Résumé

  • L’IETF prévoit de faire basculer, le 11 septembre 2026 à 22 h UTC, l’infrastructure de messagerie qui dessert ietf.org, iab.org, irtf.org et rfc-editor.org. Les messages pourront subir jusqu’à soixante minutes de retard ; l’interface Mailman3 sera indisponible, mais Mailarchive et l’accès IMAP doivent rester consultables.
  • Après une transition distincte en février 2025, l’IETF avait indiqué qu’elle croyait tous les courriels envoyés pendant l’interruption livrés peu après la reprise. Cette formulation ne prouve aucune perte. Elle montre simplement la différence entre la conviction prudente de l’exploitant et une clôture reproductible.
  • La messagerie n’est pas un outil administratif secondaire. L’IETF annonce plus de 500 listes sur lesquelles se déroule l’essentiel de son travail ; le BCP 25 impose à chaque groupe de travail une liste générale et des archives publiques. Un site d’archives accessible peut donc coexister avec un nouveau message qui n’y est jamais entré.
  • Une preuve de conservation doit distinguer rejet SMTP, suppression conforme aux règles, attente d’une confirmation, modération, acceptation par la liste, remise au relais sortant, rebond et ingestion dans les archives. Le public peut recevoir les totaux et les exceptions sans accéder aux corps, aux adresses, aux listes privées ni aux dispositifs antispam.

En 2025, une conclusion honnête mais non démontrée

Le 24 février 2025, la remise des courriels vers plusieurs domaines liés à l’IETF et vers leurs listes a été suspendue pendant le déplacement du traitement vers une nouvelle infrastructure. La fenêtre prévue de deux heures en a pris quatre, de 09 h à 13 h UTC. Une fois le service rétabli, le billet de clôture a choisi un verbe prudent : l’équipe disait croire que tous les messages envoyés vers ses adresses durant la transition avaient été livrés peu après son achèvement.

Rien, dans cette phrase, ne permet de conclure qu’un courriel a été perdu. Elle n’établit ni faute, ni insuffisance du prestataire, ni dissimulation. Le billet précisait même que le fonctionnement de fond restait essentiellement inchangé et que des travaux ultérieurs exploiteraient davantage les technologies d’informatique en nuage. La surveillance continuait, et les participants étaient invités à signaler tout comportement inattendu.

Le choix du mot croire mérite néanmoins d’être conservé. Il décrit le degré de connaissance publique à la clôture. Il ne dit pas quelle frontière définissait un message « envoyé », comment les files d’avant et d’après transition avaient été comparées, si un message en attente de vérification du premier expéditeur était compté, ni si « livré » signifiait accepté par une liste, transmis aux abonnés ou archivé.

La bascule de septembre 2026 est plus ambitieuse. L’annonce parle d’une infrastructure moderne, modulaire et conteneurisée. Les fonctions discrètes sont distribuées entre des conteneurs sur un cluster Kubernetes dédié ; l’envoi sortant passe, lui, par plusieurs machines virtuelles situées sur des réseaux de bonne réputation. postconfirm, qui vérifie les nouveaux expéditeurs, est entièrement remanié. SpamAssassin cède la place à Rspamd. La réécriture des adresses, la gestion des rebonds, les signatures DKIM et le traitement des certificats DANE évoluent également.

Le public connaît le début de la fenêtre, le retard maximal annoncé et les interfaces affectées. Il ne connaît pas encore la forme de la clôture. Une fois les nouveaux composants actifs, il faudra répondre à une question plus exigeante que « le service est-il revenu ? » : existe-t-il un état final explicable pour chaque contribution pertinente passée au voisinage de la coupure ?

Une archive accessible ne prouve que l’accès à ce qu’elle contient déjà

Dire que Mailarchive ne sera pas affecté est une promesse utile. Un lecteur devrait pouvoir rechercher un ancien échange, télécharger un message ou utiliser IMAP pendant l’intervention. Cela mesure l’accès au fonds existant.

