E-mail « message deferred » : déchiffrez pourquoi le courrier est bloqué (et corrigez-le)

Ce que « message deferred » signifie réellement (et ce que cela n’est pas)

Dans l’univers des MTA (Postfix, Exim, Sendmail, le transport SMTP d’Exchange, choisissez votre poison), « deferred » signifie « nous avons tenté la livraison, mais obtenu une erreur temporaire, donc nous réessayerons plus tard. » Ce n’est pas un bounce. Ce n’est pas un succès. C’est un état avec une horloge attachée.

La plupart des déferrals proviennent de réponses SMTP 4xx (temporaires). Pensez : « 421 Service not available », « 450 mailbox unavailable », « 451 local error », « 452 insufficient system storage ». Les MTA traitent cela comme « pas encore de panique ». Ils mettent le message en file et réessaient selon un calendrier. Si les tentatives échouent continuellement et que le message dépasse la durée maximale en file, alors il devient un bounce (5xx) ou une suppression silencieuse si votre configuration est… créativement négligente.

Le « deferred » est un symptôme, pas un diagnostic

« Deferred » vous dit où est le message : toujours dans votre file. Il ne vous dit pas pourquoi. Le « pourquoi » se trouve toujours dans le statut détaillé : une réponse SMTP distante, une défaillance DNS, une erreur de négociation TLS, un timeout, un problème de disque local, un rejet de politique, une limitation de débit, ou l’incapacité de votre MTA à lancer suffisamment de processus de livraison.

Deux déferrals qui paraissent identiques mais ne le sont pas

• Déferral distant : Votre serveur a pu se connecter, le serveur destinataire a dit « réessayez plus tard ». Greylisting, limitation, panne temporaire, arriérés d’analyse de contenu, systèmes de réputation, ou « aujourd’hui on ne vous aime pas. »
• Déferral local : Votre serveur n’a même pas pu tenter correctement la livraison. Résolution DNS en échec, chemin réseau cassé, disque plein, I/O de file lente, bibliothèques TLS défaillantes, ou limites de concurrence atteintes sur votre côté.

L’un est « attendre et réessayer ». L’autre est « vous avez un problème maintenant ». Si vous les traitez pareil, vous ferez rapidement la mauvaise chose.

Une citation pour garder les pieds sur terre : L’espoir n’est pas une stratégie. (Général James N. Mattis)

Blague n°1 : Les files de mail sont comme des piles de linge—les ignorer ne les réduit pas, ça vous évite juste de regarder votre tableau de bord dans les yeux.

Mode d’urgence pour le diagnostic : contrôles 1er/2e/3e niveau

Voici la séquence de triage haute-concentration. Conçue pour la production : minimum de changements de contexte, maximum de clarté. Ne commencez pas par lire 20k lignes de logs. Commencez par localiser le point de congestion.

Premier : la file grossit‑elle, et quelle file ?

• Si c’est la file active qui gonfle, votre MTA essaie mais est bloqué (limitation distante, réseau, TLS, politique, concurrence).
• Si c’est la file deferred qui gonfle, les tentatives échouent et sont reportées (timeouts, 4xx, DNS, pannes distantes).
• Si la maildrop / file de soumission augmente, le mail n’est pas accepté dans la file principale (problèmes de soumission locale, permissions, filtre de contenu tombé, disque, service de nettoyage).

Second : choisissez un message et suivez sa raison d’échec

Sélectionnez un message différé représentatif (pas un destinataire bizarre). Extrait la réponse SMTP exacte ou l’erreur locale. Cette ligne seule raconte souvent 80 % de l’histoire.

Troisième : décidez si c’est une politique distante ou votre infrastructure

Les problèmes de politique distante (greylisting, limitation, réputation, retard côté destinataire) nécessitent de changer de comportement : cadence de retry, réputation IP, lissage du volume, identités DNS correctes, parfois routage via un relais.

Les problèmes d’infrastructure nécessitent de réparer des systèmes : DNS, disque, CPU, réseau, TLS, limites de processus, ou une dépendance cassée comme un filtre de contenu.

Quatrième : arrêtez d’empirer la situation

• Ne « flush » pas la file entière sans cesse. Cela peut amplifier la limitation distante et prolonger la douleur.
• Ne montez pas la concurrence aveuglément. Vous pouvez DDoSser le destinataire et vous faire bloquer encore plus fort.
• Ne redémarrez pas les services en réflexe. Vous pouvez effacer un état crucial et brouiller les preuves.

Cinquième : stabilisez, puis réparez

Stabiliser signifie réduire la croissance du backlog : limiter le débit sortant, mettre en pause les expéditeurs non essentiels, ou router via un relais plus intelligent. Réparer signifie traiter la cause racine : fiabilité DNS, I/O disque, TLS, conformité de politique, ou problèmes de négociation distante.

