Échecs temporaires SMTP 4xx : causes principales et correctifs qui fonctionnent

Ce que signifient réellement les échecs temporaires SMTP 4xx

Les codes de réponse SMTP sont des instruments rugueux avec une apparence polie trompeuse. Une réponse 4xx est une défaillance transitoire : on attend du send que le message soit réessayé plus tard. Ce n’est pas une promesse que plus tard fonctionnera — juste une demande pour que votre MTA arrête de frapper.

La différence pratique entre 4xx et 5xx

• 4xx : « Réessayez. » Votre MTA met le message en file, planifie des nouvelles tentatives et finit par abandonner après un certain TTL (par défaut Postfix est souvent de plusieurs jours, mais vérifiez votre config).
• 5xx : « Arrêtez. » Le destinataire indique un rejet permanent (destinataire invalide, rejet de politique, hard bounce). Retenter est généralement vain sauf si l’émetteur corrige quelque chose en amont.

Les codes de statut étendus importent plus que les trois chiffres

Les MTA modernes incluent souvent un code « étendu » comme 4.7.0 ou 4.4.1. C’est dans ce second code que le sens se cache. Exemples :

• 421 4.7.0 : typiquement du throttling, des blocages de politique temporaires, ou un « va-t’en ».
• 450 4.2.0 : boîte aux lettres indisponible, souvent temporaire ou greylisting.
• 451 4.3.0 : erreur de traitement locale ; peut être une exhaustion de ressources.
• 452 4.3.1 : espace système insuffisant ; ou destinataire « quota plein ».
• 454 4.7.0 : TLS non disponible pour une raison temporaire (ou négociations de politique).

Règle opérationnelle : considérez le 4xx comme un signal de capacité et de correction. Même si c’est « l’autre côté », votre système est celui qui accumule le courrier différé, le bruit d’alerte et le risque réputationnel.

Idée paraphrasée attribuée à Gene Kranz : Fail fast, be calm, and act from the data. Ce n’est pas de la poésie, mais ça gagne les incidents.

Blague 1 : SMTP 4xx, c’est comme une invitation de réunion qui dit « tentative » — vous n’êtes pas rejeté, vous êtes juste coincé au purgatoire du calendrier.

Feuille de route de diagnostic rapide (premier/deuxième/troisième)

Quand la file grossit, vous n’avez pas le temps de méditer sur les RFC. Il vous faut trouver le goulet d’étranglement avec une séquence qui minimise les errances.

Premier : identifier le schéma d’échec (côté destinataire vs côté local)

1. Est-ce un seul domaine ou plusieurs ? Si c’est un grand fournisseur, pensez throttling/greylisting/politique. Si c’est beaucoup de domaines, pensez DNS, réseau, ressources locales, config cassée ou dépendance partagée.
2. Est-ce un seul hôte d’envoi ou tous les MTAs ? Si seul un serveur est impacté, suspectez la réputation IP de cet hôte, le routage ou l’exhaustion de ressources locales.
3. Y a-t-il une corrélation temporelle ? Pics en début d’heure ? Ça ressemble à des jobs batch et des limites de débit. Pics pendant les sauvegardes ? Ça ressemble à de l’I/O et de la latence.

Deuxième : lisez le texte SMTP exact, pas vos impressions

Récupérez des lignes d’exemple dans les logs et regroupez par chaîne de réponse distante. L’argent gratuit se trouve dans la différence entre « 4.7.0 try again later » et « 4.4.1 connection timed out » ou « 451 4.3.0 internal error ». Chacun pointe vers une couche différente.

Troisième : vérifiez la santé de la file et du système en parallèle

La profondeur de la file n’est pas le problème ; c’est un symptôme. Vous voulez répondre :

• Est-ce que nous tentons des livraisons à un rythme normal, ou sommes-nous bloqués (DNS cassé, réseau cassé, processus bloqué) ?
• Sommes-nous différés par la politique (throttling/greylisting), nécessitant backoff ou warmup ?
• Sommes-nous limités par les ressources (disque plein, exhaustion d’inodes, latence I/O, pression mémoire) ?

La matrice de triage la plus rapide

• 4.4.x timeouts → réseau, DNS, routage, pare-feu, panne distante.
• 4.7.x politique/throttling → limites de débit, réputation, authentification, schémas de contenu.
• 4.3.x traitement local → stockage, permissions, corruption de file d’attente, santé du processus MTA.
• 4.2.x boîte → problèmes destinataire ou greylisting ; souvent spécifique au domaine.

Principales causes des échecs SMTP 4xx (et correctifs réels)

1) Throttling du destinataire et limites de débit (421/450/451/4.7.x)

Les gros fournisseurs se défendent avec des throttles. Ils ne veulent pas que vous envoyiez trop vite, depuis trop de connexions, ou avec des schémas qui ressemblent à du spam. Le résultat est souvent 421 4.7.0, 451 4.7.x, ou un vague « Try again later ».

