Résumé

  • Le compte rendu du 25 septembre énumère huit défauts corrigés après la bascule, de l’expéditeur confirmé envoyé en modération aux messages groupés écartés et aux échecs DMARC.
  • Le problème des rebonds a révélé un ancien stock d’adresses mortes. Lorsque le nouveau traitement a commencé à désactiver des abonnés sur la base de rebonds peut-être erronés, l’IETF l’a arrêté et a réactivé les adresses désactivées en attendant un correctif.

Le billet de félicitations est arrivé le premier. Le 11 septembre, l’IETF a déclaré achevée la migration de ses services de messagerie. Il décrivait des fonctions séparées en conteneurs, leur orchestration Kubernetes, un nouveau filtre antispam, une gestion améliorée des certificats et un meilleur traitement des rebonds. Le titre et l’introduction avaient été actualisés pour annoncer la fin du chantier ; l’essentiel des détails techniques provenait encore de la publication du 28 août.

C’est un constat de bascule, pas un bilan d’exploitation.

Le bilan opérationnel est arrivé le 25 septembre. Jay Daley, directeur exécutif de l’IETF, a indiqué que la plupart des problèmes étaient résolus, puis en a décrit huit comme corrigés et deux encore en cours. Il a aussi révélé que le projet avait été lancé trois ans auparavant, après plusieurs difficultés confié à un nouveau prestataire pour être achevé. Un composant central du travail initial n’avait pas été réécrit ; ses défauts n’avaient pas été détectés avant le lancement. « C’était notre erreur », a écrit Daley.

Il ne s’agissait pas d’une panne spectaculaire, mais de petites règles aux coutures entre les listes et les expéditeurs réels. Une adresse confirmée, qui écrivait sur une liste sans y être abonnée, manquait à la liste globale d’autorisation : son message partait en modération. Les courriels Precedence: Bulk étaient supprimés sans avis, surtout ceux de l’IANA. Les balises BATV étaient mal traitées. Les adresses confirmées en majuscules devaient se confirmer une nouvelle fois. Des règles destinées à des expéditeurs atypiques étaient devenues inaccessibles. Certains champs From d’Outlook étaient découpés en deux, avec un domaine IETF ajouté à la première partie. Des notifications de Postorius partaient d’une adresse provisoire, car le champ du propriétaire était vide. Enfin, la réécriture DMARC échouait pour certains envois en fonction du nombre de destinataires.

Le directeur a déclaré ces huit points corrigés. Ils constituent un décompte de défauts nommés, pas une mesure de tous les messages manqués ou de tous les participants touchés. Le compte rendu ne fournit aucun dénominateur.

Le problème plus sérieux concernait les rebonds. Les limites structurelles de l’ancienne infrastructure empêchaient leur acheminement vers les listes pour traitement. Les adresses n’étaient donc pas désactivées. Un stock d’adresses décrites comme injoignables mais toujours abonnées s’était accumulé. Le nouveau traitement a commencé à le résorber ; les responsables de listes ont alors reçu de nombreuses alertes annonçant la désactivation d’abonnés pour excès de rebonds.

La machine avait une file d’attente et une conclusion. Elle n’avait pas encore de conclusion fiable. L’IETF a indiqué que certains rebonds semblaient incorrects. Elle a donc arrêté le traitement et réactivé toutes les adresses désactivées par celui-ci dans l’attente d’un correctif. Pendant un temps, la décision a privilégié une adresse peut-être morte plutôt qu’une automatisation susceptible de supprimer à tort un participant actif. C’était un choix de protection concret, pas la preuve que le stock avait disparu.

Le même compte rendu révèle une autre surprise de performance : le mode VERP activé par défaut dans Mailman réduisait les temps de traitement du courrier de quatre à cinq ordres de grandeur. L’IETF l’a désactivé pendant l’enquête. L’annonce ne donne ni durée de référence, ni charge de test, ni délai absolu. Le nouveau filtre Rspamd était aussi encore en réglage, car trop de spam passait.

L’ordre des événements compte. Le billet du 11 septembre présentait l’amélioration du traitement des rebonds et la réduction des occasions de spam parmi les résultats attendus. Le document du 25 septembre montre pourquoi les intentions coûtent peu et les preuves opérationnelles beaucoup : le nouveau traitement a révélé un vieux stock et des signaux douteux ; le filtrage du spam nécessitait encore des réglages. Une architecture modulaire n’efface pas la dette de données héritée et ne rend pas ses premiers verdicts exacts par décret.

Pour toute communauté qui dépend de listes communes, la leçon est simple. Une migration achevée est un événement daté. Une diffusion fiable est un résultat répété, qui dépend de l’identité de l’expéditeur, de la modération, de l’expansion des listes, de la réécriture, de l’authentification, de l’interprétation des rebonds et de la livraison finale. Chaque étape peut réussir son test tandis que le message échoue plus loin.

Le compte rendu public expose le choix de contrôle, mais pas son coût. Il ne précise ni le nombre d’adresses réactivées, ni la part des rebonds erronés, ni la durée de suspension du traitement, ni la référence utilisée pour mesurer VERP, ni la date de fin des réglages Rspamd. Ces chiffres changeraient l’évaluation du rétablissement. Le constat ferme est plus étroit : l’IETF a interrompu la désactivation d’abonnés lorsque les preuves fournies par les rebonds n’étaient pas fiables, puis a rendu cette correction publique.

Sources