Faits et contexte intéressants (pourquoi le « deferred » existe)

1. SMTP a été conçu pour des réseaux instables. Les retries sont une fonctionnalité, pas une rustine—store‑and‑forward est l’idée centrale.
2. 4xx vs 5xx est un contrat opérationnel. 4xx dit « réessayer plus tard », 5xx dit « arrêtez ». De nombreux systèmes modernes abusent du 4xx pour vous ralentir sans vous rejeter formellement.
3. Le greylisting a popularisé le « defer » comme défense. Il a armé les retries : les MTA légitimes réessaient; beaucoup de bots spammeurs ne l’avaient pas fait (ou n’attendaient pas).
4. La durée de vie en file varie selon les MTA. Postfix par défaut garde souvent des jours ; cela signifie que « message deferred » peut devenir silencieusement une plainte multi‑journées si vous n’alertez pas.
5. Le DNS fait partie du transport e‑mail, pas des métadonnées optionnelles. Si votre résolveur est cassé, votre mail est cassé. « Message deferred » sera souvent votre seul indice.
6. La préférence MX n’est pas de la répartition de charge. C’est priorité/recours. Les gens continuent à « optimiser » cela en désastre.
7. TLS pour SMTP est opportuniste par défaut. Les échecs STARTTLS peuvent provoquer des déferrals si les politiques exigent le chiffrement ou si des bugs TLS apparaissent après une mise à jour d’OS.
8. Les grands fournisseurs façonnent le trafic avec des 421. Ils peuvent vous différer pour volume, réputation ou pics soudains—même si votre contenu est correct.
9. Les files de mail sont stockées sur disque parce que la RAM oublie. Quand le stockage est lent, l’e‑mail ralentit. Le répertoire de file est une dépendance de performance.

Principaux modes de défaillance derrière les déferrals

1) Échecs temporaires distants (ils sont occupés, prudents ou agacés)

Réponses distantes courantes qui déclenchent des déferrals :

• 421 : service non disponible (maintenance, surcharge, limitation)
• 450/451 : boîte ou erreur locale temporaire
• 452 : espace de stockage insuffisant (oui, leur problème de disque devient votre problème de file)
• 4.7.0 / 4.7.1 : déferrals liés à la politique/réputation (« réessayez plus tard » pendant qu’ils décident si vous êtes spam)

Si le serveur distant vous diffère, la meilleure option est de le respecter. Des retries agressifs tendent à convertir un « déferral temporaire » en « blocage permanent ».

2) Défaillances DNS (la dépendance silencieuse de l’e‑mail)

Symptômes : lignes de log comme « Host or domain name not found », « temporary lookup failure », ou « no MX found ». Causes racines fréquentes :

• Résolveur local cassé / surchargé
• Pare‑feu bloquant l’accès aux DNS amont
• Problèmes de validation DNSSEC
• Mauvaise configuration du domaine de recherche provoquant des timeout bizarres

3) Problèmes de chemin réseau (vous ne pouvez pas les atteindre)

Timeouts de connexion, resets, problèmes de routage, problèmes MTU, tables NAT cassées—tous les classiques SRE avec un message d’erreur en forme de mail. Si vous ne pouvez pas compléter une poignée de main TCP vers le port 25 (ou le 587 vers un relais), vous différerez indéfiniment.

4) Problèmes de négociation TLS/STARTTLS

Les échecs apparaissent comme « TLS handshake failed », « no shared cipher », « certificate verify failed », ou « lost connection after STARTTLS ». Souvent déclenchés par :

• Changements de politique crypto de l’OS après patch
• Politique TLS sortante trop stricte pour le monde réel
• Middleboxes qui font une inspection TLS « utile » mais cassent tout

5) Pénurie de ressources locales (la file étouffe)

Si votre disque est plein, en panne d’inodes, ou douloureusement lent, les messages seront différés parce que le MTA ne peut pas mettre à jour les fichiers de file ou lancer des livraisons de façon fiable. La pression CPU peut aussi provoquer des timeouts et un ralentissement des livraisons. Idem si vous atteignez les limites de processus.

6) Filtres de contenu et milters (la chaîne de dépendances oubliée)

Filtres anti‑spam/virus, DKIM signing, démons de politique, scanners DLP—lorsqu’ils ralentissent ou plantent, votre MTA peut accepter le mail mais différer la livraison, ou ralentir tout dans un backlog. Vous verrez des tempfails qui ressemblent à des problèmes distants mais qui sont en réalité des échecs IPC locaux.

7) Limitation de débit et mauvaise configuration de la concurrence