Correctifs qui fonctionnent :

• Réduire la concurrence vers ce domaine : moins de connexions parallèles, moins de destinataires par connexion.
• Chauffer les nouvelles IP plutôt que d’envoyer tout le volume dès le premier jour.
• Séparer les classes de trafic (transactionnel vs bulk). Laissez le bulk encaisser le throttling, pas les réinitialisations de mot de passe.
• Utiliser un retry/backoff sensé. Les retries agressifs peuvent ressembler à un abus.

2) Greylisting (450 4.2.x / 451 4.7.x)

Le greylisting est une tactique volontaire « va-t’en et reviens ». Elle mise sur l’hypothèse que les MTA légitimes réessaieront, tandis que beaucoup de bots spammeurs ne le font pas. Vous verrez un échec temporaire au premier essai ; les tentatives ultérieures réussissent.

Correctifs qui fonctionnent :

• Ne paniquez pas. Assurez-vous que votre plan de retries est correct et pas désactivé.
• Garder votre IP d’envoi stable. Les clés de greylisting incluent souvent l’IP.
• Vérifiez que votre MTA ne se comporte pas comme un bot : HELO/EHLO correct, reverse DNS valide, comportement TLS cohérent.

3) Problèmes DNS : timeouts de résolution, SERVFAIL, resolveurs cassés (451 4.4.3, « Temporary lookup failure »)

SMTP dépend beaucoup du DNS : recherches MX, enregistrements A/AAAA, PTR, SPF, DKIM, parfois RBL et checks de politique. Si votre résolveur est lent, mal configuré ou bloqué, vous obtenez des échecs transitoires qui semblent être des problèmes distants mais sont en réalité locaux.

Correctifs qui fonctionnent :

• Utilisez des resolveurs fiables localement (systemd-resolved est un vilain récurrent).
• Surveillez la latence DNS et le taux de SERVFAIL, pas seulement « est-ce que le DNS est up ».
• Cachez de manière responsable. Ne mettez pas en cache des réponses erronées indéfiniment.

4) Problèmes de négociation TLS (454 4.7.0, échecs de handshake, cas limites d’opportunistic TLS)

TLS est surtout ennuyeux jusqu’au moment où il ne l’est plus. Un échec TLS temporaire peut venir de mismatches de cipher, d’hiccups de validation de certificat (pour TLS forcé), de bugs SNI, ou de middleboxes qui « optimisent » en cassant les choses.

Correctifs qui fonctionnent :

• Consigner les détails TLS SMTP au niveau du MTA et capturer une transaction échouée.
• Privilégier TLS moderne, tout en gardant une compatibilité si vous devez parler à des points anciens.
• Si vous imposez TLS pour certains domaines, assurez-vous que votre store CA et la gestion SNI sont corrects.

5) Problèmes de stockage et du système de fichiers de la file (451 4.3.0, 452 4.3.1, « cannot write file »)

Votre MTA est un système de stockage qui porte un chapeau mail. La file est effectivement une base de données de messages, et les bases détestent les disques lents, les disques pleins, l’exhaustion d’inodes et les permissions négligées.

Correctifs qui fonctionnent :

• Vérifiez l’espace disque, les inodes et la latence I/O.
• Mettez la file sur un stockage fiable. Si vous partagez un volume avec des voisins bruyants, attendez-vous à de la douleur.
• Faites attention aux snapshots de sauvegarde qui bloquent l’I/O ou remplissent les volumes.

6) Exhaustion de processus/ressources (451 4.3.0, « out of memory », trop de fichiers ouverts)

Les MTA ne sont pas énormes, mais sous charge ils peuvent atteindre les limites de descripteurs de fichiers, la pression mémoire ou les limites de table de processus. Les symptômes incluent des temporisations locales, une livraison lente et un comportement intermittent étrange.

Correctifs qui fonctionnent :

• Augmentez ulimit -n et les limites système de manière appropriée.
• Arrêtez de considérer le swap comme une fonctionnalité de performance.
• Dimensionnez correctement la concurrence. Ajouter des threads sur un disque saturé conduit à une panne plus longue.

7) Réputation / blocs temporaires de politique (421/451 4.7.0, « temporarily deferred »)

Les destinataires peuvent vous bloquer temporairement pour des pics de volume suspects, des plaintes pour spam, des destinataires invalides ou une authentification désalignée. Parfois le destinataire ne veut pas dire « ton mail semble mauvais », donc il dit « réessaye plus tard ».

Correctifs qui fonctionnent :

• Alignez SPF, DKIM et DMARC pour les mails que vous envoyez.
• Réduisez le taux de rebonds en nettoyant les listes et en corrigeant la validation des destinataires.
• Stabilisez le volume. Le trafic en pics coûte en réputation.