Un message nouveau suit une autre chaîne d’événements. Envoyé à 22 h 03, il peut être retenu pour vérification de l’adresse, placé en modération, accepté par la liste, distribué aux abonnés, puis inséré dans l’archive. Le site peut rester parfaitement accessible alors que cette dernière opération n’a pas eu lieu.

Un voyant vert ne fournit pas davantage de garantie. Le nouveau frontal peut accepter des connexions alors qu’une ancienne file attend encore d’être vidée. Une publication peut atteindre les abonnés mais manquer temporairement dans Mailarchive. Une réécriture DMARC peut fonctionner et un relais sortant rencontrer un autre incident. À l’inverse, un spam refusé, un envoi non autorisé vers une liste d’annonces ou un message légitimement placé en attente ne sont pas des pertes.

La conservation ne signifie donc pas que le nombre d’arrivées doit être identique au nombre de messages publics. Elle signifie que chaque différence entre les deux nombres possède une catégorie, une justification et un état final.

La documentation publique de postconfirm rend ce problème visible. Une adresse déjà approuvée peut passer sans défi. Pour un expéditeur inconnu, le message original est conservé pendant qu’un courriel de confirmation est envoyé. Une réponse valide réinjecte les messages stockés. Le logiciel distingue aussi les situations d’acceptation, de rejet, de suppression silencieuse, de confirmation en cours et d’expiration.

La différence entre rejet et suppression silencieuse est décisive. Dans le premier cas, le serveur émet une erreur vers le système expéditeur. Dans le second, il peut annoncer un succès SMTP puis arrêter toute remise. Ces deux issues peuvent correspondre à une politique antispam légitime. Mais le succès observé côté expéditeur ne suffit pas à prouver qu’une contribution a rejoint le dossier public de l’IETF.

Le périmètre à conserver doit donc être défini sans ambiguïté : chaque message accepté pour traitement par une liste doit trouver un état vérifiable ; les autres entrées doivent produire des totaux explicables selon qu’elles ont été rejetées, supprimées, retenues pour confirmation ou placées en modération.

Une liste de l’IETF est à la fois lieu de travail et pièce d’archive

Cette discipline serait disproportionnée pour une liste commerciale. Elle ne l’est pas pour une organisation qui fait de la messagerie l’un de ses principaux lieux de production normative.

La page de service de l’IETF recense plus de 500 listes et affirme que la majorité du travail s’y déroule. Les listes de groupes de travail et de BoF sont normalement ouvertes à l’abonnement et à la publication ; leurs archives sont publiques. Le même dossier peut être consulté par Mailarchive, téléchargé par rsync ou lu en IMAP.

Le BCP 25 donne à cette pratique une assise procédurale. Le RFC 2418 exige une liste Internet générale pour chaque groupe de travail, indique que l’essentiel de ses travaux s’y conduit et impose la tenue d’une archive publique. Certaines coordonnées techniques du texte de 1998 sont évidemment datées. La fonction ne l’est pas : la liste porte la discussion, l’archive permet de la vérifier.

Un courriel peut introduire une objection de sécurité, corriger une hypothèse d’interopérabilité, signaler une déclaration de brevet, contester une appréciation de consensus ou répondre à une question de Last Call. Le volume ne vaut pas soutien, et la liste n’est pas un parlement. Mais lorsqu’un président ou un réviseur s’appuie sur l’archive pour établir ce qui a été soulevé et traité, la fidélité de la conservation devient une condition de l’évidence.

Imaginons un cas de contrôle. Un participant envoie une objection avant la bascule et son serveur reçoit un succès. Le message est stocké dans l’attente de la première confirmation. Le participant répond, mais l’objet stocké n’est pas réinjecté dans le nouveau système. Les listes reprennent, les courriels ultérieurs circulent et Mailarchive reste accessible. L’exploitation semble saine ; dans l’histoire de la décision, l’objection n’a jamais existé.