Postfix et Exim offrent des réglages pour la concurrence par domaine, le taux de connexion et le parallélisme global. Trop bas et vous êtes lent ; trop haut et vous vous faites limiter ou bloquer. La valeur « correcte » varie selon la forme du trafic et le mix des destinataires.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications de base que j’exécute quand quelqu’un dit « le mail est bloqué ». Chaque tâche inclut une commande, une sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Confirm queue size and which queue is growing (Postfix)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C12A1B8       4125 Mon Jan  4 09:01:22  alerts@example.com
(connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
                                         user@gmail.com

7D91B2F04C       2988 Mon Jan  4 09:02:10  noreply@example.com
(host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
                                         ops@partner.tld

-- 2470 Kbytes in 312 Requests.

Signification : Vous avez déjà deux classes de déferrals : timeout réseau vers Google, et 421 de throttling/politique depuis partner.tld.

Décision : Séparez les problèmes. Enquêtez sur la connectivité/timeouts séparément des déferrals de politique destinataire. Une seule correction ne résoudra pas les deux.

Task 2: Summarize queue reasons quickly (Postfix qshape/qgrep style)

cr0x@server:~$ postqueue -p | tail -n +2 | awk '/^[A-F0-9]/{id=$1} /connect to/{print id,$0} /said:/{print id,$0}' | head
3F2C12A1B8 (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
7D91B2F04C (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))
1AA09D0C11 (connect to mx.mail.yahoo.com[98.137.11.163]:25: Connection timed out)

Signification : On voit un motif : timeouts vers des fournisseurs majeurs. Ça sent le pare‑feu egress, le routage, ou un blocage de votre plage IP.

Décision : Cessez de bidouiller les réglages Postfix. Testez la connectivité réseau depuis l’hôte et vérifiez la réputation/routage de votre IP publique.

Task 3: Inspect a single message’s detailed status (Postfix)

cr0x@server:~$ postcat -q 3F2C12A1B8 | sed -n '1,40p'
*** ENVELOPE RECORDS 3F2C12A1B8 ***
message_size:            4125            236               1               0            4125
message_arrival_time: Mon Jan  4 09:01:22 2026
create_time: Mon Jan  4 09:01:22 2026
named_attribute: log_ident=3F2C12A1B8
sender: alerts@example.com
recipient: user@gmail.com
*** MESSAGE CONTENTS 3F2C12A1B8 ***
Received: from app01.example.com (app01.example.com [10.10.10.21])
        by mx01.example.com (Postfix) with ESMTPS id 3F2C12A1B8
        for <user@gmail.com>; Mon,  4 Jan 2026 09:01:22 +0000 (UTC)
Subject: Alert: latency spike

Signification : Confirme l’expéditeur/destinataire et que ce n’est pas un seul destinataire problématique. Confirme aussi que le message a une taille normale et ne déclenche pas un comportement « grand message ».

Décision : Si seuls certains destinataires échouent, traitez‑les comme des politiques par domaine. Si de nombreux domaines échouent, considérez une cause d’infrastructure.

Task 4: Follow the live logs for deferral reasons

cr0x@server:~$ sudo journalctl -u postfix -f
Jan 04 09:06:11 mx01 postfix/smtp[22108]: 3F2C12A1B8: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=289, delays=0.1/0.01/289/0, dsn=4.4.1, status=deferred (connect to gmail-smtp-in.l.google.com[142.250.102.26]:25: Connection timed out)
Jan 04 09:06:14 mx01 postfix/smtp[22110]: 7D91B2F04C: to=<ops@partner.tld>, relay=mx1.partner.tld[203.0.113.10]:25, delay=244, delays=0.1/0.02/30/214, dsn=4.7.0, status=deferred (host mx1.partner.tld[203.0.113.10] said: 421 4.7.0 Try again later (in reply to end of DATA command))

Signification : La répartition delays= est de l’or. Ici, la plupart du temps est passée dans les troisième et quatrième étapes (réseau/TCP et temps de réponse SMTP distant).

Décision : Pour les timeouts, enquêtez réseau/pare‑feu. Pour un 421 à la fin de DATA, suspectez un arriéré d’analyse de contenu ou du throttling : réduisez la concurrence et la cadence de retry par domaine.

Task 5: Validate outbound TCP reachability to port 25

cr0x@server:~$ nc -vz gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com (142.250.102.26) port 25 (tcp) timed out: Operation now in progress

Signification : Ce n’est pas une question de politique SMTP. Vous ne pouvez même pas ouvrir une session TCP.

Décision : Vérifiez les règles de sortie du pare‑feu, les blocages du fournisseur en amont, la capacité NAT, ou le routage. Si vous êtes dans un cloud VPC, confirmez que le port 25 sortant n’est pas bloqué par politique.

Task 6: Confirm routing and source IP used for outbound mail

cr0x@server:~$ ip route get 142.250.102.26
142.250.102.26 via 198.51.100.1 dev eth0 src 198.51.100.23 uid 1000
    cache

Signification : Votre mail sort avec l’IP source 198.51.100.23. C’est l’IP que voient, limitent ou bloquent les fournisseurs distants.

Décision : Si les timeouts/déferrals sont spécifiques à certains fournisseurs, vérifiez si cette IP est sur une plage problématique, ou si votre FAI bloque le 25. Si vous avez plusieurs IP egress, envisagez de basculer SMTP sortant vers une IP propre.

Task 7: Verify DNS resolution reliability (A/MX) from the MTA host

cr0x@server:~$ dig +time=2 +tries=1 mx partner.tld
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14152
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3

;; ANSWER SECTION:
partner.tld.     300 IN MX 10 mx1.partner.tld.
partner.tld.     300 IN MX 20 mx2.partner.tld.

;; Query time: 21 msec
;; SERVER: 10.0.0.53#53(10.0.0.53)
;; WHEN: Mon Jan 04 09:08:44 UTC 2026
;; MSG SIZE  rcvd: 132

Signification : Les réponses DNS sont rapides et propres ici. Si vous observez des timeouts ou des SERVFAIL intermittents, c’est une cause majeure de déferrals.

Décision : Si le DNS est instable, réparez les résolveurs d’abord (caching, accessibilité aux upstream, problèmes DNSSEC). Les MTA dépendent du DNS par conception.

Task 8: Check your own hostname identity and reverse DNS (PTR)

cr0x@server:~$ hostname -f
mx01.example.com

cr0x@server:~$ dig +short -x 198.51.100.23
mx01.example.com.

Signification : L’identité forward et reverse est alignée. Un rDNS mal aligné ne provoque pas toujours des déferrals, mais c’est un ingrédient fréquent dans les « 421 try again later » des récepteurs stricts.

Décision : Si le PTR manque/est erroné, corrigez‑le. N’argumentez pas. Les récepteurs d’e‑mail ne votent pas.

Task 9: Test SMTP conversation and see the real remote behavior

cr0x@server:~$ swaks --to ops@partner.tld --server mx1.partner.tld --timeout 20
=== Trying mx1.partner.tld:25...
=== Connected to mx1.partner.tld.
<--- 220 mx1.partner.tld ESMTP
---> EHLO mx01.example.com
<--- 250-mx1.partner.tld
<--- 250-STARTTLS
---> STARTTLS
<--- 220 2.0.0 Ready to start TLS
=== TLS started with cipher TLS_AES_256_GCM_SHA384
---> MAIL FROM:<test@example.com>
<--- 250 2.1.0 Ok
---> RCPT TO:<ops@partner.tld>
<--- 250 2.1.5 Ok
---> DATA
<--- 354 End data with <CR><LF>.<CR><LF>
---> .
<--- 421 4.7.0 Try again later

Signification : Le distant accepte l’enveloppe mais diffère à la fin de DATA. Cela indique généralement un arriéré d’analyse de contenu, un scoring de politique, ou un shaping de débit qui se déclenche après avoir vu les en‑têtes/le corps.

Décision : Réduisez le débit vers ce domaine, assurez-vous que DKIM/SPF/DMARC sont corrects, et confirmez que vous n’envoyez pas des rafales soudaines. Si c’est un partenaire, coordonnez‑vous avec leur équipe mail.

Task 10: Check local disk space and inode pressure (queue lives on disk)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  900M  98% /var

cr0x@server:~$ df -i /var/spool/postfix
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       2621440 2619000   2440  100% /var

Signification : Vous êtes à court d’inodes. C’est pire que le manque d’espace pour les files mail, car chaque message en file utilise plusieurs petits fichiers.

Décision : Libérez des inodes immédiatement : effacez les fichiers temporaires non essentiels, faites une rotation des logs, déplacez des caches volumineux d’app, ou agrandissez le système de fichiers. Tant que ce n’est pas fait, le mail se comportera comme « mystérieusement cassé ». Ce n’est pas mystérieux. C’est plein.

Task 11: Confirm Postfix services are up and not stuck

cr0x@server:~$ sudo postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 1047

cr0x@server:~$ sudo postconf -n | egrep 'queue_directory|myhostname|myorigin|relayhost|default_process_limit'
queue_directory = /var/spool/postfix
myhostname = mx01.example.com
myorigin = /etc/mailname
relayhost =
default_process_limit = 100

Signification : Sanity baseline : Postfix tourne, le répertoire de file est standard, la limite de processus est 100.

Décision : Si Postfix est arrêté ou instable, corrigez‑le avant toute autre chose. S’il tourne mais diffère, passez au vrai goulot : réseau, disque, DNS, ou politique distante.

Task 12: Check delivery concurrency and per-domain throttling (Postfix)

cr0x@server:~$ sudo postconf -n | egrep 'smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_connect_timeout|smtp_helo_timeout'
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s

Signification : Une concurrence de 20 par destination peut être agressive pour certains récepteurs, surtout si vous avez des rafales.

Décision : Si vous observez beaucoup de 421/4.7.0, réduisez la concurrence par domaine et ajoutez un petit délai de rate. Ne « blast » pas plus fort. C’est comme ça qu’on se fait bloquer.

Task 13: Inspect active SMTP client connections and local exhaustion

cr0x@server:~$ sudo ss -tanp '( dport = :25 )' | head
State  Recv-Q Send-Q Local Address:Port    Peer Address:Port    Process
SYN-SENT 0     1     198.51.100.23:41220  142.250.102.26:25   users:(("smtp",pid=22108,fd=6))
SYN-SENT 0     1     198.51.100.23:41222  98.137.11.163:25    users:(("smtp",pid=22113,fd=6))
ESTAB    0     0     198.51.100.23:41210  203.0.113.10:25     users:(("smtp",pid=22110,fd=6))

Signification : Beaucoup d’entrées SYN-SENT signifie que les connexions sortantes n’aboutissent pas. C’est le réseau en amont ou un filtrage distant.

Décision : Si des SYN restent bloqués vers de nombreuses destinations, priorisez les vérifications réseau/egress. Si vous voyez beaucoup d’ESTAB mais des réponses lentes, priorisez le throttling distant ou la négociation TLS.

Task 14: Check OS-level file descriptor limits (queue and smtp are file-heavy)

cr0x@server:~$ sudo -u postfix sh -c 'ulimit -n'
1024

Signification : 1024 FDs pour l’utilisateur postfix peut être trop bas sous un trafic élevé, surtout avec des filtres de contenu et de nombreuses livraisons simultanées.

Décision : Si vous voyez « too many open files » dans les logs ou des déferrals aléatoires en charge, augmentez les limites via des overrides systemd et les limites OS. Vérifiez ensuite que la nouvelle limite s’applique réellement aux processus Postfix.

Task 15: Check Exim’s view (if you run Exim)

cr0x@server:~$ sudo exim -bp | head
1tUQz7-0004cR-7p  2.1K Mon 04 Jan 2026 09:02:10  noreply@example.com
  ops@partner.tld

1tUQz8-0004cU-9B  4.0K Mon 04 Jan 2026 09:01:22  alerts@example.com
  user@gmail.com

cr0x@server:~$ sudo exim -Mvh 1tUQz8-0004cU-9B | egrep -i 'defer|retry|error|dsn' | head
-host_address 142.250.102.26
-error_message connect to 142.250.102.26 port 25: Connection timed out

Signification : Même histoire, autre outil : Exim stocke la raison dans les en‑têtes/logs pour cette entrée de file.

Décision : Si Exim montre des timeouts réseau, allez vérifier le réseau. S’il montre des 4xx explicites, allez vers la délivrabilité/throttling.

Task 16: Validate that your resolver isn’t intermittently failing

cr0x@server:~$ for i in $(seq 1 5); do dig +time=1 +tries=1 mx gmail.com | grep 'Query time'; done
;; Query time: 19 msec
;; Query time: 21 msec
;; Query time: 1001 msec
;; Query time: 19 msec
;; Query time: 20 msec

Signification : Une requête a grimpé à ~1s (frontière du timeout). Sous charge, ça se transforme en lenteur de livraison et en déferrals.

Décision : Si vous voyez des jitter, réparez le caching DNS et l’accessibilité aux upstream, ou exécutez un résolveur cache local avec des timeouts raisonnables. L’e‑mail punit immédiatement un DNS instable.

Erreurs courantes : symptôme → cause racine → correction

1) « Tout est différé vers Gmail »

Symptôme : connect to gmail-smtp-in.l.google.com:25: Connection timed out

Cause racine : Port 25 sortant bloqué par l’ISP/cloud, ou pare‑feu/NACL egress, ou routage/NAT épuisé.

Correction : Confirmez avec nc -vz et ss. Supprimez le blocage, ou routez le mail sortant via un relais sur 587 avec authentification si le port 25 est bloqué par politique.

2) « Deferred (host said: 421 4.7.0 Try again later) » après DATA