8) Problèmes de chemin réseau : timeouts, perte de paquets, MTU bizarres (4.4.x)

Si vous timez sur plusieurs domaines, ne passez pas des heures à regarder des configs Postfix. Regardez le réseau. Perte de paquets, routage asymétrique, pare-feu mal configuré ou IPv6 cassé peuvent transformer SMTP en tragédie au ralenti.

Correctifs qui fonctionnent :

• Testez v4 et v6 séparément. Les échecs dual-stack sont notoirement confus.
• Vérifiez les tables d’état du pare-feu et la capacité NAT.
• N’ignorez pas les problèmes PMTUD/MTU si les handshakes TLS se bloquent.

9) Pannes de dépendances en aval : scan de contenu, latence milter, pannes antivirus (451 4.3.0)

Beaucoup d’architectures routent le mail via des milters, filtres de contenu, moteurs DLP ou « appliances de sécurité ». Quand ceux-ci se dégradent, votre MTA attend, bloque, puis différera. L’erreur SMTP peut mentionner un filtre ; ou pas.

Correctifs qui fonctionnent :

• Mesurez explicitement la latence et les échecs des milters.
• Utilisez des timeouts et des modes fail-open/fail-closed de façon délibérée selon la classe de mail.
• Planifiez la capacité des filtres comme s’ils étaient des services de production. Parce que c’en sont.

Blague 2 : Si votre « passerelle de sécurité e-mail » est en panne, félicitations : vous avez construit un générateur de perte de paquets très coûteux.

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

Ce sont des tâches de terrain. Chaque élément inclut une commande, une sortie exemple, ce que cela signifie et la décision à prendre. Servez-vous en pour transformer « les mails sont bloqués » en un diagnostic concret.

Task 1: Count deferred vs active queue (Postfix)

cr0x@server:~$ mailq | egrep -c "^[A-F0-9]"
1842

Ce que cela signifie : Taille brute de la file (IDs de messages). Si ce nombre augmente plus vite qu’il ne diminue, vous avez un problème de débit.

Décision : Si la file > la baseline normale et augmente, isolez par domaine et par texte d’erreur avant de redémarrer quoi que ce soit.

Task 2: Identify top deferred reasons from logs (Postfix)

cr0x@server:~$ sudo awk '/status=deferred/ {print $0}' /var/log/mail.log | tail -n 2000 | sed -n 's/.*said: //p' | sort | uniq -c | sort -nr | head
  421 4.7.0 Try again later
  198 451 4.4.2 Timeout while waiting for server greeting
   74 450 4.2.0 Greylisted, please try again
   41 451 4.3.0 Error: queue file write error
   22 454 4.7.0 TLS not available due to temporary reason

Ce que cela signifie : Ce sont les « top talkers » de votre incident. Ils vous indiquent quelle couche investiguer en priorité.

Décision : Choisissez les 1–2 messages principaux et poursuivez ces pistes. Ne dispersez pas l’attention sur cinq familles d’erreurs différentes.

Task 3: Find which recipient domains dominate the queue

cr0x@server:~$ mailq | awk '/@/ {print $NF}' | sed 's/.*@//' | tr -d '>,' | sort | uniq -c | sort -nr | head
  912 gmail.com
  376 outlook.com
  211 example-corp.com
   94 yahoo.com
   51 proton.me

Ce que cela signifie : Si un domaine domine, vous avez probablement du throttling, un problème de réputation ou une politique spécifique au fournisseur.

Décision : Appliquez un rate limiting par domaine et vérifiez l’alignement d’authentification pour le trafic vers ce domaine.

Task 4: Inspect a single queued message’s last error (Postfix postcat)

cr0x@server:~$ sudo postcat -vq 3F2A91C02B | sed -n '/^*** ENVELOPE RECORDS/,/^*** MESSAGE CONTENTS/p' | head -n 30
*** ENVELOPE RECORDS ***
message_size:           48213              2812               1               0            48213
message_arrival_time: Wed Jan  3 11:02:19 2026
sender: noreply@yourdomain.tld
*** RECIPIENT RECORDS ***
original_recipient: user@gmail.com
recipient: user@gmail.com
offset: 2812
dsn_orig_rcpt: rfc822;user@gmail.com
dsn_notify: failure
dsn_orcpt: rfc822;user@gmail.com
orig_to: user@gmail.com
recipient_status: 421 4.7.0 Try again later

Ce que cela signifie : Confirme la réponse du destinataire attachée à cet enregistrement de file (pas seulement ce que vous avez vu dans les logs).

Décision : Si l’erreur est politique/throttle, ajustez la concurrence et la stratégie de retry plutôt que de redémarrer Postfix.

Task 5: Show Postfix concurrency/rate settings that influence throttling

cr0x@server:~$ sudo postconf | egrep 'default_destination_concurrency_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_destination_recipient_limit|maximal_queue_lifetime'
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_destination_recipient_limit = 50
maximal_queue_lifetime = 5d

