La file monte. Pas un pic—une montée régulière. Cette pente lente et soutenue qui dit «quelque chose est cassé, mais poliment».
Pendant ce temps les utilisateurs signalent «des e-mails en retard», le marketing s’apprête à lancer une campagne, et les invitations du CEO arrivent avec du retard.
Une file d’attente croissante est rarement le problème. C’est le symptôme visible d’un goulet d’étranglement : DNS, handshakes TLS, limites distantes,
latence du disque local, meltdown du resolveur, problème de réputation, ou un changement de configuration bien intentionné qui a transformé votre MTA en pont à voie unique.
Voici comment trouver le coupable avant que le mail s’arrête—et avant d’apprendre votre propre incident via une capture d’écran transférée.
Comment les files d’attente augmentent (et pourquoi elles continuent d’augmenter)
Un serveur SMTP est comme un tapis roulant. Le courrier entrant arrive ; le courrier sortant est tenté ; les échecs sont différés ; les réessais ont lieu plus tard.
Quand les livraisons échouent plus vite qu’elles ne se rétablissent—ou quand vous ne pouvez pas tenter les livraisons assez rapidement—la file s’accumule.
Une courbe de croissance de la file vous indique la classe du problème :
- Croissance linéaire : vous livrez une partie des mails, mais le débit est inférieur au taux d’arrivée. Pensez à un throttling distant, une concurrence trop faible, ou une lenteur de stockage.
- Augmentation en palier puis plateau : une panne temporaire ou un défaut DNS/TLS. Ça s’accumule, puis ça se résorbe quand c’est réparé.
- Croissance explosive : échecs généralisés (resolver en panne, egress bloqué, disque plein), ou une tempête de mails (boucle, application mal configurée, compte compromis).
- «Différé» domine : vous tentez les livraisons, mais les systèmes distants rejettent ou expirent.
- «Actif» domine : le traitement local est bloqué—souvent disque, verrous, filtrage de contenu, ou un processus enfant mort.
La plupart des MTA sont conservateurs par conception : ils n’assaillent pas sans fin les serveurs distants, et ils continuent d’essayer pendant des heures ou des jours.
C’est bon pour la fiabilité. C’est aussi comme ça que vous vous retrouvez avec 600k messages en attente pendant que le problème sous-jacent persiste discrètement.
Voilà la vérité opérationnelle : votre objectif n’est pas «vider la file». Votre objectif est «restaurer un débit stable» pour que la file se résorbe naturellement.
Si vous vous concentrez d’abord sur la suppression des messages, vous supprimerez des preuves et conserverez le goulet d’étranglement.
Playbook de diagnostic rapide
Quand la file augmente, vous n’avez pas le temps pour une fouille archéologique tranquille. Vous avez besoin d’une séquence serrée qui sépare en quelques minutes «rejets distants»
de «blocage local» de «réseau/DNS/TLS».
Première étape : classer l’arriéré (différé vs actif, âge du plus ancien, raison dominante)
- La file est-elle majoritairement différée ? C’est souvent réseau/DNS/TLS/politique distante.
- Est-elle majoritairement active ? C’est souvent une contention de ressources locales (disque, CPU, filtre de contenu), ou un processus coincé.
- Quel est l’âge du plus ancien message ? S’il a des jours, vous avez un mode d’échec persistant ou un calendrier de réessai trop long pour votre activité.
Deuxième étape : confirmer la santé locale (disque, latence I/O, exhaustion d’inodes, resolveur)
- Vérifiez l’espace disque et l’utilisation des inodes là où la file réside.
- Vérifiez iowait et la latence du stockage ; les files mail font beaucoup d’écritures de petits fichiers.
- Validez la vitesse et la justesse de la résolution DNS depuis l’hôte MTA.
Troisième étape : confirmer le chemin sortant (egress port 25, handshakes TLS, limites distantes)
- Testez la connectivité TCP basique vers des destinations connues sur le port 25.
- Vérifiez les échecs TLS et les timeouts ; ceux-ci peuvent sérialiser les tentatives de livraison.
- Recherchez des motifs «421 Try again later», «4.7.0 rate limited», ou «temporarily deferred».
Quatrième étape : confirmez que vous n’êtes pas la source du problème (boucles, inondations, mauvais réessais)
- Identifiez les principaux expéditeurs et destinataires dans la file. Une seule appli peut empoisonner la source.
- Recherchez des doublons, des réponses automatiques, ou des boucles de rebonds.
- Vérifiez si les fichiers de la file tournent (taux d’écriture élevé) sans progression de livraison.
Cinquième étape : ajuster en sécurité (augmenter la concurrence seulement après avoir corrigé le goulet)
Augmenter la concurrence avant d’avoir réparé le DNS ou le disque, c’est comme ajouter des voies à une autoroute qui se termine par un pont-levis.
Vous aurez juste plus de voitures qui attendent plus vite.
Faits intéressants et contexte historique
- SMTP précède la plupart des «emails d’entreprise» : la RFC 821 (1982) a standardisé SMTP quand Internet était encore principalement des réseaux de recherche.
- «Store-and-forward» est tout l’objet : les réseaux précoces étaient peu fiables, donc la mise en file et les réessais étaient conçus dès le départ.
- Les files mail sollicitent fortement le système de fichiers : les MTA classiques stockent chaque message comme un ou plusieurs fichiers ; cela fait de la latence disque un facteur de premier plan.
- Le DNS est devenu une dépendance critique plus tard : les enregistrements MX et le routage DNS ont déplacé la livraison des tables hôtes statiques vers un système dépendant du resolveur.
- Le greylisting a popularisé les différes : au début des années 2000, beaucoup de serveurs utilisaient le «réessayez plus tard» pour réduire le spam, apprenant la patience aux MTA.
- TLS a ajouté de la complexité CPU et de handshake : STARTTLS a amélioré la confidentialité, mais a introduit de nouveaux modes de défaillance—timeouts, incompatibilités de chiffrements, intermédiaires défectueux.
- L’antispam a transformé la livraison en politique : les «4xx deferrals» modernes reflètent souvent un score de réputation, pas une infrastructure cassée.
- Les IDs de file sont devenus des artefacts judiciaires : la capacité à tracer un message unique à travers les réessais est l’une des fonctionnalités opérationnelles les plus utiles des MTA.
Une citation à garder sur un post-it près de votre terminal :
idée paraphrasée
de Richard Cook : «Le succès rend les systèmes simples ; l’échec révèle la réalité désordonnée de la manière dont le travail se déroule réellement.»
Tâches pratiques : commandes, sorties, décisions
Les tâches ci-dessous supposent un serveur mail Linux. La plupart des exemples utilisent Postfix parce qu’il est courant, mais la logique se transpose à Exim et Sendmail.
Chaque tâche inclut : commande, sortie d’exemple, ce que cela signifie, et la décision à prendre ensuite.
Tâche 1 : Mesurer la taille de la file et sa répartition (Postfix)
cr0x@server:~$ mailq | tail -n 20
-- 5234 Kbytes in 412 Requests.
-- 18452 Kbytes in 1923 Requests.
-- 23686 Kbytes in 2335 Requests.
Sens : Postfix affiche les totaux par répertoire de file vers la fin ; plusieurs lignes peuvent apparaître selon la configuration et les groupes de files.
Le signal clé est le nombre de requêtes et s’il augmente dans le temps.
Décision : Si les requêtes augmentent, ne touchez pas encore à la concurrence. Passez à l’analyse des raisons (Tâche 3) et à la santé locale (Tâche 5/6).
Tâche 2 : Obtenir un résumé structuré de la file (Postfix)
cr0x@server:~$ postqueue -p | head -n 20
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5* 1487 Thu Jan 3 10:21:52 alerts@example.com
user@remote.tld
F6G7H8I9J0 9210 Thu Jan 3 10:22:01 billing@example.com
finance@remote.tld
-- 23686 Kbytes in 2335 Requests.
Sens : Un astérisque indique généralement que le message est dans la file active (en cours de tentative). Pas d’astérisque signifie souvent différé.
Décision : Si vous voyez beaucoup de messages actifs mais peu de progression, suspectez un goulet local ou des processus de livraison bloqués. Allez aux Tâches 8 et 9.
Tâche 3 : Extraire les raisons dominantes de déferrals depuis les logs
cr0x@server:~$ sudo grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 20
Jan 3 10:23:10 server postfix/smtp[21944]: A1B2C3D4E5: to=<user@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=120, delays=0.2/0.1/60/59, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.7]:25: Connection timed out)
Jan 3 10:23:12 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, delays=0.2/0.1/30/59, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)
Sens : La raison est dans les parenthèses. Les timeouts crient réseau/egress/DNS ; les 421/4.7.0 évoquent souvent du throttling ou un problème de réputation.
Le découpage delays= est de l’or : il vous dit où le temps a été passé (avant le gestionnaire de file, DNS, connexion, transmission).
Décision : Si la raison dominante est un timeout de connexion, testez la connectivité (Tâche 11). Si c’est 421/4.7.0, vérifiez les schémas d’envoi et le throttling distant (Tâche 14).
Tâche 4 : Compter rapidement les differrals par raison
cr0x@server:~$ sudo grep "status=deferred" /var/log/mail.log | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
842 connect to mx.remote.tld[203.0.113.7]:25: Connection timed out
311 host mx.other.tld[198.51.100.9] said: 421 4.7.0 Try again later
97 TLS is required, but our TLS engine is unavailable
52 lost connection with mx.third.tld[192.0.2.10] while receiving the initial server greeting
Sens : C’est votre carte thermique. Si une raison domine, vous avez un goulet que vous pouvez nommer.
Décision : Corrigez la raison principale en premier. Les problèmes de file suivent souvent la loi de Pareto : une cause provoque la plupart des douleurs.
Tâche 5 : Vérifier l’espace disque là où Postfix stocke les files
cr0x@server:~$ df -h /var/spool/postfix
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 40G 38G 1.2G 97% /
Sens : 97% d’utilisation n’est pas «acceptable». Les files mail ne gèrent pas bien un système de fichiers serré : les performances chutent, le nettoyage devient étrange, et vous risquez un arrêt complet.
Décision : Libérez de l’espace immédiatement ou déplacez les spools vers un système de fichiers plus grand. Ensuite enquêtez pourquoi le volume s’est rempli (logs, mails bloqués, core dumps).
Tâche 6 : Vérifier l’exhaustion d’inodes (le tueur silencieux)
cr0x@server:~$ df -i /var/spool/postfix
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda2 2621440 2619000 2440 100% /
Sens : Vous pouvez avoir des octets libres et être quand même HS. Un spool mail crée beaucoup de petits fichiers ; l’exhaustion d’inodes empêche la création de fichiers et casse les livraisons.
Décision : Réduisez le nombre de fichiers (supprimez les anciens logs, faites une rotation agressive, videz la file) et planifiez un système de fichiers avec plus d’inodes (ou une autre disposition de stockage).
Tâche 7 : Déterminer si vous êtes lié par l’I/O (iowait et latence)
cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 01/03/2026 _x86_64_ (4 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.31 0.00 5.01 48.22 0.00 34.46
Device r/s w/s rKB/s wKB/s avgrq-sz avgqu-sz await svctm %util
sda 4.00 220.00 120.0 9800.0 86.2 9.8 44.10 3.20 72.00
Sens : Un iowait élevé et un await élevé signifient que votre disque ne suit pas. Les files mail sont sensibles au comportement fsync sur petits fichiers.
Décision : Arrêtez de tuner Postfix en premier. Réparez le stockage : déplacez le spool sur un disque plus rapide/SSD, réduisez les I/O concurrentes, ou ajustez la politique de stockage de la VM.
Tâche 8 : Vérifier la santé du service Postfix et la saturation des processus
cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
Active: active (running) since Thu 2026-01-03 09:01:02 UTC; 1h 22min ago
Main PID: 1021 (master)
Tasks: 68 (limit: 18945)
Memory: 212.4M
CPU: 18min 12.301s
Sens : «Active (running)» est nécessaire mais pas suffisante. L’important est de savoir si les processus enfants sont coincés ou en train de respawner.
Décision : Si le CPU est élevé et la file ne se résorbe pas, vérifiez si un filtre de contenu ou un démon de politique bloque. Si le CPU est faible mais la file élevée, suspectez l’I/O ou des differrals distants.
Tâche 9 : Chercher des processus smtp bloqués et des durées d’exécution longues
cr0x@server:~$ ps -eo pid,etime,cmd | grep -E "postfix/smtp|postfix/local" | head
21944 00:10:12 postfix/smtp -t unix -u -c
21947 00:09:58 postfix/smtp -t unix -u -c
21950 00:00:03 postfix/local -t unix -u
Sens : Beaucoup de processus smtp avec un temps écoulé long suggèrent des blocages de connexion/TLS ou des tar-pitting distants.
Décision : Consultez le découpage des délais dans les logs (Tâche 3) et testez TCP/TLS depuis cet hôte (Tâche 11, Tâche 12).
Tâche 10 : Vérifier la vitesse et la justesse de la résolution DNS
cr0x@server:~$ dig +tries=1 +time=2 mx remote.tld
;; ANSWER SECTION:
remote.tld. 300 IN MX 10 mx.remote.tld.
remote.tld. 300 IN MX 20 mx2.remote.tld.
;; Query time: 1789 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Jan 03 10:25:55 UTC 2026
Sens : Près de 2 secondes pour une simple recherche MX, c’est mauvais. Multipliez cela par des milliers de livraisons et vous obtenez une file.
Décision : Corrigez la latence du resolveur : vérifiez systemd-resolved/unbound, le DNS amont, la perte de paquets, ou des domaines de recherche mal configurés.
Tâche 11 : Tester la connectivité sortante sur le port 25 (ne devinez pas)
cr0x@server:~$ nc -vz -w 3 mx.remote.tld 25
Connection to mx.remote.tld (203.0.113.7) 25 port [tcp/smtp] succeeded!
Sens : Le TCP fonctionne. Si vous avez encore des timeouts dans Postfix, suspectez une perte de paquets intermittente, des pare-feux stateful, ou l’épuisement des ressources de concurrence.
Décision : Si le TCP échoue, escaladez au réseau : ACL egress, blocages SMTP chez le fournisseur, épuisement de la table NAT, ou filtrage en amont.
Tâche 12 : Tester le handshake STARTTLS vers un MX distant
cr0x@server:~$ openssl s_client -starttls smtp -connect mx.remote.tld:25 -servername mx.remote.tld -brief < /dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx.remote.tld
Verification: OK
250 SMTPUTF8
Sens : Le handshake TLS est sain. Si les logs Postfix montrent des échecs TLS, suspectez le bundle CA local, un mismatch SNI, ou un OpenSSL ancien.
Décision : Si le handshake bloque, réduisez temporairement les timeouts DNS/TLS et enquêtez sur les middleboxes qui cassent STARTTLS.
Tâche 13 : Identifier les principaux expéditeurs dans la file (qui vous inonde)
cr0x@server:~$ postqueue -p | awk 'NR%2==1{print $7}' | sed 's/[<>]//g' | sort | uniq -c | sort -nr | head
8123 noreply@app.internal
1432 alerts@example.com
611 billing@example.com
Sens : Un expéditeur qui génère la majorité des mails en file indique généralement un changement d’application, une tempête de réessais, ou des identifiants compromis.
Décision : Appliquez un rate-limit ou bloquez temporairement le principal fautif, et contactez l’équipe propriétaire. Stabilisez le débit avant de «réparer l’email».
Tâche 14 : Identifier les principales destinations (qui vous rejettent)
cr0x@server:~$ postqueue -p | awk 'NR%2==0{print $1}' | sed 's/[<>]//g' | awk -F@ '{print $2}' | sort | uniq -c | sort -nr | head
9321 remote.tld
2210 other.tld
809 bigmail.example
Sens : Si un domaine domine, vous pouvez cibler : vérifiez la joignabilité de leurs MX, votre réputation, leurs messages de déferral, et votre taux d’envoi vers eux.
Décision : Appliquez des limites de concurrence par destination ou ralentissez vers ce domaine, plutôt que de pénaliser tous les autres destinataires.
Tâche 15 : Inspecter un message spécifique en file (Postfix)
cr0x@server:~$ sudo postcat -q A1B2C3D4E5 | sed -n '1,30p'
*** ENVELOPE RECORDS ***
message_size: 1487 1487
message_arrival_time: Thu Jan 3 10:21:52 2026
sender: alerts@example.com
*** MESSAGE CONTENTS ***
Received: from app.internal (app.internal [10.0.10.5])
by server with ESMTP id A1B2C3D4E5
for <user@remote.tld>; Thu, 03 Jan 2026 10:21:52 +0000 (UTC)
Subject: Alert: backend latency
Sens : Confirme l’expéditeur, le destinataire, et le passage interne. Utile pour détecter des boucles mail, de l’usurpation, ou un locataire spécifique qui génère de la charge.
Décision : Si vous repérez une boucle (en-têtes Received répétées), arrêtez-la à la source et purgez les messages affectés.
Tâche 16 : Confirmer la taille du répertoire de file et le nombre de fichiers
cr0x@server:~$ sudo du -sh /var/spool/postfix/deferred /var/spool/postfix/active
3.8G /var/spool/postfix/deferred
126M /var/spool/postfix/active
cr0x@server:~$ sudo find /var/spool/postfix/deferred -type f | wc -l
198234
Sens : Si le différé domine, vous attendez surtout des conditions distantes (ou DNS/TLS/egress). Le nombre de fichiers compte pour les inodes et le coût de parcours des répertoires.
Décision : Si le nombre de fichiers est massif et que les inodes sont tendus, priorisez la vidange ou le déplacement du spool ; puis réduisez le flux entrant (rate limit) pour éviter l’effet spirale.
Tâche 17 : Surveiller le taux de vidage de la file en temps réel
cr0x@server:~$ watch -n 5 "postqueue -p | tail -n 1"
Every 5.0s: postqueue -p | tail -n 1
-- 23686 Kbytes in 2335 Requests.
Sens : Vous vous souciez de la pente, pas d’un seul nombre. Si ce nombre ne baisse pas après votre correctif, vous n’avez pas corrigé le goulet.
Décision : Si ça baisse régulièrement, cessez de toucher aux choses. Laissez-la se résorber. Votre travail est d’éviter d’empirer la situation.
Tâche 18 : Vérifier si vous êtes throttlé ou tarpitté par des serveurs distants
cr0x@server:~$ sudo grep "said: 4" /var/log/mail.log | tail -n 20
Jan 3 10:24:01 server postfix/smtp[21947]: F6G7H8I9J0: to=<finance@remote.tld>, relay=mx.remote.tld[203.0.113.7]:25, delay=90, dsn=4.7.0, status=deferred (host mx.remote.tld[203.0.113.7] said: 421 4.7.0 Try again later)
Sens : Un 4xx est un différé temporaire ; la partie distante vous demande explicitement de ralentir ou de revenir plus tard.
Décision : Réduisez la concurrence par destination et le taux d’envoi ; si vous opérez du mail en masse, segmentez ce trafic vers un host/IP sortant dédié.
Blague #1 : Le mail est le seul système où «réessayez plus tard» est à la fois une fonctionnalité du protocole et une stratégie de soutien émotionnel.
Goulets d’étranglement et modes de défaillance courants
1) Goulets disque et système de fichiers (le classique)
Les spools mail sont des usines à petits fichiers. Vous avez des opérations métadonnées, des fsyncs, des recherches de répertoire, et beaucoup de «écrire un peu, renommer, unlink».
Si votre file est sur un stockage réseau lent, des disques VM surchargés, ou un système de fichiers presque plein, les livraisons ralentiront même si le CPU est inactif.
Indicateurs spécifiques au stockage :
- Iowait élevé,
awaitélevé, débit modeste. - Les processus du gestionnaire de file se bloquent sur l’I/O ; «actif» croît et reste élevé.
- Les écritures de logs accusent du retard ; les horodatages dans les logs sautent.
Que faire :
- Déplacez le spool sur un SSD local quand c’est possible.
- Gardez
/varspacieux ; 20% libre n’est pas du luxe, c’est du bon sens opérationnel. - Évitez de colocaliser les spools mail avec des systèmes très générateurs de logs, des environnements de staging de sauvegarde, ou tout ce qui effectue de larges écritures séquentielles.
2) Lenteur du resolveur DNS (mort par mille requêtes)
Chaque livraison sortante implique le DNS : recherche MX, A/AAAA, parfois TLSA, parfois des vérifications SPF/DMARC selon votre configuration.
Si votre resolveur est lent, vous sérialisez effectivement les livraisons.
Causes typiques :
- systemd-resolved qui relaie vers un DNS amont instable.
- Pare-feu qui laisse tomber des fragments ou des réponses UDP (problèmes EDNS).
- Domaines de recherche qui provoquent un churn NXDOMAIN répété.
- Mauvais comportement IPv6 : les recherches AAAA réussissent, mais la connectivité v6 réelle est cassée.
3) Blocs egress réseau et restrictions SMTP du fournisseur
Beaucoup de clouds bloquent le port 25 sortant par défaut. Certains pare-feu d’entreprise interceptent «à leur manière» le SMTP et font je-ne-sais-quoi.
Symptômes : timeouts de connexion, succès sporadiques, ou «No route to host».
La correction n’est presque jamais «tuner Postfix». C’est : ouvrez le port, utilisez le relais correct, ou routez le mail via un smarthost approuvé.
4) Échecs de handshake TLS et incompatibilités de politique
STARTTLS est opportuniste dans beaucoup de configurations, mais de plus en plus obligatoire dans certains environnements. TLS introduit :
erreurs de vérification de certificat, timeouts de handshake, incompatibilités de suites de chiffrement, et même des bugs dans de vieilles bibliothèques.
Surveillez :
TLS is required, but our TLS engine is unavailableSSL_accept error,no shared cipher- Longs délais pendant la phase de connexion/handshake dans les logs.
5) Limites de débit distantes et déferrals liés à la réputation
Le côté distant peut être sain. Ils ne vous aiment juste pas pour le moment.
Pics de volumétrie, nouvelles IP d’envoi, SPF/DKIM/DMARC mal alignés, ou schémas de rebond inhabituels peuvent déclencher du throttling.
Approche opérationnelle :
- Séparez les flux transactionnels et les flux bulk (hôte/IP distinct si possible).
- Implémentez un pacing par domaine et des plafonds de concurrence.
- Arrêtez les tempêtes de réessais provenant d’applications qui traitent SMTP comme une file de messages (ce n’est pas le cas).
6) Filtrage de contenu et milters (la sérialisation cachée)
L’analyse antispam/AV est coûteuse. Si vous faites passer tout le mail par une seule instance de filtre, vous pouvez créer un goulet qui ressemble à «SMTP lent».
Aussi : quand le filtre échoue, les MTA ont tendance à différer—la file croît—et l’équipe filtre dira «ça marche sur mon portable».
Traitez les filtres comme toute autre dépendance : capacity plan, surveillez, et échouez en sécurité (avec une politique explicite).
7) Mauvaise configuration du calendrier de réessai et durée de vie de la file
Si vous réessayez trop agressivement, vous amplifiez les pannes et vous vous faites plus fortement limiter. Si vous réessayez trop lentement, vous accumulez du retard et manquez les SLA métier.
La durée de vie de la file compte aussi : garder du courrier indésirable pendant des jours gaspille disque et attention.
Blague #2 : La file mail est comme votre abonnement à la salle de sport—si vous l’ignorez assez longtemps, elle sera toujours là, vous jugeant en silence.
Trois mini-récits d’entreprise tirés du terrain
Mini-récit 1 : L’incident causé par une fausse hypothèse
Une entreprise moyenne faisait tourner Postfix sur une paire de VMs derrière un load balancer. Ils avaient l’hypothèse «l’email sortant n’est pas critique, on peut toujours renvoyer». Cette hypothèse a tenu jusqu’à la semaine de paie.
La file a commencé à croître lentement après un changement réseau. Les logs montraient des timeouts de connexion vers une poignée de domaines, mais pas tous.
L’ingénieur d’astreinte a supposé que les domaines distants étaient instables et a attendu. Au matin, la file différée était massive et le disque presque plein.
Puis Postfix a commencé à lancer des erreurs liées à la création et au nettoyage de fichiers.
Le vrai problème était embarrassant : le port 25 sortant était bloqué sur une des gateways NAT pendant le déploiement d’une règle de pare-feu.
La moitié du trafic réussissait ; l’autre moitié faisait timeout. Le schéma de «succès partiel» a trompé tout le monde.
Parce que les réessais étaient conservateurs, les échecs se sont accumulés silencieusement.
La correction n’a rien d’héroïque : corriger les règles de pare-feu, vider la file, et ajouter un contrôle synthétique qui teste TCP/25 sortant depuis chaque nœud chaque minute.
La leçon a été plus précieuse que l’incident : ne supposez jamais que «quelques mails passent» signifie «le mail est OK».
Mini-récit 2 : L’optimisation qui a mal tourné
Une autre organisation avait de vrais problèmes de débit. Le marketing voulait une livraison de campagne plus rapide ; l’ingénierie voulait moins de plaintes.
Quelqu’un a augmenté la concurrence et le parallélisme Postfix globalement. La file s’est vidée plus vite—pendant environ une heure.
Puis les differrals distants ont commencé : beaucoup de 421 et 4.7.x «try again later». Les destinations majeures ont commencé à tar-pitter les connexions.
Le MTA a réagi en maintenant de nombreux processus smtp ouverts, chacun attendant une salutation ou une réponse lente.
Le CPU a monté, mais pire, l’utilisation des descripteurs de fichiers a grimpé et la machine a commencé à se comporter bizarrement.
Pendant ce temps le filtre de contenu (un milter) recevait des rafales qu’il n’était pas conçu pour traiter.
Il a commencé à timeouter, ce qui a provoqué plus de differrals, ce qui a généré plus de réessais, ce qui a augmenté les rafales.
C’est comme ça qu’on construit une boucle de rétroaction : prenez un système déjà sous tension et «optimisez» jusqu’à l’auto-dommage.
La récupération a nécessité de réduire la concurrence, d’ajouter des limites par domaine, et de scaler la couche de filtres.
La correction à long terme a été politique : les changements de débit mail exigent des tests de capacité et un plan de rollback, pas un «bump» un vendredi après-midi.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une société financière exploitait une petite flotte de MTAs sortants. Rien de fancy—juste de la discipline.
Ils gardaient les spools sur SSD locaux, faisaient une rotation agressive des logs, pointaient les resolveurs DNS vers des instances connues fiables, et surveillaient la distribution d’âge de la file.
Un jour un resolveur amont a commencé à échouer de façon intermittente. Beaucoup de systèmes de l’entreprise ont eu des problèmes, mais la flotte mail n’est pas tombée.
Leurs tableaux de bord montraient la latence des requêtes DNS augmenter, mais la file est restée stable.
Pourquoi ? Ils avaient un resolveur cache local sur chaque hôte mail avec des timeouts sensés et un cache chaud.
Ils avaient aussi des alertes non seulement sur la taille de la file, mais sur «l’âge du plus ancien message différé» et la «cardinalité des raisons de déferral».
Ces alertes ont déclenché tôt, alors que la file était encore gérable.
La correction a été un changement contrôlé des resolveurs amonts et une réduction temporaire de la concurrence sortante pour éviter d’amplifier les timeouts DNS.
Pas d’appel de crise. Pas de panique des dirigeants. Juste des opérations ennuyeuses qui font ce qu’elles savent faire de mieux : prévenir le drame.
Erreurs courantes (symptôme → cause racine → fix)
-
Symptôme : La file croît, majoritairement différée, avec «connect timed out».
Cause racine : TCP/25 sortant bloqué, routage intermittent, ou épuisement de la table NAT.
Fix : Validez TCP/25 avecnc; vérifiez la politique pare-feu/egress ; confirmez la capacité NAT ; envisagez un relais smarthost. -
Symptôme : La file croît, «Try again later» (421/4.7.0) domine.
Cause racine : Limitation de débit distante ou throttling de réputation ; schémas d’envoi en rafales.
Fix : Ralentissez par domaine, segmentez le trafic, réduisez la concurrence, nettoyez l’authentification (SPF/DKIM/DMARC) et la gestion des rebonds. -
Symptôme : File active élevée, CPU bas, iowait élevé.
Cause racine : Latence disque sur le volume spool ; stockage surchargé ; système de fichiers presque plein.
Fix : Déplacez le spool vers un stockage plus rapide ; libérez espace/inodes ; isolez des autres I/O ; vérifiez aveciostat. -
Symptôme : Échecs sporadiques, longs délais avant la connexion, temps de requête DNS élevé.
Cause racine : Latence du resolveur, problèmes EDNS/fragmentation, domaines de recherche mal configurés.
Fix : Corrigez le chemin DNS ; exécutez un cache local ; baissez les timeouts resolveur ; vérifiez les temps avecdig. -
Symptôme : Differrals liés à TLS apparaissent soudain après une mise à jour OS ou un changement de certificat.
Cause racine : Mismatch du bundle CA, changements OpenSSL, politique TLS exigée sans support.
Fix : Retestez avecopenssl s_client; vérifiez le magasin CA ; ajustez la politique TLS prudemment, pas émotionnellement. -
Symptôme : La file est énorme, mais un seul expéditeur interne domine.
Cause racine : Tempête de réessais d’une appli, logique de queue défectueuse, ou compte compromis envoyant du spam.
Fix : Limitez le débit de l’expéditeur au niveau MTA ; bloquez temporairement ; corrigez le comportement de l’appli ; renouvelez les identifiants. -
Symptôme : La file croît et les logs montrent «warning: database is locked» ou similaire pour des maps.
Cause racine : Maps de recherche en contention (ex. bases locales), fichiers map montés en NFS, ou LDAP lent.
Fix : Déplacez les maps localement, changez de backend map, mettez en cache les recherches, et isolez les dépendances. -
Symptôme : La file se vide extrêmement lentement même après la correction réseau.
Cause racine : Calendrier de réessai trop conservateur ; trop peu de workers smtp ; limites par domaine trop strictes.
Fix : Augmentez temporairement la concurrence et le taux de livraison après la disparition du goulet ; surveillez le taux d’erreur et les differrals distants.
Listes de vérification / plan étape par étape
Checklist A : Premières 10 minutes (confinement et collecte de signaux)
- Photographiez la situation. Enregistrez la taille de la file, l’âge du plus ancien message (si vous le suivez), et les principales raisons de differrals (Tâche 1–4).
- Confirmez disque local et inodes. Si l’un ou l’autre est critique, corrigez cela en priorité (Tâche 5–6). Un disque plein transforme un problème de livraison en perte de données.
- Vérifiez la latence DNS et le TCP/25 sortant. Validez depuis l’hôte MTA, pas depuis votre portable (Tâche 10–12).
- Identifiez le principal expéditeur et les principaux domaines destinataires. Contenez une inondation tôt (Tâche 13–14).
- Communiquez. Informez les parties prenantes : «La livraison sortante est retardée ; l’acceptation entrante fonctionne toujours (ou pas). Prochain point dans 30 minutes.»
Checklist B : Stabiliser le débit (arrêter l’hémorragie)
- Réduisez l’entrée si nécessaire. Si une appli unique inonde, throttlez-la au MTA ou pare-feu. Oui, on va vous crier dessus ; faites-le quand même.
- Corrigez la raison de differral principale. Ne poursuivez pas dix petits problèmes quand un seul domine (Tâche 4).
- Privilégiez le tuning par destination plutôt que global. Si un domaine vous bride, ne pénalisez pas tous les autres.
- Assurez la santé I/O du spool. Déplacez les files vers un stockage rapide si nécessaire ; les files ne sont pas un endroit pour être «économe».
- Vérifiez le taux de vidage. Surveillez la pente (Tâche 17). Si la pente s’améliore, cessez de trifouiller.
Checklist C : Récupération et nettoyage (après début de vidage)
- Confirmez le comportement des rebonds. Assurez-vous de ne pas générer de backscatter ou de boucles de rebond.
- Validez la politique de réessai. Assurez-vous de ne pas conserver des messages pendant des jours que l’entreprise ne juge plus utiles.
- Contrôles post-incident. Ajoutez des alertes sur l’âge de la file et les raisons de différal, pas seulement la longueur de la file.
- Faites un petit test de charge. Si vous avez changé la concurrence ou déplacé le spool, vérifiez que vous n’avez pas créé un nouveau goulet.
- Documentez les «top 3» causes et contrôles. Le vous du futur n’est pas aussi brillant à 03:00.
FAQ
1) Dois-je simplement vider la file ?
Seulement après avoir corrigé le goulet sous-jacent. Vider une infrastructure cassée augmente la charge sur la partie défaillante et peut aggraver les differrals ou déclencher des throttles distants.
Le flush est un outil de récupération, pas de diagnostic.
2) Quand est-il acceptable de supprimer des mails en file ?
Lorsqu’ils sont clairement abusifs (inondation de spam), manifestement obsolètes (expiration approuvée par le métier), ou quand disque/inodes risquent de faire tomber le serveur.
Supprimez avec intention : identifiez par expéditeur, destination, ou âge. Ne purge pas au hasard en espérant le meilleur.
3) Pourquoi la file est majoritairement différée et pas active ?
Différé signifie que des tentatives ont eu lieu et ont échoué temporairement. C’est généralement la politique distante, DNS/TLS/egress, ou des dépendances de filtrage de contenu qui ont refusé le mail.
Une domination de la file active pointe plus vers un traitement local ou des contraintes d’I/O.
4) Comment savoir si le DNS est le goulet ?
Mesurez le temps de recherche depuis l’hôte mail avec dig. Si les recherches MX prennent des centaines de millisecondes à des secondes, c’est suffisant pour plafonner le débit.
Corrélez aussi avec le découpage des délais dans les logs où le temps avant connexion augmente.
5) Un disque presque plein peut-il causer des retards avant d’être réellement plein ?
Oui. Beaucoup de systèmes de fichiers ralentissent lorsque l’espace est limité, et les spools mail amplifient les opérations métadonnées.
Aussi : «presque plein» est la façon dont on finit «soudainement plein» pendant un arriéré.
6) Pourquoi les serveurs distants nous demandent-ils de «réessayer plus tard» ?
Parce qu’ils se protègent : limites de débit, contrôles de réputation, greylisting, ou protection contre la surcharge.
Traitez les 4xx comme un signal de rythme, pas comme une insulte personnelle.
7) Augmenter la concurrence est-il toujours une mauvaise idée ?
Non. C’est simplement souvent mal utilisé. Augmentez la concurrence seulement quand les ressources locales et le réseau sont sains, et quand les differrals distants ne dominent pas.
Préférez un tuning ciblé (par domaine) plutôt qu’un «montez tout».
8) Sur quelles métriques devrais-je alerter en plus de la longueur de la file ?
Alertez sur l’âge du message le plus ancien, le ratio différé/actif, le nombre de raisons de différal principales, la latence de requête DNS depuis le MTA, la marge disque/inodes sur le volume spool,
et les taux de succès TCP/25 sortants.
9) Comment savoir si un filtre de contenu nous ralentit ?
Cherchez des timeouts ou des differrals faisant référence au milter/service de politique, un nombre élevé de connexions vers le filtre, ou une latence croissante dans la partie «avant le gestionnaire de file» du découpage des délais.
Si le filtre sérialise le travail, la file croît même si la connectivité distante est bonne.
10) Pourquoi la file continue-t-elle de croître même après que nous avons «réparé le réseau» ?
Parce que le débit de livraison est encore inférieur au taux d’arrivée, ou parce que les calendriers de réessai font que vous ne retenterez pas beaucoup de messages différés immédiatement.
Surveillez la pente ; ajustez la concurrence prudemment une fois la défaillance primaire résolue.
Prochaines étapes à réellement entreprendre
Si votre file d’e-mails continue d’augmenter, ne la traitez pas comme une masse mystérieuse à «tuner». Traitez-la comme un backlog avec une cause.
Nommez la raison de differral dominante. Vérifiez le disque local et le DNS. Prouvez la connectivité sortante. Identifiez le principal expéditeur et la principale destination.
Puis faites un changement à la fois et regardez la pente.
Étapes pratiques pour la prochaine journée ouvrable :
- Ajoutez des alertes sur l’âge du message différé le plus ancien et sur les principales raisons de différal, pas seulement sur la taille de la file.
- Déplacez ou approvisionnez le spool sur un stockage fiable pour les I/O de petits fichiers. Si cela semble cher, évaluez le coût d’une panne.
- Exécutez un resolveur DNS cache local sur les hôtes mail (ou utilisez des resolveurs amonts connus fiables) et mesurez la latence en continu.
- Implémentez un pacing par destination et séparez le bulk du transactionnel si vous envoyez du volume.
- Rédigez une page de runbook avec le Playbook de diagnostic rapide et les cinq commandes principales que vous lancerez en situation de stress.