Symptôme : Le distant accepte RCPT puis diffère après le contenu du message.

Cause racine : Arriéré d’analyse de contenu, shaping de débit, ou scoring de réputation déclenché par vos en‑têtes/corps, un pic de volume, ou une identité incohérente (PTR/HELO/SPF/DKIM).

Correction : Réduisez la concurrence par domaine, ajoutez un délai de rate, assurez la stabilité du DKIM, assurez que SPF inclut votre IP d’envoi, alignez rDNS et HELO. Si c’est un partenaire, coordonnez l’allowlist et les attentes de volume.

3) « Temporary lookup failure » / « Host not found »

Symptôme : DSN ou lignes de logs liées au DNS, souvent intermittentes.

Cause racine : Timeouts du résolveur, DNSSEC cassé, panne upstream, ou /etc/resolv.conf mal configuré avec des serveurs morts.

Correction : Réparez la chaîne de résolveur ; ajoutez de la redondance ; raccourcissez les timeouts ; assurez‑vous que le MTA pointe vers des résolveurs fiables.

4) La file grossit, le disque semble correct, mais les livraisons traînent

Symptôme : Pas d’erreurs évidentes, juste du mail lent et des déferrals en hausse.

Cause racine : Latence I/O disque (pas capacité) ou épuisement d’inodes, souvent sur /var partagé avec logs et données applicatives.