Ce que cela signifie : Une concurrence élevée + aucun délai de rate est une manière classique de se faire throttler par les grands fournisseurs.

Décision : Si vous voyez du 4.7.x throttling, baissez la concurrence par destination (commencez par 2–5) et ajoutez un petit rate delay pour les domaines lourds.

Task 6: Confirm DNS resolution for MX and A/AAAA

cr0x@server:~$ dig +time=2 +tries=1 MX gmail.com
;; ANSWER SECTION:
gmail.com.              300     IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              300     IN      MX      20 alt2.gmail-smtp-in.l.google.com.

cr0x@server:~$ dig +time=2 +tries=1 A alt1.gmail-smtp-in.l.google.com
;; ANSWER SECTION:
alt1.gmail-smtp-in.l.google.com. 300 IN A 142.250.102.26

Ce que cela signifie : Si ceci est lent, renvoie SERVFAIL ou timeout, vous avez un problème DNS qui se manifestera par du 4.4.x ou « temporary lookup failure ».

Décision : Si le DNS est instable, corrigez les resolveurs d’abord. La livraison mail dépend d’un DNS sain.

Task 7: Check resolver health (systemd-resolved)

cr0x@server:~$ resolvectl status | sed -n '1,40p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.53
       DNS Servers: 10.0.0.2 10.0.0.3
        DNS Domain: corp.local

Ce que cela signifie : Vous utilisez un résolveur stub local ; les serveurs upstream sont listés. Si l’upstream est incorrect ou inaccessible, attendez-vous à des échecs intermittents.

Décision : Si les serveurs upstream sont internes et surchargés, basculez vers des resolveurs fiables ou exécutez un résolveur de cache local avec supervision.

Task 8: Test outbound SMTP connectivity (TCP and banner)

cr0x@server:~$ nc -vz alt1.gmail-smtp-in.l.google.com 25
Connection to alt1.gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

cr0x@server:~$ timeout 5 bash -lc 'exec 3<>/dev/tcp/alt1.gmail-smtp-in.l.google.com/25; head -n 1 <&3'
220 mx.google.com ESMTP

Ce que cela signifie : Si la connexion TCP échoue ou la lecture de la bannière timeoute, suspectez le pare-feu, le routage, la perte de paquets ou une panne distante.

Décision : Si cela échoue largement, escaladez au réseau. Si cela échoue seulement vers un fournisseur, vérifiez les listes de blocage ou la réputation/politique.

Task 9: Verify IPv6 isn’t silently breaking outbound delivery

cr0x@server:~$ getent ahosts alt1.gmail-smtp-in.l.google.com | head
2607:f8b0:4004:c06::1a STREAM alt1.gmail-smtp-in.l.google.com
2607:f8b0:4004:c06::1a DGRAM
2607:f8b0:4004:c06::1a RAW
142.250.102.26 STREAM
142.250.102.26 DGRAM
142.250.102.26 RAW

Ce que cela signifie : Si IPv6 existe, votre MTA peut l’essayer en premier. Si votre routage IPv6 est cassé, vous verrez des timeouts et des différeés.

Décision : Si le chemin v6 est peu fiable, corrigez-le ou préférez IPv4 pour SMTP jusqu’à ce qu’il soit digne de confiance.

Task 10: Check disk space and inode exhaustion (queue writes)

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

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

Ce que cela signifie : Un espace ou des inodes à 99–100% provoquent des erreurs d’écriture de file et des différements 451/452.

Décision : Libérez de l’espace/inodes immédiatement (rotation des logs, suppression d’anciens fichiers), puis planifiez une expansion du filesystem de la file ou un format adapté aux inodes.

Task 11: Check I/O latency (a common hidden villain)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          3.01    0.00    1.24   18.55    0.00   77.20

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              5.12   92.40   164.0  8120.3  98.40   1.12  99.60

Ce que cela signifie : await proche de 100ms et %util proche de 100% indiquent un disque saturé. Les files mail détestent ça.

Décision : Réduisez la concurrence, déplacez la file vers un stockage plus rapide, ou arrêtez le voisin I/O (sauvegardes, scans antivirus, tempêtes de snapshot).

Task 12: Confirm Postfix processes are alive and not stuck

cr0x@server:~$ sudo systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (exited) since Wed 2026-01-03 10:58:01 UTC; 10min ago
    Process: 1123 ExecStart=/bin/true (code=exited, status=0/SUCCESS)

cr0x@server:~$ ps -ef | egrep 'postfix/(master|qmgr|smtp|pickup)' | head
root      1180     1  0 10:58 ?        00:00:00 /usr/lib/postfix/sbin/master -w
postfix   1182  1180  0 10:58 ?        00:00:00 pickup -l -t unix -u
postfix   1183  1180  0 10:58 ?        00:00:00 qmgr -l -t unix -u