Il ne s’agit pas d’un événement constaté, mais d’un test de conception. Il montre pourquoi disponibilité et intégrité du dossier répondent à deux questions différentes.

La pensée de Heng Lu sur le rapport entre registre et réalité ne doit être transposée ici qu’avec mesure. Une liste n’acquiert pas de souveraineté parce qu’elle recueille des participations. En revanche, quand une institution utilise un dossier pour démontrer qu’un problème a été proposé, contesté et résolu, le dépositaire doit en assurer la fidélité. Cette obligation maintient l’exploitant dans un rôle étroit ; elle ne l’élève pas au-dessus des contributeurs.

Une preuve de conservation est un rapprochement, pas un communiqué cérémoniel

La clôture la plus robuste prendrait la forme d’un relevé borné, publié après l’épuisement déclaré des files et des messages en attente. Il couvrirait la fenêtre de bascule et une période de résorption précisément datée.

À l’entrée, il donnerait le nombre de messages arrivés sur chaque domaine selon une définition publiée du point de comptage. Il séparerait les refus SMTP, les acceptations et les suppressions conformes à une règle. Une acceptation technique ne serait pas renommée en contribution publique.

Pour le contrôle des nouveaux expéditeurs, il distinguerait les messages libérés, encore en attente, expirés et supprimés. Il montrerait les soldes d’ouverture et de fermeture de la modération. Pour les listes, il compterait les contributions acceptées par classe de liste publique ou privée, sans nommer les espaces confidentiels.

Au départ, le relevé s’arrêterait à la limite que l’IETF contrôle : remise aux relais sortants, tentatives, reprises et rebonds. Il ne prétendrait pas prouver qu’un fournisseur extérieur a placé chaque courriel dans une boîte de réception, ni qu’une personne l’a lu.

Pour les listes publiques, chaque message accepté devrait correspondre à un objet d’archive. La comparaison pourrait aussi vérifier que Mailarchive, rsync et IMAP présentent le même ensemble au point de clôture. Tout écart restant porterait un âge, un propriétaire institutionnel et une date de réexamen.

Le rapprochement exige un identifiant interne stable qui survive aux transformations permises. La nouvelle architecture peut modifier l’enveloppe ou le champ visible de l’expéditeur afin de préserver l’alignement SPF et DMARC, puis ajouter une signature DKIM. Le champ From affiché ne suffit donc pas.

Une empreinte salée dérivée de l’identité originelle du message pourrait servir aux comparaisons protégées. Sur les listes publiques, un échantillon ou une correspondance vérifiable est envisageable puisque les messages finissent eux-mêmes par être publiés. Sur les listes privées, seuls des totaux sont nécessaires. Avant toute publication, il faut néanmoins tester si l’empreinte permettrait de retrouver une adresse ou un Message-ID par essais simples.

La promesse de soixante minutes mérite elle aussi une mesure plus fine. Le rapport peut séparer le délai entre l’entrée IETF et la remise au relais sortant de celui qui sépare l’acceptation par la liste de l’ingestion dans l’archive. Médiane, percentile élevé et maximum racontent davantage qu’un état binaire. Un message bloqué parce que l’expéditeur ne répond pas au défi appartient à une autre horloge.

Enfin, le relevé identifierait les versions réellement déployées, l’heure de début, un éventuel retour arrière, la fin de résorption des files, les exceptions et les corrections ultérieures. L’ouverture du code est utile ; elle ne prouve ni la révision exécutée, ni la configuration en production, ni l’état vivant traité pendant la bascule.

La confidentialité impose une preuve mince

L’ouverture de l’IETF n’efface pas les données personnelles. Sa déclaration de confidentialité inclut les messages, les en-têtes, les adresses électroniques, les informations IP et les métadonnées d’interaction. Certaines listes de direction ou d’équipes sont privées. La vérification d’un premier expéditeur peut révéler une tentative de contribution qui n’a jamais été publiée.

