La machine ne savait pas s’écrire à elle-même

Publié le 2 octobre 2026.

Un hébergeur nous disait « ralentis » deux cent cinquante-sept fois, et on continuait de frapper.

Signalé par un client : 6 min 30 d’attente avant la première tentative pour un lien de mot de passe oublié. En regardant, pire que ça : des tours de worker de dix-sept à vingt minutes, dont presque tout à attendre des serveurs muets. La file portait 257 messages « 4.7.1 Rate limit due to high number of emails sent » et 166 « mx3.mail.ovh.net ne répond pas ». Insister après un 4.7.1 n’obtient rien : ça prolonge la punition, et c’est exactement le comportement qui fait classer un expéditeur — nous l’étions déjà chez Cloudmark le matin même. Dès qu’un hôte demande qu’on ralentisse ou cesse de répondre, on laisse le reste de sa file pour le passage suivant ; les autres hôtes continuent d’avancer, ce qui est tout l’intérêt du groupage. Un refus ordinaire — une adresse qui n’existe pas — n’arrête rien : il ne dit rien de l’hôte, et s’arrêter là ferait traîner la file pour une seule mauvaise adresse. Et le courrier ne dicte plus la durée du tour : quarante-cinq secondes au plus, le reste repart ensuite. Le débit global ne change pas — seule change la latence du courrier neuf, et c’est la seule qui se remarque. Un « différé » apparaît désormais à part dans le bilan : ce n’est ni un échec ni un report décidé par le serveur distant, c’est nous qui nous arrêtons, et les confondre ferait lire une panne là où il y a de la retenue. Un test a d’ailleurs attrapé une faute dans ce correctif même : le budget était calculé sur l’heure logique du tour, que les essais fixent dans le passé — l’échéance était donc déjà dépassée, et plus aucun message ne serait sorti.

Trois personnes nous ont dit la même chose sans se connaître : on vendait le remède dans la foulée du diagnostic.

Le message de prospection s’ouvrait sur une mesure réelle du domaine, puis enchaînait quatre blocs d’argumentaire. Trois destinataires l’ont dit, chacun de son côté : « Je vous ai écrit sans un problème de mail ! » (27/09), « Rien compris. Pourriez-vous traduire en bon français svp ? » (02/10), et enfin, ironique : « Merci pour ce remarquable message, qui permet à la fois de m’informer que mon domaine présente une configuration perfectible et, dans le même mouvement, de m’expliquer pourquoi votre solution est précisément celle qu’il me faudrait. La boucle est donc parfaitement bouclée. » Il a raison. Un message qui mesure un défaut puis vend le remède dans la même respiration se lit comme un défaut fabriqué, même quand la mesure est exacte — et la nôtre l’est. L’argumentaire ne convainquait donc personne : il discréditait le constat qui le précédait, et ce constat est la seule chose qui donne le droit d’écrire à quelqu’un qui n’a rien demandé. Tout est retiré : l’offre, le paragraphe sur ce que détecte le produit, la recette proposée en fin de message. 2 100 caractères → 744. Restent la mesure, la correction, d’où ça vient, et l’adresse. Un test borne désormais la longueur, et un autre vérifie qu’aucun argumentaire n’y revient sans qu’une mesure le justifie.

Un refus qui revient par courrier vaut un refus tout court.

Signalé sur le forum : 19 avis de non-remise arrivaient dans la boîte d’un client, et le message d’origine restait « livré ». Beaucoup de serveurs acceptent d’abord (250) puis rejettent ensuite, une fois la boîte retrouvée ou le contenu analysé ; le verdict revient alors par courrier, à l’adresse de retour, et pas dans la conversation SMTP. Ne traiter que le refus immédiat, c’est ne voir qu’une moitié de la vérité — la plus facile. Et le dégât dépasse l’inconfort : une adresse morte qu’on ne retire pas est une adresse qu’on réessaie, ce qui est la première cause de réputation détruite — le jour même, notre propre adresse était classée chez Cloudmark avec 327 refus en cinq jours. Les deux signalements n’en faisaient qu’un. Le rapprochement ne devine rien : notre Message-ID porte l’identifiant du message, et l’avis le renvoie ; sans lui, on ne fait rien plutôt que de choisir par l’adresse — deux messages au même destinataire se ressemblent, et poser un rebond sur le mauvais serait pire que de n’en poser aucun. Et un retard n’est pas un rebond : un avis « delayed » dit que le serveur réessaie encore, et condamner l’adresse à ce moment-là serait exactement l’erreur qu’on reproche aux autres. Dix-huit tests tiennent les deux sens.

Cent cinquante-cinq refus nommaient notre propre adresse IP, et étaient imputés aux destinataires.

Signalé sur le forum par un client, chiffres à l’appui. Sur 48 heures : 155 refus « client [5.75.180.201] blocked using Cloudmark CSI » et 72 « Spam detected », tous annoncés « cause : destinataire ». C’est le même défaut que celui corrigé le 28/09 pour Orange, resté ouvert pour les autres fournisseurs — et il tenait à un mot : la règle attrapait « client host … blocked », quand Cloudmark écrit « client [adresse] blocked ». Un écart d’un mot, et cent cinquante-cinq adresses valides accusées. Le piège, pour la troisième fois : élargir à « blocked » tout court aurait attrapé « This mailbox has been blocked due to inactivity », qui désigne une vraie boîte morte — on l’aurait transformée en faute de notre part, donc réessayée indéfiniment, ce qui est la première cause de réputation détruite. Chaque motif a donc été nommé sur les chaînes réelles, et onze cas — six qui nous désignent, cinq qui désignent le destinataire — sont tenus par des tests.