Correction : Mesurez avec iostat/pidstat (non montré ici), déplacez le spool vers un stockage plus rapide, séparez le système de fichiers, augmentez les inodes, et arrêtez de co‑localiser « file de mail » avec « tout le reste qui écrit ».

5) « TLS handshake failed » et soudain tout diffère après un patch

Symptôme : Erreurs de négociation STARTTLS vers certains domaines, pas tous.

Cause racine : Changement de politique crypto (chiffres/protocoles), serveurs distants obsolètes, ou politique TLS locale trop stricte.

Correction : Décidez de votre politique : TLS opportuniste vs obligatoire. Si obligatoire, vous pourriez avoir besoin d’exceptions par domaine. Si opportuniste, assouplissez les contraintes locales trop strictes pour la réalité SMTP.

6) « J’ai flushé la file et maintenant c’est pire »

Symptôme : Plus de déferrals, nouveaux blocs, délais plus longs.

Cause racine : Un flush crée un burst. Le throttling distant se déclenche plus fort ; votre réputation IP en prend un coup ; vos tables NAT/état souffrent.

Correction : Limitez. Lissez. Laissez les retries faire leur travail. Flushez seulement après avoir éliminé la cause racine, et même alors augmentez progressivement.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a déplacé son application principale d’un environnement colocalisé vers un VPC cloud. Ils ont conservé la VM du serveur mail « parce que ça marchait déjà ». Le plan de migration incluait bases, caches et couche applicative. Le mail a été traité comme un grille‑pain : on le branche et il chauffe le pain.