Ce que cela signifie : Postfix semble vivant. Si la file ne se vide pas, concentrez-vous sur les erreurs de livraison et dépendances plutôt que de redémarrer aveuglément.

Décision : Ne redémarrez que si vous avez la preuve d’un processus bloqué ou d’un changement de config ; les redémarrages peuvent amplifier les tempêtes de file.

Task 13: Measure queue age and “how bad is it”

cr0x@server:~$ mailq | awk 'BEGIN{old=0} /^[A-F0-9]/{id=$1} /^[[:space:]]*[A-Z][a-z]{2}[[:space:]]/{print}' | tail -n 5
     Wed Jan  3 08:41:22  user@outlook.com
     Wed Jan  3 08:41:23  user@gmail.com
     Wed Jan  3 08:41:24  user@yahoo.com
     Wed Jan  3 08:41:25  user@proton.me
     Wed Jan  3 08:41:26  user@example-corp.com

Ce que cela signifie : Des entrées anciennes indiquent une incapacité prolongée à livrer. Ce n’est plus seulement un clignotement transitoire.

Décision : Si les plus anciens mails ont des heures d’âge pour du trafic transactionnel, commencez les mitigations : réglages de throttling par domaine, pools séparés, routage via un MTA alternatif, ou pause des envois bulk.

Task 14: Check for too many open files (classic 451 local errors)

cr0x@server:~$ cat /proc/$(pgrep -n master)/limits | egrep 'open files|Max processes'
Max processes             127528               127528               processes
Max open files            1024                 1048576              files

Ce que cela signifie : Si Max open files est bas (ex. 1024), une forte concurrence peut atteindre l’exhaustion de FD sous charge.

Décision : Augmentez les limites pour Postfix via des overrides systemd et ajustez la concurrence pour coller à la réalité disque/réseau.

Task 15: Validate TLS from your host to a target (debug handshake failures)

cr0x@server:~$ openssl s_client -starttls smtp -connect alt1.gmail-smtp-in.l.google.com:25 -servername alt1.gmail-smtp-in.l.google.com -brief < /dev/null | head -n 12
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=mx.google.com
Verification: OK
250 SMTPUTF8

Ce que cela signifie : TLS fonctionne de bout en bout depuis cet hôte. Si Postfix signale 454, il peut s’agir d’un mismatch de politique, d’un store CA ou d’une interférence milter.

Décision : Si cela échoue, corrigez le bundle CA système, les réglages SNI/cipher ou les middleboxes réseau avant de toucher au routage mail.

Task 16: Spot milter/filter delays (symptom: local tempfail)

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | egrep -i 'milter|timeout|warning' | tail -n 20
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: can't read response packet: Connection timed out
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: aborting milter conversation
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: unavailable: temporary failure

Ce que cela signifie : Votre dépendance de filtrage timeoute, poussant SMTP vers des échecs temporaires locaux.

Décision : Rétablissez la capacité du filtre, bypassez pour le trafic critique, ou définissez des timeouts/politique de basculement de façon intentionnelle.

Trois mini-histoires d’entreprise issues de la production

Mini-histoire 1 : La panne causée par une mauvaise hypothèse (« 4xx signifie que l’autre côté est down »)

L’entreprise exploitait une paire de relais Postfix devant une flotte d’applications. Tout allait « bien » jusqu’à un mardi matin où les réinitialisations de mot de passe ont commencé à accumuler du retard. L’astreinte voyait 451 4.4.2 Timeout while waiting for server greeting et a supposé que le grand fournisseur avait une panne. Cette hypothèse leur a fait perdre deux heures à attendre.

Entre-temps la file a gonflé. Pas seulement pour le grand fournisseur — pour presque tout le monde. L’indice était enfoui dans les logs : les timeouts arrivaient pour des domaines sans lien entre eux. L’équipe a continué à blâmer « l’internet », ce qui est le signe qu’on manque d’idées.

Un ingénieur réseau a finalement exécuté un test de bannière direct et a remarqué quelque chose d’étrange : la connexion TCP réussissait vite, mais la lecture de la bannière SMTP restait bloquée. Ce n’est pas « le distant est down ». C’est « des paquets se font manger ». Le coupable était une mise à jour d’un pare-feu stateful qui a réduit la taille de la table de connection tracking. En charge normale c’était OK ; en pointe, il laissait tomber de nouveaux flux et certains flux établis de manière imprévisible.

Le correctif fut trivial : restaurer la capacité du connection tracking et réduire la concurrence SMTP pendant quelques heures le temps que le backlog s’évacue. L’action post-mortem fut plus importante que le réglage pare-feu : « Quand vous voyez des timeouts 4.4.x sur plusieurs domaines sans rapport, traitez-le comme votre réseau jusqu’à preuve du contraire. »