Et un « 0 ouvert » qui voulait dire « on n’a jamais demandé ».

Repéré à l’œil sur le tableau par domaine : letock.fr, 3 514 messages livrés, 0 ouvert, pendant que les autres domaines en comptaient des centaines. L’ouverture se mesure par une image invisible, et une image n’existe que dans du HTML ; or 4 757 des 4 758 messages de ce domaine sont en texte seul — c’est la prospection. Le zéro était donc exact, et il mentait : on le lit « personne n’a ouvert » là où la vérité est « nous n’avons jamais demandé ». La colonne affiche maintenant un tiret quand aucun message ne portait de HTML. Et on ne pose pas de mouchard dans du courrier froid pour faire remonter la colonne : c’est précisément ce qui fait classer un expéditeur, et nous sommes déjà listés chez Cloudmark. On préfère dire qu’on ne sait pas.

Le plafond avait été relevé à 8 000, l’écran l’affichait, et les envois s’arrêtaient à 1 000 pile.

Signalé depuis l’exploitation : tous les envois du jour bloqués, confirmations comprises. Il y avait deux plafonds, et le 28/09 nous n’en avions levé qu’un. Le plafond d’équipe suivait bien le palier de chauffe — vérifié à 8 000 ce jour-là — mais un second contrôle, posé avant que ce plafond n’existe, coupait toujours à la constante de 1 000. Les deux disaient la même chose (« qu’un compte compromis ne vide pas son mois en une nuit ») et le plus grossier gagnait. Ce n’est pas une limite trop stricte, c’est pire : on croyait la limite levée alors qu’elle ne l’était pas, et on a raisonné faux pendant quatre jours en regardant un chiffre qui ne décidait rien. Le contrôle en double est retiré. Il n’était d’ailleurs jamais atteint par une équipe ordinaire — son plafond vaut au plus mille, par construction — il ne mordait que sur les équipes nommément dispensées, c’est-à-dire exactement celles qu’il ne devait pas toucher. Un test garde la borne des équipes ordinaires, pour qu’elle ne disparaisse pas avec le contrôle qui la doublait.

Notre serveur redisait bonjour après le chiffrement, et décalait toutes les réponses d’un cran.

Trouvé en corrigeant le défaut précédent : la connexion passait enfin, et échouait plus loin. La RFC 3207 dit que le protocole « repart dans l’état qui suit un 220 ». Nous avions lu « on renvoie un 220 » — ce n’est pas la même chose : après la poignée de main, c’est au client de parler, avec EHLO. Mesuré avec openssl contre notre propre serveur : la bannière partait une seconde fois, et la réponse à EHLO arrivait donc un cran trop tard. Un client strict lit alors « 220 » là où il attend « 250 », et renonce. Les gros expéditeurs tolèrent, et c’est ce qui rend ce défaut si long à voir : notre courrier entrant fonctionnait, nos écrans étaient verts, et seuls les expéditeurs rigoureux renonçaient — en silence, sans que personne ici n’en entende parler. C’est notre propre client qui l’a révélé, en échouant à écrire à un domaine que nous hébergeons nous-mêmes. Combien d’autres avaient abandonné avant, on ne le saura pas, et c’est précisément le problème : la mise en ligne vérifie désormais ce point à chaque publication.

Un message de LeTock vers un domaine hébergé par LeTock ne partait jamais.

Signalé par un client, avec le détail exact : mx.letock.fr : connect ECONNREFUSED 5.75.180.201:25. Depuis l’extérieur, le même serveur répond parfaitement — c’est ce qui rend la panne si difficile à voir. La réception écoute sur un port non privilégié et une règle du noyau y renvoie le port 25 ; cette règle est posée en PREROUTING, qui par construction ne voit jamais le trafic qui sort de la machine. Le serveur d’envoi composait donc le port 25 de sa propre adresse, où rien n’écoutait. Conséquence pour les clients : toutes les notifications internes vers leur propre domaine — devis, commandes, alertes vers contact@ et admin@ — restaient bloquées sans fin. Le détail qui compte dans le correctif : la redirection évidente renverrait vers la boucle locale, et notre réception verrait alors arriver du courrier depuis 127.0.0.1 au lieu de l’adresse publique — celle que le SPF autorise. Notre propre courrier interne aurait échoué à sa propre vérification, et personne n’aurait relié ça à sa cause. La règle garde donc l’adresse.

Et la remise locale sans SMTP, qui était la correction proposée, a été écartée exprès.

Déposer le message directement dans la boîte quand le domaine est hébergé ici est plus simple, plus rapide, et évite la boucle. C’est aussi deux chemins de remise au lieu d’un : le courrier interne ne traverserait plus la réception — ni ses refus, ni son classement, ni son journal. Le jour où l’un des deux dérive, personne ne le voit, parce que « ça marche quand on envoie de l’extérieur ». Un seul chemin, éprouvé par l’usage réel, vaut mieux qu’un raccourci qu’on serait seuls à emprunter. Et la mise en ligne vérifie désormais que la machine se joint elle-même, parce que cette règle vit hors du dépôt : ce qui vit hors du dépôt se perd, et cette panne-là est silencieuse.

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.