Le lundi, les e‑mails transactionnels n’arrivaient plus chez les grands domaines consommateurs. La file grossissait. Les logs indiquaient connect to ...:25: Connection timed out. L’équipe app a supposé que Gmail était down ou « limitait ». L’équipe réseau a supposé que l’équipe mail avait mal configuré Postfix. Tout le monde s’est trompé de façon coordonnée.

La cause racine était banale : le TCP/25 sortant était bloqué par la politique par défaut du fournisseur cloud pour ce compte. Le serveur mail pouvait résoudre le DNS et se connecter aux services internes, donc la supervision semblait OK. Seul le port qui compte pour la livraison SMTP était implicitement refusé.

Ils ont passé des heures à tuner la concurrence et les intervalles de retry—autrement dit, optimiser la radio d’une voiture dont le moteur manque. Une fois que quelqu’un a lancé nc -vz depuis l’hôte et vu le timeout, le diagnostic est devenu évident. Ils ont routé le mail sortant via un relais authentifié sur le port 587 en attendant l’exception de politique.

La leçon : ne supposez pas que « le réseau est ouvert » simplement parce que SSH fonctionne. SMTP dépend de chemins egress spécifiques, et les paramètres par défaut du cloud ne sont pas vos amis.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une entreprise globale a subi un pic de volume légitime : relevés trimestriels, réinitialisations de mot de passe, et une campagne marketing que personne n’a voulu reconnaître. Leur cluster MTA était sain, mais les déferrals ont augmenté contre quelques gros récepteurs qui renvoyaient des 421 4.7.0.

Un ingénieur a trouvé que la limite de concurrence par destination était « conservatrice » et l’a augmentée. Puis de nouveau. Le débit a augmenté—pendant environ 20 minutes. Puis les récepteurs distants ont commencé à différer plus tôt, plus souvent, et plus longtemps. Certains destinataires sont passés de 4xx à des blocages définitifs. Les délais de livraison sont passés de minutes à heures.