Mini-histoire 2 : L’optimisation qui a mal tourné (file sur stockage partagé « rapide »)

Une autre organisation a voulu « moderniser » ses relais mail. Ils ont déplacé la file Postfix du SSD local vers un système de fichiers réseau partagé parce que c’était « durable » et « plus simple à gérer ». Le changement est passé facilement car il sonnait fiable.

Au début, ça marchait. Puis un job de sauvegarde a été ajouté, prenant des snapshots réguliers de ce stockage partagé. Chaque heure, pile à l’heure, le processus de snapshot causait un pic de latence. Les livraisons SMTP ralentissaient, puis différaient, et la file gonflait. L’erreur était un mélange de 451 4.3.0 erreurs de traitement local et de timeouts aléatoires, parce que quand le gestionnaire de file se bloque assez longtemps, tout le reste commence à sembler cassé.

L’équipe a répondu par le rituel habituel : redémarrer Postfix. Ça a « aidé » temporairement, surtout en réinitialisant du travail en vol et en donnant l’illusion d’une action. Mais chaque redémarrage ralentissait la récupération parce qu’il augmentait le churn de connexion et forçait plus de handshakes TLS.

Le correctif final fut de cesser de traiter la file mail comme un répertoire de logs. Ils l’ont remise sur SSD local, activé la supervision de latence disque et traité le stockage partagé comme un lieu pour les sauvegardes — pas pour les écritures critiques à chaud. La leçon était claire : la livraison d’e-mails est sensible à l’I/O, et un stockage partagé « durable » peut être un piège de performance si la latence n’est pas strictement contrôlée.

Mini-histoire 3 : La pratique ennuyeuse et correcte qui a sauvé la journée (séparation des classes de trafic)

Une entreprise fit la chose peu sexy : elle sépara les e-mails transactionnels du bulk marketing. Deux identités expéditrices logiques, deux pools d’IP, files distinctes, limites de débit différentes. Ça ressemblait à de la bureaucratie, donc impopulaire — jusqu’au jour où ce ne l’était plus.

Une campagne est partie avec une faute dans un segment qui a causé un afflux de destinataires invalides. Le taux de rebond a grimpé, et un grand fournisseur a commencé à renvoyer des différements de politique temporaires (421 4.7.0). La file bulk s’est empilée rapidement, comme une congère contre une porte.

Mais le mail transactionnel a continué à circuler. Les réinitialisations de mot de passe et les notifications de facture passaient par le pool transactionnel avec une hygiène stricte des listes et un profil de volume stable. Ce pool avait des limites de concurrence par domaine séparées et une politique de retry différente. Il a à peine subi le throttling.

La réponse à l’incident fut presque ennuyeuse : pause des envois bulk, correction du segment, laisser la file bulk s’écouler lentement, et garder le mail critique sain. Le post-mortem ressemblait à une histoire du soir : « La séparation ennuyeuse des responsabilités a empêché des retards affectant le revenu. » Cela n’a rendu personne célèbre, ce qui est souvent le signe d’un bon engineering.

Faits intéressants et contexte historique (utile, pas trivia)

• SMTP précède l’ère moderne du spam. Il a été conçu dans un réseau plus confiant, d’où l’empilement massif de contrôles de politique aujourd’hui.
• Les échecs temporaires sont devenus une arme et un bouclier. Le greylisting a popularisé l’usage des 4xx pour faire perdre du temps aux spammeurs, misant sur le fait que les MTA légitimes retenteront.
• Les codes étendus (comme 4.7.0) ont été introduits pour plus de précision au-delà des trois chiffres, parce que « 451 » seul n’était pas assez expressif pour les politiques modernes.
• Les files mail sont volontairement persistantes. SMTP suppose que les réseaux tombent ; la file-et-retry est l’essence même. Votre travail est d’empêcher que la file ne devienne une décharge.
• Historiquement, certains MTA réessayaient pendant une semaine ou plus. C’était logique quand les liens étaient peu fiables ; aujourd’hui ça peut transformer une courte panne en jours de retard.
• Les checks RBL/RHSBL et les politiques basées sur DNS ont explosé avec le spam. La fiabilité des resolveurs est devenue critique pour le mail, d’où le fait que des pannes DNS puissent ressembler à « mail en panne ».
• TLS pour SMTP a commencé comme chiffrement opportuniste. Il a amélioré la confidentialité sans coordination requise, mais a aussi créé des cas limites étranges où « parfois TLS marche » devient une variable de livraison.
• Les gros fournisseurs de boîtes mail fonctionnent comme des cibles DDoS. Leurs throttles font partie de la survie ; si vous envoyez à grande échelle, vous négociez avec leurs systèmes anti-abus.
• Même les blocs « temporaires » peuvent être effectifs de façon permanente si votre comportement de retry déclenche plus d’application de politique (ex. retries concurrents élevés qui ressemblent à du martèlement).

