Résumé

  • L’IETF prévoit de basculer ses services de courrier le 11 septembre 2026 à 22 h UTC. La livraison pourra être retardée jusqu’à soixante minutes ; l’interface web Mailman3 sera indisponible, tandis que les archives et l’accès IMAP doivent rester consultables.
  • La disponibilité des conteneurs ne suffit pas. Un courriel peut être accepté, stocké dans l’attente d’un défi, libéré, réécrit pour l’alignement DMARC, signé en DKIM, protégé par DANE puis confié à un relais distinct. Chaque verbe désigne une responsabilité différente.

L’annonce de l’IETF du 28 août couvre les domaines ietf.org, iab.org, irtf.org et rfc-editor.org, listes comprises. Elle décrit une architecture modulaire : fonctions isolées dans des conteneurs, ordonnanceur Kubernetes dédié, communication par milter, nouveau moteur Rspamd et machines virtuelles séparées pour la sortie du courrier.

Cette précision permet d’éviter une lecture trompeuse. Une archive joignable ne démontre pas que les nouveaux messages circulent. Une interface Mailman3 arrêtée ne dit rien, à elle seule, sur les files SMTP. Un pod sain ne prouve pas que le relais distant a accepté le message. Il faut observer des plans de service différents.

Une migration nouvelle, pas la reprise de l’alerte de 2024

BTW conserve déjà un article sur l’arrêt planifié d’août 2024, le passage de l’envoi principal vers Amazon SES et le risque annoncé de non-récupération de certains messages. Ce texte reste public. Le présent dossier n’en change ni le sens ni la portée.

Une note de février 2025 indiquait encore que le traitement sous-jacent demeurait fondamentalement identique et que des travaux ultérieurs exploiteraient davantage les technologies cloud. L’annonce de 2026 décrit précisément cette étape ultérieure : refonte complète de postconfirm, nouveau filtrage, réécriture d’adresses, gestion DANE, composants séparés et sortie hors du cluster.

La question n’est donc plus seulement « combien de temps le courrier attendra-t-il ? ». Elle devient « qui détient le message à chaque instant, qui peut le modifier et quelle preuve autorise le passage suivant ? ».

postconfirm crée une garde conditionnelle

Le dépôt public postconfirm décrit un milter qui reconnaît les expéditeurs déjà approuvés. Pour une adresse nouvelle, il conserve le message, émet un défi et attend la réponse. Une confirmation correcte fait passer l’adresse à l’état accepté et réinjecte le message retenu.

La machine d’états distingue notamment inconnu, en confirmation, accepté, rejeté, supprimé et expiré. Elle distingue aussi le rejet, visible par le client SMTP, de la suppression silencieuse après une réponse de succès. Ce détail interdit de confondre trois registres : la réponse remise à l’expéditeur, l’objet effectivement stocké, et l’événement ultérieur de libération ou de purge.

La documentation publique mentionne des paramètres et valeurs par défaut. Ils ne révèlent pas la configuration de production. L’annonce ne donne ni durée réelle de conservation, ni taille de base, ni version déployée, ni politique de purge. Après la bascule, ces éléments devront être lus dans la configuration et les traces, non déduits du README.

Le défi a lui aussi une portée limitée. L’IETF l’associe à l’acceptation de Note Well. Une réponse démontre un contrôle suffisant de la boîte pour ce parcours. Elle n’atteste ni identité juridique, ni pouvoir de représentation, ni véracité du contenu. La participation peut justifier l’entrée dans une procédure ; elle ne transforme pas le détenteur d’une adresse en mandataire universel.

Réécrire une adresse, c’est déplacer la responsabilité technique

Les listes redistribuent un message depuis des adresses IP qui ne figurent pas nécessairement dans le SPF du domaine d’origine. Elles peuvent aussi altérer des éléments couverts par la signature DKIM. Une politique DMARC stricte peut alors bloquer un message légitime.

Le milter annoncé vérifie SPF et DMARC. Si les adresses d’envoi de l’IETF ne sont pas autorisées par le SPF d’origine, il peut remplacer l’envelope From par une forme réversible sous un domaine dmarc.* contrôlé par l’IETF. Avec une politique DMARC de quarantaine ou de rejet, il peut aussi réécrire le header From. Le message sortant reçoit ensuite une signature DKIM du domaine approprié.