Pourquoi ? Les récepteurs n’étaient pas limités uniquement par la capacité. Ils appliquaient des politiques et façonnaient le trafic. Une concurrence plus élevée ressemblait à un comportement abusif, même si le contenu était correct. Le MTA est devenu un marteau très poli, tapotant le même clou jusqu’à ce que le destinataire s’énerve et parte.

La correction a été l’inverse de « l’optimisation » : baisser la concurrence par destination, introduire un petit délai de rate, et répartir le trafic sur des pools d’IP séparés avec des patterns de volume stables. Ils ont aussi cessé de balancer tout le backlog immédiatement après une fenêtre de maintenance.

La leçon : en livraison d’e‑mail, la force brute n’est pas de l’ingénierie de performance. C’est de l’ingénierie de réputation, et le score est tenu par quelqu’un d’autre.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une société financière envoyait des mails sortants depuis deux MTA en active‑active, devant lesquels se trouvait une couche de relais. Rien de fancy. Ce qui l’était, c’était leur discipline : un système de fichiers séparé pour /var/spool/postfix, des alertes sur l’utilisation des inodes, et un échantillonnage quotidien des raisons de déferral (pas seulement des comptes).

Un matin, les déferrals ont augmenté, mais seulement pour un sous‑ensemble de destinations. La file n’explosait pas encore. Leur alerte n’était pas « file > X », c’était « raison de déferral principale changée ». C’est une alerte mature : elle repère un nouveau mode de défaillance avant que le volume devienne effrayant.

La nouvelle raison était une défaillance de négociation TLS vers certains serveurs anciens juste après un patch OS. L’équipe avait un playbook prêt : confirmer avec un test SMTP ciblé, revenir sur le changement de politique crypto pour SMTP seulement, et garder le reste du jeu de patches de sécurité. Pas de drame, pas de réunion générale.

Ils ont rétabli la livraison en moins d’une heure, et personne en dehors de l’équipe mail n’a remarqué. C’est le meilleur résultat : l’absence de réunions.

Leçon : les pratiques ennuyeuses—spools séparés, alertes d’inodes, monitoring par raison—ne semblent pas héroïques. Elles le sont. Elles vous évitent d’apprendre de dures leçons pendant les heures ouvrables.

Listes de contrôle / plan pas à pas (stabiliser, réparer, prévenir)

Étape 1 : Stabiliser le champ d’impact (15 minutes)

• Arrêtez les flush répétés de la file. Si quelqu’un flush toutes les cinq minutes, prenez doucement le clavier.
• Identifiez les 1–3 raisons principales de déferral à partir des logs et de la sortie de la file. Ne poursuivez pas les cas rares pour l’instant.
• Throttlez le trafic sortant vers les domaines les plus touchés s’ils renvoient des 421/4.7.0.
• Vérifiez disque/inodes sur le système de spool et libérez de l’espace si nécessaire.
• Vérifiez la résolution DNS depuis l’hôte MTA et assurez‑vous qu’elle est stable et rapide.

Étape 2 : Réparer la cause racine (30–120 minutes)

• Si timeouts : vérifiez le port 25 sortant, le routage, le pare‑feu, l’état NAT et les blocs de politique fournisseur.
• Si 421 throttling distant : ajustez la concurrence/taux par destination, lissez les rafales, et vérifiez l’identité de l’expéditeur (PTR/HELO/SPF/DKIM).
• Si échecs TLS : reproduisez avec un test ciblé, puis ajustez votre politique TLS SMTP pour coller à la réalité opérationnelle.
• Si goulot du filtre de contenu : contrôlez la santé des milters/services, leurs files et leurs timeouts. S’ils sont down, décidez de bypass temporaire (avec acceptation du risque) ou de mise à l’échelle.
• Si latence I/O disque : déplacez le spool vers un stockage plus rapide ou isolez‑le des voisins bruyants. L’e‑mail n’est pas impressionné par votre filesystem partagé.

Étape 3 : Vider la file en sécurité (heures, pas minutes)

• Laissez les retries normaux faire leur travail sauf si vous avez des SLA de livraison stricts.
• Augmentez la concurrence progressivement seulement si les réponses distantes restent saines (2xx) et que vos ressources locales peuvent suivre.
• Priorisez les classes de mail (réinitialisations de mot de passe > newsletters). Si vous ne pouvez pas, séparez au moins par expéditeur ou politique de relais.

Étape 4 : Prévenir la réapparition (cette semaine)

• Alertez sur les raisons de déferral, pas seulement sur la taille de la file.
• Suivez la performance par domaine : quels destinataires diffèrent, à quelle fréquence, et combien de temps pour revenir à la normale.
• Séparez le stockage du spool et surveillez l’espace et les inodes ainsi que la latence.
• Documentez votre identité sortante : PTR, nom HELO, enregistrements SPF, sélecteurs DKIM, politique DMARC.
• Gardez un relais fallback testé sur 587 avec authentification pour les environnements où le port 25 est fragile ou l’IP egress devient problématique.