Erreurs fréquentes : symptômes → cause racine → correction

« Tout est différé » et la file croît sur de nombreux domaines

Symptôme : Beaucoup de 4.4.x timeouts ou « temporary lookup failure », affectant des destinataires variés.

Cause racine : Problèmes de résolveur DNS local, exhaustion firewall/NAT, perte de paquets, ou IPv6 cassé.

Correction : Validez le DNS avec dig, testez la lecture de bannière avec nc//dev/tcp, et isolez v4/v6. Corrigez le réseau avant d’ajuster Postfix.

Un domaine domine les différements avec « Try again later »

Symptôme : Spécifique au fournisseur 421 4.7.0 ou similaire, principalement un domaine.

Cause racine : Throttling dû à la concurrence, un pico de volume, ou des signaux de réputation.

Correction : Baissez la concurrence par destination, ajoutez un rate delay, séparez les classes de trafic et stabilisez le volume. Ne réessayez pas agressivement.

451 4.3.0 intermittent pendant les pics

Symptôme : 451 4.3.0 « internal error » / erreurs d’écriture de file, souvent corrélées à d’autres jobs.

Cause racine : Disque plein/exhaustion d’inodes, ou latence I/O due aux sauvegardes/snapshots/AV ; parfois exhaustion de FD.

Correction : Vérifiez df -h, df -i, iostat et les limites de FD. Déplacez la file vers un stockage à faible latence et stoppez les voisins bruyants.

454 4.7.0 TLS non disponible, seulement pour certains destinataires

Symptôme : TLS opportuniste marche pour la plupart, mais un sous-ensemble échoue temporairement.

Cause racine : Mismatch de cipher, middlebox cassé, bizarreries SNI, store CA ou mauvaise config TLS forcé.

Correction : Reproduisez avec openssl s_client -starttls smtp depuis l’hôte émetteur ; ajustez les réglages TLS ou contournez les middleboxes.

Le greylisting est traité comme une panne

Symptôme : La première tentative reçoit 450, la suivante réussit, mais les gens paniquent quand même.

Cause racine : Le greylisting fonctionne comme prévu, et votre alerting est trop naïf.

Correction : Ajustez l’alerte sur des seuils de taux/ancienneté, pas sur un seul 450. Assurez-vous que les intervalles de retry ne sont pas excessifs pour le mail critique.

La file descend lentement même après « la correction »

Symptôme : Le destinataire accepte de nouveau le mail, mais vous êtes encore engorgé pendant des heures.

Cause racine : Vos limites de débit MTA, la latence disque, ou les plafonds de concurrence par domaine sont trop bas pour récupérer le backlog.

Correction : Augmentez le débit temporairement et prudemment (plus de workers, concurrence légèrement supérieure), surveillez disque et erreurs, puis revenez en arrière.

Listes de contrôle / plan étape par étape

Étape par étape : de la première alerte à une livraison stable

1. Capturez l’état. Taille de la file, principaux textes d’erreur, principaux domaines destinataires, ancienneté du message le plus ancien.
2. Classifiez la famille d’erreur dominante. 4.4.x timeouts vs 4.7.x politique vs 4.3.x erreurs locales.
3. Vérifiez ou infirmez les problèmes DNS/réseau locaux. Recherches DNS, connect TCP, lecture de bannière, sanity v4/v6.
4. Contrôlez la santé du stockage. Espace, inodes, latence I/O, filesystem de la file.
5. Vérifiez les dépendances. Milters/filtres, proxies sortants, NAT/pare-feu.
6. Appliquez la plus petite mitigation sûre. Limiter par domaine, mettre en pause le bulk, ou rerouter le mail critique.
7. Surveillez le taux d’évacuation et le taux d’erreurs. Ne déclarez pas victoire tant que la file ne diminue pas et que les nouveaux mails se livrent normalement.
8. Après stabilité : durcissement post-incident. Meilleurs seuils d’alerte, séparation du trafic, marges de capacité améliorées.

Checklist opérationnelle : quoi tuner (et quoi ne pas)

• À faire : tuner la concurrence par domaine et le rate delay pour les gros fournisseurs.
• À faire : séparer transactionnel et bulk, idéalement au niveau IP/identité et file.
• À faire : surveiller la latence DNS, la latence disque et l’ancienneté de la file.
• À ne pas faire : « réparer » un backlog en augmentant la concurrence aveuglément ; vous provoquerez souvent plus de throttling et une pire réputation.
• À ne pas faire : redémarrer les MTA comme première réponse. C’est un dernier recours ; c’est un mauvais outil de diagnostic.
• À ne pas faire : ignorer IPv6. Soit exécutez-le correctement, soit préférez explicitement IPv4 pour SMTP jusqu’à ce que vous puissiez.

Checklist d’alerte (éviter les incidents « email down » faux)

