Résumé

  • Pendant la migration de septembre 2026, la liste générale de modération de l’IETF a omis les adresses confirmées qui n’étaient abonnées à aucune liste. Leurs messages ont été mis en attente.
  • L’erreur a mêlé deux états distincts : une adresse confirmée pour l’envoi et une adresse abonnée à une liste précise. L’IETF dit avoir rétabli toutes les adresses confirmées dans la liste d’autorisation.

Le nouveau portier de l’IETF avait perdu le registre des personnes autorisées à entrer. Pour refaire sa liste, il avait consulté la liste des personnes qui voulaient recevoir le courrier.

Le 25 septembre, Jay Daley, directeur exécutif de l’IETF, a décrit le défaut. La liste globale utilisée par les outils de modération excluait les adresses déjà confirmées qui n’étaient abonnées à aucune liste. Un message envoyé depuis l’une de ces adresses partait en modération. Le correctif consistait à reconstruire la liste à partir de toutes les adresses confirmées.

La différence tient à deux décisions de l’utilisateur. Confirmer une adresse signifie avoir répondu au défi envoyé par le système. S’abonner signifie demander les messages d’une liste donnée. On peut confirmer une adresse pour contribuer sans accepter plusieurs centaines de courriels dans sa boîte. L’un est une preuve de contrôle de l’adresse; l’autre, une préférence de réception. La migration a utilisé la seconde comme preuve de la première.

Ce n’est pas un détail de configuration réservé aux administrateurs de listes. L’IETF gère plus de 500 listes de diffusion et affirme que la majeure partie de son travail s’y déroule. Sa procédure impose une confirmation par défi-réponse lors d’un premier abonnement ou d’un premier envoi. L’annonce de la migration précise le motif : cette première confirmation établit aussi l’accord du participant avec le Note Well, qui expose les règles de participation. Quand le système oublie cette preuve, il oublie ce qui a ouvert la porte.

Deux colonnes, deux questions

Avant la migration, le service conservait une liste générale d’adresses ayant répondu au défi. Dans la nouvelle architecture, un composant vérifiait si l’expéditeur était déjà approuvé. Pour une nouvelle adresse, le message initial attendait la réponse au défi; après validation, le système le libérait et enregistrait l’approbation pour les envois suivants.

Le défaut s’est produit lors de la reconstruction de la liste de modération. Les adresses confirmées mais absentes de toute liste d’abonnés ont été perdues. Pour les listes, l’expéditeur manquait alors dans la table de modération attendue, et le message était retenu. L’avis public décrit le symptôme et le correctif.

Le défaut de conception est visible : l’abonnement est un mauvais substitut à la preuve qu’une adresse a passé le contrôle d’envoi.

Une migration, plusieurs hypothèses cassées

Daley a recensé huit problèmes corrigés au 25 septembre et deux encore en cours. Les messages marqués Precedence: Bulk avaient été supprimés sans avertissement, surtout ceux d’IANA. Des messages signés BATV semblaient provenir d’un relais de l’IETF. Les adresses confirmées avec majuscules devaient parfois confirmer une seconde fois. Des expressions de compatibilité pour certains expéditeurs ne pouvaient jamais s’exécuter. Un analyseur échouait sur certains formats Outlook; des notifications Postorius affichaient un champ vide pour le propriétaire du site; et le traitement DMARC échouait dans certains cas de nombreux destinataires.

Les deux dossiers ouverts concernaient les rebonds et le spam. Une accumulation d’adresses injoignables restait abonnée. Le nouveau traitement des rebonds désactivait des comptes, mais certains résultats semblaient erronés. L’opérateur a suspendu le traitement et réactivé les adresses désactivées pendant l’enquête. Le VERP, technique de Mailman qui associe un rebond à un abonné, ralentissait le traitement de quatre à cinq ordres de grandeur dans cette installation; il a été désactivé à son tour. Le réglage de Rspamd continuait après le passage de trop de spam.

Le récit de Daley décrit aussi la chaîne de responsabilité. Le système avait été commandé trois ans auparavant. Après des difficultés répétées, un autre prestataire en a achevé une partie, sans remplacer un composant central hérité du projet précédent. Ses défauts n’ont pas été détectés avant la mise en service. « C’était notre erreur », écrit Daley. L’aveu est utile parce qu’il nomme le composant conservé et le contrôle absent.

La liste appartient au processus de normalisation

La RFC 2418 explique que les groupes de travail conduisent une grande partie de leurs travaux par courrier électronique. Elle présente l’email comme un moyen d’élargir la participation au-delà des réunions en personne et exige que les contributeurs qui n’assistent pas aux réunions puissent prendre part au processus. Elle exige aussi des archives publiques. La RFC 6778 détaille leur archivage, leur consultation et leur recherche sur le Web : le débat en cours et le dossier qui lui survit sont deux parties du même travail.

Recevoir une liste et y publier sont donc deux fonctions différentes. La première règle le contenu d’une boîte de réception; la seconde permet à une contribution d’entrer dans le canal de travail. Les règles anti-spam et la vérification des adresses restent nécessaires. Une liste ouverte n’est pas une invitation aux expéditeurs falsifiés. Elle suppose que le système se souvienne du résultat quand une personne légitime a terminé le contrôle.

Le constat opérationnel est précis : des messages d’expéditeurs confirmés ont été envoyés en modération et attendaient une libération manuelle. La note ne donne ni nombre d’expéditeurs ou de messages ni délai de modération; ces données distingueraient quelques cas d’une interruption plus large. La porte avait pris une préférence de réception pour une preuve d’autorisation, et l’expéditeur attendait qu’un humain démêle les deux.

Le correctif doit garder les états séparés

Daley indique que la liste d’autorisation comprend de nouveau toutes les adresses confirmées. L’annonce initiale précise que l’accès aux archives et à IMAP n’avait pas été interrompu pendant la bascule prévue. Ici, une correction circonscrite compte : elle remet l’adresse confirmée dans l’état que le contrôle des listes consulte.

Un service de messagerie gère plusieurs registres : confirmation de l’adresse, abonnement, modération, rebonds, réécriture de l’expéditeur et archivage. Chacun répond à une question différente. Les fusionner peut simplifier une migration de base de données; une exportation incomplète peut alors effacer le travail d’un autre registre.

Le test utile est simple : garder les adresses autorisées à publier indépendamment des abonnements; vérifier qu’une adresse confirmée mais non abonnée peut écrire sur une liste ouverte; tester séparément une liste à accès restreint; puis rapprocher modération, livraison et archive après la bascule. Un test limité aux abonnés actifs aurait reproduit l’angle mort avec une efficacité exemplaire.

Les listes ne sont pas un décor autour du travail de l’IETF. Elles portent débats techniques, annonces de procédure et traces qui survivent aux réunions. La distinction entre recevoir et contribuer tient dans deux champs. Pendant la migration, l’IETF en a gardé un et perdu l’autre.

Sources