Le RFC 9989 constate que ces accommodements sont désormais établis dans le monde des listes. Ils rétablissent l’alignement ; ils ne transfèrent pas l’auteur. La signature définie par le RFC 6376 engage un domaine signataire sur les parties signées. Elle ne prouve ni l’identité humaine, ni l’exécution du défi, ni la remise finale.

Une piste d’audit correcte conserve l’adresse originale reçue, les deux adresses réécrites, la politique consultée, la fraîcheur de la correspondance inverse, le domaine et le sélecteur DKIM. Sans cette double identité, une archive ou une enquête peut attribuer à l’IETF des paroles qu’il n’a fait que transporter.

DANE exige un chevauchement observable

L’annonce mentionne un schéma de certificats « courant plus suivant ». Le RFC 7672 explique pourquoi : avant de servir un nouveau certificat, les associations TLSA doivent être publiées assez longtemps pour que les caches DNS expirent l’ancien état. En cas de DANE obligatoire et de non-correspondance, le courrier doit attendre plutôt que descendre silencieusement vers un canal non authentifié.

Un robot de renouvellement peut donc déclarer son opération terminée alors que des expéditeurs externes voient encore un TLSA ancien. La preuve rassemble certificat généré, TLSA publié, validation DNSSEC, TTL, certificat réellement présenté par chaque endpoint, handshake et âge de file. Aucun tableau isolé ne suffit.

La réussite future n’est pas encore établie. L’annonce décrit un dispositif, pas le résultat du 11 septembre. Elle ne dit pas combien d’expéditeurs imposent DANE ni quelle proportion des caches aura convergé.

La modularité réduit le périmètre d’un service, pas celui de la preuve

Séparer les fonctions permet de dimensionner le filtrage, la confirmation et la réécriture sans redéployer tout le système. Mais chaque liaison milter devient un point où le message peut être accepté, différé, rejeté, supprimé ou modifié. Deux réplicas peuvent momentanément porter des versions différentes. Kubernetes peut recréer un processus sans restaurer l’état métier qui expliquait son dernier choix.

La sortie du courrier constitue en outre un autre domaine : plusieurs machines virtuelles placées sur des réseaux réputés sains. Le cluster peut rester vert tandis qu’une VM accumule les files ou subit le bridage d’un grand destinataire. SMTP transfère la responsabilité saut par saut ; il ne constitue pas une transaction atomique de l’auteur au lecteur.

L’objectif annoncé de supprimer une possibilité de relais ouvert rejoint le RFC 2505. Il faut néanmoins le vérifier sur les retours réécrits, les adresses périmées et chaque chemin exceptionnel. Une intention de sécurité n’est pas un test négatif exécuté.

L’archive témoigne d’une publication, pas d’une livraison universelle

Le maintien des archives et d’IMAP pendant la fenêtre protège l’accès à l’historique. Il ne garantit pas qu’un message retenu soit déjà archivé, qu’un post archivé ait atteint chaque abonné, ou qu’un relais distant l’ait accepté.

Il faut une corrélation qui traverse les transformations : réponse d’entrée, empreinte de l’objet retenu, défi, libération ou purge, réécriture, signature, expansion de liste, insertion dans l’archive, file sortante, réponse SMTP distante et bounce. Comme les octets peuvent changer, chaque empreinte doit nommer son étape.

La primauté du code exécuté impose cette discipline : le plan et le dépôt établissent l’intention, pas le chemin réellement pris par un message. La souveraineté pratique des données se trouve dans les copies, bases, journaux, clés, DNS et files qui détiennent réellement l’information. Enfin, la spécification minimale et la décision locale maintiennent la bonne frontière : SMTP, DKIM, DMARC et DANE donnent des règles communes ; chaque opérateur choisit son déploiement, mais doit prouver l’interopérabilité à chaque interface.

L’architecture devient crédible lorsqu’elle peut raconter la vie complète d’un message sans emprunter la réussite d’un composant voisin.