• Alert on oldest queue age for critical classes, not just queue size.
• Alert on deferred rate by domain (sudden 4.7.0 spike).
• Alert on DNS SERVFAIL/timeout rate from mail hosts.
• Alert on disk I/O wait and filesystem fullness for queue volumes.
• Alert on milter latency/timeouts if you have milters.

FAQ

1) Les erreurs SMTP 4xx sont-elles « sans risque » car elles seront réessayées ?

Non. Les retries sont un mécanisme, pas une solution. Un pic de 4xx est soit un signal de politique (throttling) soit un signal de fiabilité (DNS/réseau/stockage). Traitez-le comme une latence croissante dans n’importe quel autre système de production.

2) Quelle est la façon la plus rapide de distinguer throttling et panne réseau ?

Regardez les codes étendus et la distribution. Un clustering de 4.7.x sur un fournisseur suggère throttling/politique. Des timeouts 4.4.x sur de nombreux domaines suggèrent des problèmes réseau/DNS/locaux.

3) Pourquoi je vois « Try again later » sans détails utiles ?

Les destinataires gardent volontairement la politique opaque pour ne pas aider les spammeurs. Votre meilleur signal est le comportement : quels domaines, quels volumes, quels schémas de connexion, et si votre identité IP a récemment changé.

4) Combien de temps dois-je réessayer les messages différés ?

Assez longtemps pour gérer des vraies pannes, assez court pour ne pas livrer des notifications périmées. Beaucoup d’organisations définissent des durées de vie plus courtes pour les notifications transactionnelles que pour le bulk à faible valeur. Alignez le TTL sur la valeur business.

5) Les problèmes SPF/DKIM/DMARC peuvent-ils provoquer des 4xx au lieu de 5xx ?

Oui. Certains destinataires différeront pendant qu’ils évaluent la réputation, attendent le DNS, ou appliquent une politique temporaire. De plus, vos propres systèmes (ex. milters) peuvent tempfail pendant les recherches DNS pour ces checks.

6) Dois-je désactiver le greylisting côté réception (si je le contrôle) ?

Si vous le pouvez, préférez des contrôles anti-abus plus modernes. Le greylisting peut retarder le courrier légitime et créer du bruit opérationnel. Si vous le gardez, whitelistz les expéditeurs critiques et assurez des fenêtres de retry raisonnables.

7) Pourquoi redémarrer Postfix « règle » parfois le problème ?

Parce que cela réinitialise des états, libère des processus bloqués, ou réduit temporairement la concurrence pendant que le système redémarre. Cela peut aussi empirer la situation en augmentant le churn de connexion et les handshakes TLS. Utilisez-le avec des preuves, pas de la superstition.

8) Quelle est la bonne façon de gérer un backlog massif une fois la cause racine corrigée ?

Évacuez délibérément. Priorisez le trafic critique, limitez les domaines qui pénalisent les rafales, et augmentez le débit seulement autant que votre disque/réseau peuvent supporter. Sinon vous déclencherez de nouveaux throttles et prolongerez la récupération.

9) Les erreurs 452 concernent-elles toujours un disque plein ?

Non. 452 peut signifier que le destinataire est en dépassement de quota, ou que l’émetteur ne peut pas allouer des ressources. Vérifiez si le texte mentionne « insufficient system storage » localement, et validez votre propre disque/inodes.

10) Comment éviter que les incidents 4xx ne me réveillent à 3h du matin ?

Séparez les classes de trafic, surveillez l’ancienneté de la file et les raisons de différement, gardez le stockage de la file rapide et spacieux, et traitez le DNS comme une dépendance de première classe avec son propre SLO.

Conclusion : prochaines étapes pour éviter les répétitions

Les échecs SMTP 4xx sont rarement mystérieux. Ce sont juste des systèmes distribués habillés d’une cravate. Votre travail est d’arrêter de deviner et de commencer à classifier : politique vs réseau vs ressources locales vs dépendances.

Prochaines étapes qui rapportent immédiatement :

1. Ajoutez un panneau « principales raisons différées » (texte d’erreur + codes étendus) et alertez sur les shifts soudains.
2. Alertez sur l’ancienneté de la file la plus ancienne pour le mail transactionnel ; arrêtez de traiter tous les mails de la même façon.
3. Faites respecter la séparation du trafic : transactionnel vs bulk, idéalement avec files séparées et politiques de débit.
4. Rendez le DNS ennuyeux : resolveurs rapides, supervision et basculement testé.
5. Protégez le stockage de la file : faible latence, espace/inodes suffisants et pas de tempêtes de snapshot surprises.
6. Documentez la feuille de diagnostic rapide dans vos runbooks, puis répétez-la une fois quand rien n’est en feu.

Si vous faites cela, les « échecs temporaires » redeviennent ce qu’ils doivent être : des turbulences occasionnelles, pas un style de vie récurrent.