Une restauration modifie les observations futures ; il ne peut pas atteindre chaque expéditeur et effacer une stratégie mise en cache. Lorsqu'une stratégie d'application commence à retarder le courrier légitime, conservez la révision exacte cassée et trouvez le moyen le plus rapide de faire en sorte qu'un chemin de réception satisfasse à la stratégie que les expéditeurs peuvent déjà détenir.
Stabiliser la livraison avant de supprimer les contrôles
Références : RFC 8461 §4, RFC 8461 §5.1.
Identifiez si l'échec est un MX omis, un problème de certificat, une perte STARTTLS problème de support ou de récupération de politique. La restauration d'un MX précédemment conforme ou la réparation de son certificat peuvent aider les expéditeurs avec des politiques mises en cache anciennes et nouvelles plus directement que de tenter un retrait de politique globale d'urgence.
Vérifiez les journaux de l'expéditeur concerné lorsqu'ils sont disponibles et testez chaque candidat destinataire prévu. S'il reste un MX conforme, les expéditeurs pourront peut-être l'utiliser. Ne présumez pas qu’une sauvegarde est sûre simplement parce que sa préférence DNS est une priorité inférieure ; il doit encore correspondre à la politique et réussir la validation du transport.
Choisissez la réparation ou le retrait volontaire
Références : RFC 8461 §3.2, RFC 8461 §8.1, RFC 8461 §8.3.
Pour une réparation, publiez le corps HTTPS corrigé avant de modifier l'identifiant TXT . Conservez les copies de police précédentes et les valeurs max_age disponibles pour calculer le risque de transition. Un corps actuel corrigé ne prouve pas qu'un expéditeur l'a récupéré.
Pour une suppression délibérée, la section 8.3 RFC 8461 recommande le mode de service aucun avec un petit max_age (par exemple, un jour) et la mise à jour de l'enregistrement de découverte, puis la conservation de l'infrastructure de politique pertinente jusqu'à ce que toutes les politiques précédemment servies aient expiré avant de la supprimer. Calculez la dernière durée de service de chaque version plus son propre max_age, puis utilisez la dernière expiration pour chaque version. Une version plus ancienne avec une durée de vie plus longue peut survivre à la précédente. Une politique none nécessite toujours version et max_age ; Les lignes mx ne sont pas requises dans ce mode. Utilisez un nouvel identifiant valide pour annoncer le changement.
Reproduire le cas obsolète
Références : RFC 8461 §3.3, RFC 8461 §5.
Dans un expéditeur contrôlé, mettez en cache une stratégie d'application autorisant uniquement mx1.example.net avec max_age 86400. Remplacez DNS public et le HTTPS par une stratégie aucune, mais empêchez initialement cet expéditeur d'obtenir la mise à jour. Tentative de livraison à mx2.example.net . L'ancienne politique d'application valide exclut toujours mx2, malgré le nouveau corps aucun de l'opérateur.
Autorisez ensuite l'actualisation et la capture de l'expéditeur en n'en appliquant aucun, ou avancez l'horloge de test contrôlée tout au long de la durée de vie du cache d'origine dans un environnement isolé et sécurisé. Ne modifiez pas les horloges de l'infrastructure de messagerie de production pour ce test. Il s'agit d'une procédure de laboratoire et non d'une procédure exécutée. MTA test; le nouvel appareil hors ligne démontre uniquement l'arithmétique de l'état et de la dernière durée de vie, pas un véritable cache d'expéditeur.
Terminez avec des preuves pour les deux cohortes
Références : RFC 8461 §8.3, RFC 8460 §4.1.
Vérifiez le comportement d'un nouvel expéditeur sans stratégie mise en cache et d'un expéditeur connu pour détenir la révision d'application précédente. Préservez les résultats de la file d’attente, récupérez les résultats et les métadonnées des politiques. TLS-RPT peut aider à identifier les échecs restants, mais la couverture est incomplète et les rapports sont retardés.
Gardez l'hôte HTTPS et la découverte disponibles pendant la fenêtre de retrait prévue, surveillez le chemin de livraison réel et documentez la décision de suppression finale. La suppression _mta-sts à elle seule ne constitue ni une restauration immédiate ni une stratégie fiable de récupération après incident.
Preuves historiques conservées et portée restante
Ce qui suit décrit les observations conservées du 7 novembre 2026, et non une nouvelle expérience de réseau pour cette revue. Les contrôles hors ligne nouvellement exécutés sont enregistrés séparément.
Le calcul du retrait inclut désormais chaque version précédemment servie plutôt que uniquement le dernier max_age. Dans le grand livre logique exécuté, A1 a été servi pour la dernière fois à 1 000 300 avec une durée de vie de 86 400, B2 à 1 000 600 avec une durée de vie de 3 600 et C3 à 1 000 900 avec une durée de vie de 3 600. Leurs limites d'expiration sont respectivement de 1 086 700, 1 004 200 et 1 004 500. La limite de suppression calculée est donc 1 086 700. L’ancien instantané de l’expéditeur A1 rejette toujours le nouveau nom d’hôte uniquement, même après que le laboratoire a annoncé et récupéré B2. La restauration de l'ancienne route compatible reste significative pour cet instantané. Il s'agit d'un calcul d'état et d'itinéraire étiqueté, et non d'un retrait de cache distant observé ou d'une récupération de messages en file d'attente. Un retrait de production doit utiliser les heures réelles de dernière diffusion et toutes les versions antérieures.