Un export intégral des journaux serait donc une mauvaise réponse. Il exposerait des communications confidentielles, des abonnements, des décisions antispam et des détails susceptibles d’aider au contournement. Une preuve conçue pour l’assurance ne doit pas devenir un nouvel outil de surveillance.

Le document public peut se limiter à des comptes par tranche horaire, domaine et classe de liste ; aux soldes de début et de fin ; aux quantités dans chaque état ; à des fourchettes de délai ; au nombre et à l’ancienneté des exceptions ; à une méthode de comparaison non réversible ; et à un historique de corrections.

Les pièces détaillées peuvent rester sous la garde des exploitants autorisés ou d’un contrôleur indépendant soumis à la confidentialité. Le public doit pouvoir voir que les comptes se ferment et que les exceptions restent visibles. Il n’a pas besoin de lire le contenu de la modération.

Les objections utiles fixent les limites

Première objection : le courrier électronique est distribué, donc aucune conservation totale n’est possible. C’est exact au-delà de la frontière IETF. Le rapport doit prouver la remise au relais contrôlé et exposer rebonds et reprises, sans parler de réception humaine.

Deuxième objection : des statistiques faciliteraient les attaques. Les profondeurs de files en temps réel, les noms de règles et les résultats par expéditeur sont sensibles. Un agrégat différé après stabilisation peut les éviter. Si même un total par domaine est risqué, un contrôleur indépendant peut examiner le détail et publier une attestation plus grossière.

Troisième objection : l’IETF surveille déjà ses services. C’est probable. La proposition n’est pas de dupliquer cette surveillance, mais d’en tirer une pièce de clôture proportionnée à la valeur du dossier public.

Quatrième objection : l’exercice est trop lourd. Pourtant, le système doit déjà distinguer défi, acceptation, rejet, suppression, libération, réécriture, relais, rebond et archivage. Le rapprochement réutilise ces états ; il ne crée aucun comité supplémentaire.

Cinquième objection : le mot croire critique injustement 2025. Au contraire, l’incertitude assumée vaut mieux qu’une certitude fictive. Le progrès consiste à produire, cette fois, les éléments qui permettent à la prudence de devenir preuve.

Limites de l’enquête

La transition de septembre n’avait pas eu lieu à la date de clôture des recherches. Aucun document vérifié ne fournit le plan d’exécution final, les seuils de retour arrière, la topologie réelle des files, les manifestes déployés, la configuration de production, les volumes ni la méthode de rapprochement prévue. Leur absence de l’annonce publique ne prouve pas leur absence interne.

La documentation de postconfirm expose des états et des valeurs par défaut. La durée de conservation d’un jour qui y figure n’est pas nécessairement celle de la production. Les dépôts de réécriture et de certificats montrent du code public, non la réussite d’un déploiement. « Mailarchive et IMAP ne seront pas affectés » ne précise pas le régime d’ingestion des nouveaux messages.

La phrase de 2025 ne démontre aucune perte. Le fait établi est plus simple : la clôture publique reposait sur une conviction déclarée, alors que le service produit une trace centrale pour le travail de l’IETF. La bascule de 2026 permet de joindre le résultat opérationnel à cette trace par une preuve bornée.

Sources

  1. Annonce IETF du 28 août 2026 sur la transition de la messagerie
  2. Billet technique IETF sur la bascule prévue le 11 septembre
  3. Billet IETF sur la transition achevée le 24 février 2025
  4. Description des listes de diffusion de l’IETF
  5. RFC 2418 / BCP 25
  6. Déclaration de confidentialité IETF/IRTF/IAB
  7. IETF Note Well
  8. Dépôt IETF Tools postconfirm
  9. Mise à jour du projet de transition de l’infrastructure IT