Blague n°2 : La livraison d’e‑mail est un système distribué où le « problème temporaire » de l’autre dure exactement aussi longtemps que la patience de votre direction.

FAQ (ce que les gens demandent à 2 h du matin)

1) « Message deferred » est‑ce mauvais ?

Pas automatiquement. Le déferral est la façon dont SMTP survit aux défaillances temporaires. Ça devient mauvais quand la file grossit plus vite qu’elle ne se vide, ou quand la raison de déferral indique un défaut local (DNS, disque, port 25 bloqué).

2) Combien de temps un message différé reste‑t‑il en file ?

Ça dépend de la configuration de votre MTA. Beaucoup de systèmes réessaient pendant des jours avant d’abandonner. Sur le plan opérationnel, vous devriez alerter bien avant que « des jours » ne devienne visible par les utilisateurs.

3) Pourquoi je vois des 421 « Try again later » alors que le destinataire est up ?

Parce que « up » n’est pas synonyme de « disposé ». Les grands récepteurs différent pour shaping, réputation, détection de rafales, et capacité d’analyse de contenu. Traitez un 421 comme un signal de négociation, pas comme un crash serveur.

4) Dois‑je flush la file pour la réparer ?

Flushez après avoir corrigé la cause racine, et même alors prudemment. Flusher pendant un événement de throttling crée souvent un burst qui aggrave le throttling ou déclenche des blocages.

5) Quelle est la différence entre « deferred » et « bounced » ?

Deferred signifie échec temporaire (généralement 4xx) et sera réessayé. Bounced signifie échec permanent (5xx) et est renvoyé à l’expéditeur (ou journalisé/supprimé selon la politique).

6) Pourquoi le DNS importe‑t‑il autant pour la livraison mail ?

Le routage SMTP dépend des enregistrements MX, plus des recherches A/AAAA pour ces hôtes. Beaucoup de récepteurs vérifient aussi la cohérence PTR/HELO. Si le DNS est lent ou cassé, les livraisons s’arrêtent et les déferrals s’accumulent.

7) Des problèmes de disque peuvent‑ils vraiment provoquer « message deferred » ?

Oui. Les files mail sont composées de nombreux petits fichiers. Si vous manquez d’espace ou d’inodes, ou si le système de fichiers est lent, le MTA ne peut pas mettre à jour l’état de la file ou traiter les livraisons. Les logs peuvent ne pas hurler ; ils différeront juste.

8) Pourquoi seuls certains domaines diffèrent alors que d’autres livrent ?

Parce que la politique est propre à chaque récepteur. Un domaine peut greylist, un autre peut throttler, un autre exiger une rDNS correcte, et un autre être down. L’e‑mail n’est pas un réseau unique ; c’est des milliers de jeux de règles indépendants.

9) DKIM/SPF/DMARC provoquent‑ils des déferrals ou des rebonds ?

Les deux sont possibles. Un mauvais alignement ou une authentification manquante peut augmenter les déferrals 4xx (politique/réputation) avant un rejet définitif. Corriger l’authentification réduit souvent le bruit « try again later » avec le temps.

10) Quand dois‑je impliquer l’équipe mail du destinataire ?

Quand vous avez un 4xx distant constant avec un motif stable (même réponse, même étape comme fin de DATA) et que votre infrastructure est OK (port 25 fonctionnel, DNS propre, identité cohérente). Apportez des preuves : horodatages, transcriptions SMTP, IP d’envoi, et IDs de message d’exemple.

Étapes suivantes à réaliser cette semaine

Si « message deferred » est un invité récurrent dans vos logs, cessez de le traiter comme la météo. Construisez un petit système répétable autour de ce phénomène.

• Instrumentez les raisons de déferral (top N par compte, top N par destinataire/domaine affecté). Une file qui monte est tardive ; un changement de raison est précoce.
• Séparez votre système de fichiers de spool et alertez sur les inodes et les symptômes de latence, pas seulement sur le « % disque utilisé ».
• Renforcez la résolution DNS pour les hôtes MTA. Des résolveurs récursifs fiables avec des timeouts sensés ne sont pas optionnels.
• Fixez des règles de shaping par domaine sensées pour ne pas apprendre le throttling via une plainte client.
• Gardez un chemin de secours testé (un relais sur 587) pour quand le port 25 est instable ou que votre IP egress devient douteuse.

L’objectif n’est pas d’éliminer les déferrals. C’est irréaliste. L’objectif est de reconnaître quand un retry normal devient un incident de production—et de réparer le vrai goulot avant que votre file ne devienne une capsule temporelle.