Résumé

  • L’IETF a programmé au 11 septembre 2026 une transition de ses services de courrier. Elle prévoit jusqu’à soixante minutes de retard et l’indisponibilité temporaire de l’interface Mailman. La bascule n’a pas encore eu lieu : ce sont des prévisions, pas des résultats.
  • La réponse au défi d’un nouvel expéditeur autorise postconfirm à remettre en circulation un message conservé. Elle ne prouve ni son acceptation par la liste, ni la justesse de la réécriture, ni la signature, ni le transport DANE, ni la remise à l’abonné.

Un contributeur envoie pour la première fois un message pendant la maintenance. Postconfirm le conserve, pose un défi, reçoit la réponse puis le réinjecte. Le compteur des messages en attente diminue. Cette diminution peut signifier que le message a avancé. Elle peut aussi signifier qu’il a expiré, été purgé ou quitté une file sans accusé de la suivante.

L’annonce publiée le 28 août mérite donc d’être lue comme une carte de responsabilités. À 22 heures UTC le 11 septembre, les services des domaines de l’IETF, de l’IAB, de l’IRTF et du RFC Editor doivent migrer. Les archives et l’accès IMAP sont annoncés comme maintenus, tandis que l’interface web Mailman3 sera indisponible. Le retard possible de soixante minutes fixe une attente opérationnelle ; il ne mesure pas encore la transition.

La sortie d’une file n’est pas une arrivée

Le nouveau dispositif isole des fonctions dans des conteneurs orchestrés par Kubernetes et reliés par le protocole milter. Les relais sortants restent sur plusieurs machines virtuelles. Postconfirm, Rspamd, la réécriture d’adresses, la signature DKIM, les certificats DANE et le traitement des rebonds ont donc chacun une frontière observable.

Le projet postconfirm décrit précisément le premier transfert. Un expéditeur inconnu peut voir son courrier stocké en attendant un défi. Une réponse correcte place l’expéditeur dans l’état accepté et libère les messages. Cela prouve l’application d’une règle locale. Cela n’authentifie pas une personne et ne dit rien du traitement ultérieur.

Il faut rapprocher les empreintes, pas seulement les volumes : identifiant du message, heure de dépôt, échéance, état du défi, tentative de libération et accusé de réinjection. La documentation distingue même le rejet du rejet silencieux après réponse positive au client. Sans nom du composant et de l’action, « SMTP OK » reste une phrase sans frontière.

Réécrire une identité crée un nouveau fait

Une liste diffuse du courrier depuis une infrastructure qui n’est pas nécessairement autorisée par la politique SPF de l’expéditeur. L’annonce explique que le nouveau service vérifie SPF et DMARC et peut réécrire l’adresse d’enveloppe ou l’en-tête, puis signer avec DKIM.

SPF relie un hôte émetteur à la politique publiée d’un domaine. DKIM protège les éléments sélectionnés d’un message sous une identité de domaine ; le texte admet qu’un signataire ne connaît pas toujours l’identité individuelle. DMARC ajoute alignement et politique de réception, sans résoudre les domaines visuellement proches ni les noms d’affichage trompeurs.

Le journal doit donc conserver l’avant et l’après : identités originales, preuve ayant déclenché la branche, adresses réécrites, domaine et sélecteur de signature, champs couverts et résultats observés chez des vérificateurs. Une signature valide de l’infrastructure IETF attribue la forme signée à cette infrastructure. Elle ne certifie pas rétroactivement l’identité ni le mandat de l’auteur initial.

Le certificat prêt n’est pas la session établie

Le schéma de rotation current + next 3 1 1 vise à maintenir un certificat utilisable avec DANE. Le dépôt public danebot montre des emplacements distincts pour les états courant et suivant. Préparer la clé suivante est une preuve de préparation, pas une observation faite par un expéditeur distant.

DANE pour SMTP permet au MTA émetteur d’utiliser MX, DNSSEC et TLSA pour découvrir et authentifier le prochain saut TLS. Le RFC ne prétend pas protéger tout le courrier et dépend du DNSSEC contre la rétrogradation. Il faut vérifier séparément la matière prévue, l’état TLSA vu, le certificat réellement servi et la négociation de clients couvrant l’ancien et le nouvel état.

Celui qui accepte prend une obligation bornée

SMTP donne un sens fort au 250 OK après DATA : le récepteur prend la responsabilité de remettre ou relayer. Mais il ne promet pas une lecture humaine. Les notifications d’état disent même que « delivered » peut désigner la remise à un exploseur de liste. « relayed » et « expanded » ont encore d’autres limites.

Le registre de migration doit nommer l’émetteur de chaque reçu : MTA entrant, postconfirm, gestionnaire de liste, réécriture, signataire, relais sortant, MTA destinataire, boîte témoin. Une absence de rebond n’est pas une preuve de livraison. Un conteneur sain n’est pas une preuve de transit. Une file vide n’est pas une preuve de conservation.

La discipline des couches de réalité de Heng Lu interdit de confondre configuration, état local, acceptation protocolaire et résultat. La primauté du code en fonctionnement exige un témoin à la frontière qui pouvait réellement agir. Enfin, le contrôle pratique des données appartient à celui qui peut lire les files, réécrire l’identité, changer les clés ou restaurer le message.

La transition sera démontrée lorsque ces reçus se réconcilieront. Avant cela, une architecture modulaire et un défi réussi décrivent seulement ce qui devait arriver et la première porte franchie.

Sources