AnnonceNouveautés19 lectures
Le courrier partait une conversation à la fois, et le reste attendait
LeTock.fréditeur 10 pts ·
Publié le 28 septembre 2026.
Le voyant accusait le relais pendant que la chaîne faisait exactement son travail.
Signalé depuis l’écran : « en file : 26 — la file monte : relais ou worker ». Vérification : zéro message en souffrance. Les vingt-six attendaient une reprise programmée entre deux et trente minutes plus tard, exactement comme prévu depuis qu’un refus temporaire fait patienter. Le voyant s’allumait au-delà de vingt messages en attente, et un compte n’est pas une tendance — le mot « monte » affirmait quelque chose que personne n’avait mesuré. Pire : le correctif du matin, qui fait patienter les reprises, remplit la file par construction. La règle aurait donc hurlé de plus en plus fort à mesure que la chaîne s’améliorait. Ce qui dit une panne, c’est un message dont l’heure est passée depuis plus d’un quart d’heure, et rien d’autre ; c’est maintenant la même condition ici, dans l’état de la chaîne, et dans la sélection d’expédition. Trois règles pour une seule question, c’était la garantie qu’un écran mente un jour. Le nombre en file reste affiché, parce que c’est un fait : c’est le jugement qui change de source.
Cinquante-neuf refus de réputation étaient imputés aux destinataires — et 23 adresses valides ont été supprimées à cause de ça.
Orange écrit « Mail rejete. Mail rejected. OFR_506 ». Rien dans cette phrase ne dit que c’est notre réputation qui est en cause, et le code enrichi vaut 5.2.0 — qui parle de la boîte du destinataire. Ces refus étaient donc annoncés « cause : destinataire ». Nous ne supprimions rien nous-mêmes, mais un client a fait la seule chose raisonnable avec cette information : il a retiré vingt-trois adresses Orange et Wanadoo parfaitement valides. Une donnée ambiguë qu’on laisse interpréter finit toujours par être interprétée de la façon qui coûte le plus cher. Le piège était dans la correction évidente : attraper « tout ce qui contient OFR ». Les quatre codes Orange rencontrés ne veulent pas la même chose — OFR_506 et OFR005_100 nous désignent, mais OFR_416 désigne un destinataire réellement invalide. Un motif large aurait transformé une adresse morte en faute de notre part, donc réessayée indéfiniment, ce qui est la première cause de réputation détruite. On nomme le code qu’on a mesuré, et rien de plus ; un test garde chacun des quatre.
La campagne froide pouvait prendre la place d’un code de connexion.
Constaté en cherchant pourquoi un code de connexion était arrivé après son expiration. Ce n’était pas la file — vérifié : 31 secondes entre la création et l’acceptation par le serveur d’en face. Mais le chiffre d’à côté disait autre chose : 904 messages sur les 1 000 du jour, dont 600 de prospection — exactement la part froide autorisée, la règle avait bien fonctionné — et 304 de transactionnel. Quatre-vingt-seize places pour le reste de la journée. Deux bornes servaient la même fonction, et la plus grossière gagnait. Le plafond de mille était un garde-fou contre un compte inconnu ; celui qui a un sens physique est le palier de chauffe, puisque c’est lui que les serveurs d’en face constatent. Une équipe hors quota suit donc maintenant le palier, sans jamais descendre sous l’ancien plafond — les premiers paliers valent 50, les suivre aveuglément aurait resserré le plafond d’une équipe de confiance au lieu de l’ouvrir. La part froide, elle, ne bouge pas : élever ce plafond ne donne rien de plus à la campagne, ça rend au transactionnel la place qu’elle lui prenait. Et une fois la chauffe finie, la borne reste finie : « aucune limite » sur un chemin d’envoi est la façon dont une boucle qui s’emballe devient une catastrophe de réputation.
La file montait : vingt-sept places sur cinquante étaient prises par des messages qui ne partiraient jamais.
Signalé depuis l’écran : « en file : 487 ». Ma première hypothèse était fausse, et elle m’accusait — je pensais que mon propre changement du matin déclenchait des limites de débit. Vérification : aucune limite de débit nulle part, et 368 des 397 messages en file n’avaient jamais été tentés. Les autres tournaient en rond. Un refus temporaire (4xx) remettait le message en file sans aucun délai : le tour suivant le reprenait une minute plus tard, cinq fois, puis le déclarait mort. Le dégât le plus grave n’est pas la file, c’est le greylisting — cette protection très répandue refuse par principe la première tentative et accepte la même remise un quart d’heure plus tard. Cinq essais en cinq minutes échouaient donc à tous les coups face à un mécanisme conçu pour nous laisser passer, et le message était perdu alors qu’il suffisait d’attendre. Les reprises s’espacent désormais — 5 minutes, 15, 1 heure, 4 heures — et la raison affichée dit quand, parce qu’un message qui disparaît quatre heures sans explication est indiscernable d’un message perdu.
Et ce qui a déjà échoué passe maintenant en dernier.
La file était servie par date, donc le plus vieux d’abord, donc le plus cassé d’abord — une file d’attente qui récompense l’échec. Vingt-sept des cinquante places de chaque lot revenaient aux mêmes messages d’un seul domaine client mal configuré, pendant que des messages neufs attendaient derrière, transactionnels compris. Le nombre de tentatives passe donc devant la date : un message jamais essayé part toujours en premier, les reprises prennent la place qui reste. Aucune n’est abandonnée pour autant — leur tour vient quand la file se vide, et un test le vérifie, parce qu’une priorité qui affame la queue serait le défaut suivant.
Le groupage par domaine ne protégeait pas ce qu’il prétendait protéger.
Corrigé dans la journée, sur relecture de mon propre code. Les remises étaient groupées par nom de domaine destinataire, pour qu’un serveur ne voie jamais deux conversations à la fois. Mais la plupart des « .fr » ne tiennent pas leur propre serveur de courrier : ils pointent vers une poignée d’hébergeurs. Huit domaines différents, c’était donc souvent huit conversations simultanées vers la même machine — exactement ce que le groupage devait empêcher, avec en prime la fausse impression de s’en être prémuni. Le serveur d’en face ne compte pas les domaines, il compte les connexions par adresse IP. Le groupage suit maintenant le MX réellement appelé.
Huit secondes par message, cinquante messages à la file : un tour de sept minutes.
Signalé depuis l’écran : « e-mails bloqués depuis plus de 15 min : 178 ». Mesuré avant de toucher quoi que ce soit, dans le bilan que chaque tour de worker écrit : cinquante messages traités en 414 secondes, soit 8,3 secondes chacun, et un maximum de 8,7 minutes pour un tour sur trois heures d’observation. Ces huit secondes ne sont pas du calcul, c’est de l’attente — résolution MX, connexion, STARTTLS, poignée de main, DATA, fermeture, puis on recommence pour le suivant. Une passe de prospection dépose 180 messages : vingt-cinq minutes pour les sortir. Le gain est facile, la garantie qui l’accompagne ne l’est pas. Ouvrir cinquante connexions d’un coup vers le même serveur est la définition de ce qui fait mettre une adresse d’expédition sur liste noire. Les messages sont donc groupés par domaine destinataire : un domaine ne voit jamais qu’une conversation à la fois, exactement comme avant, et ce sont les domaines différents qui avancent ensemble — huit de front. Trois tests gardent cette propriété plutôt que la vitesse : une mesure de durée dans un test échoue au hasard le jour où la machine est chargée, et apprend à ignorer le rouge.
Et le voyant comptait comme « bloqué » ce qui attendait sagement son heure.
Un message peut être délibérément programmé plus tard : envoi différé demandé par le client, ou report décidé par le palier de chauffe. Le compteur « en souffrance » le jugeait sur sa date de création, donc un envoi prévu pour demain s’affichait en rouge aujourd’hui. Deux règles différentes cohabitaient sans le savoir : l’une pour dire « en retard », l’autre pour choisir quoi expédier. C’est la garantie d’un écran qui ment un jour. Elles n’en font plus qu’une.
Un détail vous a gêné, ou vous a coûté du temps ? Répondez ici plutôt
que par courrier : la réponse servira aussi aux suivants.