E-mail « 451 problème local temporaire » — localisez rapidement le problème côté serveur

Ce que « 451 problème local temporaire » signifie réellement

SMTP a deux grandes classes d’échec : permanent (5xx) et temporaire (4xx).
Une réponse 451 est un 4xx : l’expéditeur doit réessayer plus tard. L’expression « problème local temporaire »
n’est pas une loi universelle ; c’est une explication textuelle courante ajoutée par les MTAs (ou des politiques/filtres intermédiaires) lorsque
le serveur ne peut pas accepter un message pour l’instant à cause d’une condition locale.

Vous verrez aussi des variantes telles que :
451 4.3.0 Temporary server error,
451 4.3.2 System not accepting network messages,
ou 451 4.7.1 Try again later.
Le premier chiffre est le statut SMTP ; le « code de statut amélioré » (comme 4.3.0) donne un indice sur la catégorie.
Mais voici la vérité inconfortable : la partie textuelle est souvent générique, et le code amélioré peut être trompeur
lorsque c’est un filtre ou un démon de politique qui parle.

Où l’erreur est générée importe

« 451 » peut provenir de :

• Le MTA récepteur (Postfix, Exchange, Sendmail, Exim).
• Un filtre de contenu (antivirus, antispam) qui tombe en échec sécurisé ou en échec « ouvert ».
• Un service de politique (limitation de débit, greylisting, vérifications de réputation) qui expire.
• Un relais en amont (votre smart host / fournisseur sortant) qui vous renvoie un 451.
• Votre propre MTA lors d’une tentative de livraison sortante, reportant dans la file.

Votre premier travail n’est pas de « réparer le 451 ». Votre premier travail est de répondre à une question :
Qui a dit 451, à quelle étape, et à cause de quelle ressource locale ?

Une citation à garder : L’espoir n’est pas une stratégie. — idée paraphrasée souvent évoquée en ingénierie/ops.
Le 451 repose par défaut sur l’espoir (« réessayez plus tard »). Nous allons en faire une preuve.

Mode opératoire de diagnostic rapide (premier/deuxième/troisième)

Vous voulez trouver le goulot rapidement, pas écrire une lettre d’amour à chaque fichier de log du système.
Traitez cela comme un incident : confirmez l’étendue, identifiez le composant en échec, puis validez les contraintes les plus probables dans l’ordre.

Premier : confirmez où le 451 prend naissance (10 minutes)

1. Est-ce entrant ou sortant ? Consultez le suivi des messages côté expéditeur ou les logs de votre propre MTA.
   Si vous êtes l’expéditeur, vous verrez des livraisons « deferred ». Si vous êtes le récepteur, vous verrez des sessions entrantes rejetées/reportées.
2. Capturez l’extrait exact de la transcription SMTP. Vous avez besoin de la ligne complète, y compris le code amélioré et tout texte entre crochets expliquant la raison.
   « 451 problème local temporaire » sans contexte, c’est comme « service dégradé » sans graphique.
3. Identifiez le composant qui parle. Postfix peut logguer « reject: 451 » mais la raison peut être « policy service unavailable. »
   Exchange peut mapper des erreurs de transport internes en 451 4.3.0.

Deuxième : vérifiez les contraintes classiques de ressources (15 minutes)

1. Disque plein / épuisement d’inodes : spools mail, répertoires de file, partitions de logs.
2. Croissance de la file : file des « deferred » qui explose à cause de problèmes en aval.
3. Pannes DNS : résolveur lent, cache cassé, DNSSEC défaillant, ou UDP/53 bloqué.
4. Pression CPU/mémoire : filtres de contenu qui expirent, démons de politique bloqués, pools de threads saturés.
5. Réseau/TLS : timeouts de handshake, ports sortants bloqués, problèmes de certificat, MTU anormale.

Troisième : vérifiez les politiques et dépendances (30–60 minutes)

1. Greylisting ou limitation de débit : 451 intentionnels déguisés en « problème local ».
2. Intégration Spam/AV : clamd, rspamd, Amavis, milter qui expirent.
3. Dépendances base de données / annuaire : LDAP, SQL, Redis, services de réputation.
4. Rétro-pression depuis un relais en amont : votre smarthost vous reporte (« deferring ») et vous vous en prenez à vous-même.

Si vous ne faites qu’une chose : vérifiez le disque et le DNS en priorité. La plupart des incidents 451 sont soit
« nous ne pouvons écrire le message nulle part » soit « nous ne pouvons résoudre quelque chose dont nous avons besoin maintenant ».

Faits intéressants et contexte historique

• SMTP est antérieur à la plupart des modèles modernes de fiabilité. Il a été conçu à une époque où « réessayer plus tard » était normal parce que les réseaux étaient peu fiables.
• Le 4xx est une fonctionnalité, pas un bug. Les échecs temporaires font partie du modèle de résilience SMTP ; les expéditeurs doivent mettre en file et réessayer avec backoff.
• Les codes de statut améliorés (comme 4.3.0) sont venus plus tard. Ils ont été ajoutés pour réduire l’ambiguïté, mais tous les systèmes ne les implémentent pas de manière cohérente.
• Le greylisting a popularisé les 451 intentionnels. Il renvoie délibérément des échecs temporaires pour voir si l’expéditeur réessaie comme un vrai MTA.
• Les répertoires de file sont sensibles à la performance. Historiquement, les MTAs utilisaient des files basées sur des fichiers ; la latence disque peut devenir « problème local temporaire » rapidement.
• Le filtrage de contenu a déplacé le goulot. Avec la montée du spam, les MTAs ont commencé à déléguer les décisions aux milters et scanners — ajoutant de nouveaux modes de défaillance.
• Le DNS est plus dans le chemin critique qu’on le pense. Même lors d’une livraison par IP, de nombreuses configurations font des reverse lookups, des vérifications SPF ou des requêtes de politique.
• Le 451 est souvent utilisé pour le throttling de réputation. Certains fournisseurs utilisent 451 pour ralentir ou « soft block » les expéditeurs sans refuser définitivement.

Blague #1 : Le courrier électronique est le seul protocole où « réessayez plus tard » est un chemin de succès de premier ordre. C’est comme un restaurant qui sert « peut-être » avec des frites.

Tâches pratiques avec commandes (et quoi décider)

Ce sont des vérifications côté serveur, sûres en production. Chaque tâche inclut : commande, exemple de sortie, ce que cela signifie, et la décision à prendre.
Les commandes supposent un serveur Linux de messagerie (exemples Postfix), mais la logique s’applique à d’autres MTAs.

Task 1: Find the 451 in logs and extract context

cr0x@server:~$ sudo grep -R --line-number -E " 451 |451 " /var/log/mail.log | tail -n 20
/var/log/mail.log:128772:Jan  4 10:03:22 mx1 postfix/smtp[24188]: 9C2A8402C5: to=<user@example.net>, relay=mx.example.net[203.0.113.25]:25, delay=12, delays=0.1/0.02/3.1/8.8, dsn=4.3.0, status=deferred (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

Signification : Il s’agit d’une livraison sortante. L’hôte distant a différé après DATA (phase de contenu), pas à la connexion/HELO.
Cela pointe vers un filtrage de contenu distant, une mise en file ou des problèmes de ressources — moins probable un souci DNS.
Décision : Si plusieurs destinataires du même domaine affichent ceci, considérez-le comme un throttling côté distant et ajustez la fréquence/volume ;
si c’est plusieurs domaines, suspectez votre réputation sortante ou votre propre filtre de contenu qui expire.

Task 2: Check if it’s your inbound side rejecting clients

cr0x@server:~$ sudo grep -E "reject:.*451|NOQUEUE: reject:.*451" /var/log/mail.log | tail -n 20
Jan  4 10:05:09 mx1 postfix/smtpd[24501]: NOQUEUE: reject: RCPT from unknown[198.51.100.44]: 451 4.3.2 Temporary local problem; from=<sender@outside.tld> to=<user@yourdomain.com> proto=ESMTP helo=<mail.outside.tld>

Signification : La session entrante est différée au moment du RCPT. C’est typiquement une politique locale, des recherches, du greylisting,
ou une panne de dépendance (LDAP/SQL) qui empêche la validation du destinataire.
Décision : Arrêtez de regarder les files sortantes ; commencez à vérifier vos services de politique et vos recherches d’annuaire.

Task 3: Check disk space where queues/spools live

cr0x@server:~$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   40G   39G  512M  99% /
/dev/sdb1      xfs   200G   45G  155G  23% /var

Signification : Le système racine est à 99 %. Si la file Postfix est sous /var/spool/postfix et que /var va bien, vous pourriez être ok —
sauf si les logs ou fichiers temporaires sont sur /. Beaucoup d’installations placent encore des chemins critiques sur /.
Décision : Si un système de fichiers hébergeant /var/spool, /var/lib, /var/log ou des répertoires temporaires est >90%,
considérez-le comme un incident actif : libérez de l’espace, étendez le disque, ou déplacez les spools. Le 451 peut être votre alerte avant un 5xx définitif.

Task 4: Check inode exhaustion (the silent disk-full)

cr0x@server:~$ df -ih
Filesystem    Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.6M  2.6M     0  100% /
/dev/sdb1        50M  1.2M  48.8M   3% /var

Signification : La racine n’a plus d’inodes. Vous pouvez avoir « de l’espace disponible » et être quand même bloqué parce que le système de fichiers ne peut plus créer de fichiers.
Les MTAs créent beaucoup de petits fichiers (entrées de file). L’épuisement d’inodes déclenche souvent « problème local temporaire » parce que la création de fichiers échoue.
Décision : Trouvez et supprimez les éléments consommant beaucoup d’inodes (fichiers temporaires anciens, dumps de crash, logs en boucle) ou reconstruisez le système de fichiers avec plus d’inodes
(options mkfs ext4) si c’est chronique.

Task 5: Inspect Postfix queue size and deferred reasons

cr0x@server:~$ sudo postqueue -p | head -n 40
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C2A8402C5     3287 Thu Jan  4 10:03:21  no-reply@yourdomain.com
                                         user@example.net
                                         (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

A1B7B40310     9121 Thu Jan  4 10:03:49  app@yourdomain.com
                                         ops@another.tld
                                         (connect to mx.another.tld[192.0.2.10]:25: Connection timed out)

-- 1245 Kbytes in 342 Requests.

Signification : Vous avez plusieurs modes d’échec : 451 distant et timeouts de connexion. Cela suggère des problèmes sortants larges (réseau, réputation,
fournisseur en amont) plutôt qu’un problème sur un domaine distant unique.
Décision : Si le nombre de différés augmente rapidement, limitez les expéditeurs, suspendez les campagnes en masse, et protégez le volume de la file pour éviter de remplir les disques.
Ensuite isolez : avez-vous des problèmes DNS/connectivité ou êtes-vous temporairement bloqué ?

Task 6: Check the mail service health and recent restarts

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-04 09:58:12 UTC; 12min ago
   Main PID: 1218 (master)
      Tasks: 3 (limit: 18948)
     Memory: 22.1M
        CPU: 3.912s

Signification : Postfix est en cours d’exécution. Cela ne veut pas dire qu’il est sain, mais cela écarte le scénario le plus simple « service arrêté ».
Décision : S’il y a des redémarrages répétés, vérifiez les OOM kills, les boucles de rechargement de configuration, ou des échecs de dépendance provoquant des redémarrages par watchdog.

Task 7: Look for OOM kills or kernel-level IO pain

cr0x@server:~$ sudo dmesg -T | egrep -i "oom|killed process|ext4|xfs|i/o error|blk_update_request" | tail -n 30
[Thu Jan  4 10:01:12 2026] Out of memory: Killed process 22219 (clamd) total-vm:2150340kB, anon-rss:824000kB, file-rss:0kB, shmem-rss:0kB

Signification : Votre démon antivirus a été tué. Si votre pipeline SMTP dépend de clamd, le milter peut expirer ou échouer fermé,
entraînant des diffèrés 451.
Décision : Stabilisez la mémoire (limites, swap, contraintes de conteneur), et décidez si le mail doit échouer ouvert (accepter puis scanner en asynchrone)
ou échouer fermé (différer). Dans de nombreux environnements régulés, échouer fermé est correct — mais il faut dimensionner correctement.

Task 8: Validate DNS resolution from the mail server (A/MX/PTR)

cr0x@server:~$ dig +time=2 +tries=1 mx example.net
;; ANSWER SECTION:
example.net.            300     IN      MX      10 mx.example.net.

cr0x@server:~$ dig +time=2 +tries=1 a mx.example.net
;; ANSWER SECTION:
mx.example.net.         300     IN      A       203.0.113.25

Signification : Le DNS répond rapidement pour ce domaine. Si dig est lent ou expire, votre MTA va bloquer,
les files vont croître, et certains MTAs répondent 451 lorsque des recherches nécessaires pour des contrôles de politique échouent.
Décision : Si le DNS est lent, corrigez d’abord la santé du résolveur (cache local, accessibilité des upstream, règles de pare-feu).
Ne « tunez pas Postfix » pour compenser un DNS cassé ; c’est décorer une maison en feu.

Task 9: Check reverse DNS of your outbound IP (common trigger for throttling)

cr0x@server:~$ dig +short -x 198.51.100.10
mail01.yourdomain.com.

Signification : Le PTR existe. Beaucoup de fournisseurs ne rejetteront pas fermement l’absence de PTR, mais ils vont throttler avec des réponses 4xx.
Décision : Si le PTR manque ou est incorrect, corrigez-le auprès de votre ISP/fournisseur cloud. Attendez-vous à réduire les « 451 mystérieux » chez les grands récepteurs.

Task 10: Check policy daemon/milter responsiveness (socket connectivity)

cr0x@server:~$ sudo ss -lntp | egrep ":10023|:10024|:8891|:8892" || true
LISTEN 0      100          127.0.0.1:10024       0.0.0.0:*    users:(("master",pid=1218,fd=15))
LISTEN 0      100          127.0.0.1:8891        0.0.0.0:*    users:(("rspamd",pid=2110,fd=12))

Signification : Vos ports de filtrage écoutent en local. C’est nécessaire, pas suffisant.
Décision : Si les sockets attendus n’écoutent pas, redémarrez ce sous-système et inspectez ses logs.
Si les sockets existent mais expirent, vous avez probablement une surcharge, une contention de verrous, ou une latence des dépendances en aval.

Task 11: Measure local latency to the filter (a quick “is it slow?” test)

cr0x@server:~$ time (echo -e "QUIT\r\n" | nc -w 2 127.0.0.1 10024 >/dev/null)
real    0m0.006s
user    0m0.002s
sys     0m0.002s

Signification : Le port répond rapidement. Si cela prend des secondes ou expire, votre chemin de filtrage retarde les transactions SMTP,
et certains clients/serveurs répondent par 451 lorsque leurs budgets de timeout interne sont dépassés.
Décision : Si c’est lent, scalez le filtre, ajustez les timeouts, ou déroutez temporairement le scan pour des sources de confiance pendant la stabilisation.

Task 12: Check if you’re hitting connection limits or rate limits

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|smtpd_client_message_rate_limit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 200

Signification : Des limites agressives peuvent déclencher des différés 4xx pour des pics légitimes (réinitialisations de mot de passe, alertes d’incident, jobs par lot).
Décision : Si vous voyez des pics causant des 451 pour des applis internes ou partenaires de confiance, augmentez les limites et ajoutez des exceptions par client.
Gardez des limites pour l’internet public ; ne vous auto-DDoS pas avec de la « sécurité ».

Task 13: Inspect per-domain deferrals and concurrency (outbound shaping)

cr0x@server:~$ sudo postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Signification : Une forte concurrence et aucun délai de rate peuvent ressembler à un comportement abusif pour les gros fournisseurs, déclenchant un throttling temporaire 451.
Décision : Pour les domaines connus pour throttler, ajoutez des transport maps avec une concurrence réduite et de petits délais. Ce n’est pas « capituler » ;
c’est être un voisin poli pour que votre courrier arrive.

Task 14: Check the immediate health of the queue filesystem (latency)

cr0x@server:~$ sudo iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              2.00   85.00    64.0  4200.0  48.12   2.10  89.50
sdb              0.00   12.00     0.0   180.0   1.20   0.35   4.20

Signification : sda est fortement utilisé avec un await élevé. Si votre file est sur sda, vous avez un goulot IO.
Les MTAs font beaucoup de comportements similaires à fsync ; la latence IO de la file se transforme en timeouts SMTP et en diffèrés 451.
Décision : Déplacez la file vers un stockage plus rapide, réduisez la pression de sync (avec prudence), ou réduisez le churn de la file (désactiver des logs inutiles,
éviter des partitions de fichier trop petites).

Task 15: Confirm TLS works and certificates aren’t causing stalls

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.yourdomain.com:25 -servername mx1.yourdomain.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.yourdomain.com
Verification: OK

Signification : STARTTLS fonctionne et le certificat se vérifie localement (en supposant que votre trust store est normal).
Décision : Si cela échoue de manière intermittente, vérifiez les certificats expirés, la chaîne rompue, ou la contention CPU pendant les handshakes.
Les problèmes TLS peuvent se manifester comme « problème local temporaire » selon l’endroit où l’échec est géré.

Task 16: Check if your upstream relay is the one deferring you

cr0x@server:~$ sudo grep -E "relay=.*\[.*\]:587|relay=.*:587" /var/log/mail.log | tail -n 10
Jan  4 10:04:11 mx1 postfix/smtp[24321]: 3F9B7402D2: to=<user@bigmail.tld>, relay=relay.provider.tld[192.0.2.50]:587, delay=4.2, dsn=4.7.1, status=deferred (host relay.provider.tld[192.0.2.50] said: 451 4.7.1 Rate limit exceeded, try again later)

Signification : Le « problème local » n’est pas local. Votre relais vous throttle.
Décision : Arrêtez de tuner votre MTA à l’aveugle. Négociez les limites avec le fournisseur, implémentez du shaping sortant, et vérifiez que vous ne faites pas
transiter du trafic spam depuis des comptes compromis.

Carte des causes racines : d’où vient le 451

« Problème local temporaire » est une catégorie de symptômes. Voici la carte que j’utilise en production : classer par étape et par dépendance.
Elle réduit rapidement l’espace de recherche.

Classification par étape

• À la connexion / bannière : listener local surchargé, limites de connexion, file d’acceptation pleine, épuisement du kernel conntrack, problèmes de politique TLS.
• À HELO/EHLO : vérifications reverse DNS, restrictions helo, requêtes au service de politique, décision de greylisting en amont.
• À MAIL FROM / RCPT TO : recherche de destinataire (LDAP/SQL), restrictions d’expéditeur, vérifications SPF, limitation de débit, greylisting.
• À DATA / fin de DATA : timeouts des filtres de contenu, scan antivirus, services de scoring spam, failures d’écriture/disque/commit de la file.
• Après acceptation (bounce ultérieur) : pas du 451 ; c’est là que vous obtenez des DSN ou des pertes silencieuses. Problème différent.

Classification par dépendance (les suspects habituels)

1) Contraintes de stockage et système de fichiers

Si Postfix ne peut pas créer de fichiers de file, n’écrit pas les logs, ou ne peut pas fsync à temps, vous verrez des échecs temporaires.
Les problèmes de stockage apparaissent comme des 451 parce qu’il est plus sûr de différer que d’accepter et de perdre du courrier.

Surveillez :
disque plein, épuisement d’inodes, latence IO élevée, journal saturé, pépins NFS (oui, certains font encore ça), ou overlays de conteneurs anormaux.

2) Instabilité DNS et résolveur

Le DNS n’est pas optionnel. Les MTAs recherchent les enregistrements MX, valident les domaines, effectuent parfois des reverse lookups, et les systèmes de politique consultent TXT (SPF) et autres données.
Si votre résolveur expire, votre transaction SMTP attend. Si elle attend trop longtemps, vous différez. Si vous différez, vous obtenez 451.

3) Filtrage de contenu et milters

Antivirus et antispam sont de fréquentes « usines à 451 ». Ils sont souvent gourmands en CPU, mémoire, et riches en dépendances (mises à jour, règles, réputation externe).
Lorsqu’ils décrochent, ils :
échouent fermés (diffèrent le mail) ou échouent ouverts (acceptent sans scanner). Choisissez consciemment, pas par accident.

4) Services de politique et recherches d’annuaire

La vérification des destinataires, les contrôles d’expéditeur, les limites de débit et l’authentification peuvent faire appel à LDAP, SQL, Redis, APIs HTTP ou démons locaux.
Tout timeout devient « problème local temporaire ».

5) Throttling distant et contrôles de réputation

Parfois, 451 signifie simplement que la partie distante dit : « Vous envoyez trop » ou « Nous ne vous faisons pas encore confiance ».
Les grandes boîtes font cela pour éviter les inondations et forcer un bon comportement sans bloquer définitivement.
La meilleure correction est généralement du shaping sortant et de l’hygiène de réputation, pas des réessais agressifs.

Blague #2 : La file de mail, c’est comme un abonnement à la salle de sport — tout le monde aime l’avoir, personne n’aime vérifier sa taille.

Trois mini-récits d’entreprise (crédibles, douloureux, utiles)

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

Une entreprise SaaS de taille moyenne gérait son propre relais Postfix pour les mails transactionnels. Ils avaient une culture d’incident stricte et une rotation d’astreinte correcte.
Un vendredi, le support signala des « retards d’e-mail » chez quelques clients d’entreprise. Les logs montraient beaucoup de différés 451.

L’ingénieur d’astreinte supposa que c’était le destinataire distant qui les throttle. L’hypothèse semblait raisonnable : ce étaient des 451 en fin de DATA,
et les grandes entreprises throttlent. Ils ajustèrent donc la concurrence par domaine et retournèrent dormir.

Samedi matin, la file différée avait triplé. Pas catastrophique, mais la tendance était mauvaise. Le deuxième ingénieur vérifia l’espace disque
et trouva de la place. Le CPU semblait correct. Le réseau semblait OK. Puis ils remarquèrent quelque chose de subtil : les logs mail cessaient de s’écrire toutes les quelques minutes,
puis étaient écrits en rafales.

Cause racine : épuisement d’inodes sur le système racine, causé par une accumulation silencieuse de petits fichiers temporaires d’une application non liée.
Postfix vivait sur /var (sain), mais syslog écrivait dans /var/log sur /, et lorsque syslog ne pouvait plus écrire, l’équipe perdit la visibilité en temps réel.
Pendant ce temps, le filtre de contenu écrivait des fichiers temporaires dans /tmp sur /, échouant de manière intermittente et provoquant des 451 en fin de DATA.

Correctif : nettoyer les répertoires consommateurs d’inodes, déplacer les chemins temporaires du filtre vers /var, et ajouter de la surveillance d’inodes. La leçon n’était pas seulement « vérifier les inodes » —
c’était : ne jamais accepter une explication externe réconfortante (« throttling distant ») tant que vous n’avez pas prouvé que votre propre système peut écrire des fichiers de façon fiable.

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

Une organisation financière voulait un débit mail interne plus rapide pour les notifications. Quelqu’un remarqua que la file mail était sur des disques lents.
L’optimisation proposée : déplacer /var/spool/postfix sur un système de fichiers réseau « pour la résilience » et libérer l’IO locale.
Le test était petit. Ça a été déployé.

En une semaine, ils virent des 451 temporaires intermittents sur les mails entrants. Pas constants — juste assez pour énerver les humains.
Les erreurs se concentraient pendant les fenêtres de sauvegarde et lors de congestions réseau sporadiques. La file acceptait, puis stallait, puis différait.

Le post-mortem fut douloureux car rien n’était réellement « down ». Le système de fichiers réseau était « up », la latence était « dans le SLA », et les sauvegardes « réussies ».
Mais SMTP n’est pas impressionné par votre SLA ; il se soucie de la latence de queue en queue et du comportement de fsync. Les opérations de file qui étaient sub-millisecondes localement devinrent
des dizaines de millisecondes avec des pointes d’une seconde. Voilà comment on fabrique des timeouts et des 451.

Correctif : remettre la file sur un SSD local, garder la résilience au niveau système (réplication, sauvegardes, configuration reconstruisible),
et réserver les systèmes de fichiers réseau pour des éléments qui ne sont pas sur le chemin synchrone d’une transaction SMTP.
L’« optimisation » a amélioré des moyennes et détruit le p99. Le mail vit au p99.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un prestataire de santé avait des exigences strictes de sécurité et de conformité, ce qui impliquait des scans entrants lourds et des vérifications de politique conservatrices.
Ils avaient aussi une pratique ennuyeuse : chaque dépendance du flux mail avait un health check et un SLO, y compris les résolveurs DNS et le service antispam.
Personne n’en faisait étalage lors des soirées.

Un mardi, ils commencèrent à voir un pic de diffèrés 451 au moment du RCPT. Les utilisateurs le remarquèrent vite car les rappels de rendez-vous étaient retardés.
L’ingénieur d’astreinte consulta le tableau de bord et vit le graphe de latence LDAP devenir une escalier.
En même temps, le service SMTP était lui-même sain.

Ils activèrent un basculement « mode dégradé » pré-approuvé : la vérification des destinataires passa des vérifications LDAP strictes à des recherches mises en cache pour les domaines locaux connus
pendant 30 minutes, tout en maintenant des contrôles stricts pour le relais externe. Cela réduisit immédiatement les diffèrés.

Cause racine : un job de maintenance d’annuaire a causé de la contention de verrous, transformant des recherches rapides en timeouts. Sans SLOs de dépendance,
l’équipe aurait chassé la configuration de Postfix, des règles de firewall, et des attaques fantômes.

Correctif : replanifier le job de maintenance, ajouter du connection pooling et des timeouts, et documenter le mode dégradé avec des garde-fous.
L’ennuyeux a gagné : un rollback propre et de l’observabilité ont transformé le 451 en une nuisance de 20 minutes au lieu d’un incident d’une demi-journée.

Erreurs courantes : symptôme → cause racine → correctif

Ce sont les pièges qui maintiennent les équipes dans la boucle « c’est probablement l’autre ». Soyez meilleurs que ça.

1) Beaucoup de 451 en fin de DATA → timeout du scanner → scaler ou contourner en sécurité

• Symptôme : 451 survient « in reply to end of DATA command », surtout en périodes de charge.
• Cause racine : pipeline antivirus/spam lent ou injoignable ; timeout du milter ; OOM kills.
• Correctif : vérifiez les processus du filtre, les sockets et les timeouts ; ajoutez de la capacité ; ajustez la politique fail-open/closed de façon explicite ; déplacez les répertoires temporaires vers un disque local rapide.

2) 451 au moment du RCPT → dépendance de validation des destinataires cassée → réparer LDAP/SQL/DNS

• Symptôme : « NOQUEUE: reject: RCPT … 451 » et cela corrèle avec la latence de l’annuaire.
• Cause racine : service de lookup destinataire (LDAP/SQL) qui expire ; daemon de politique incapable d’atteindre son backend.
• Correctif : rétablissez la santé de la dépendance ; ajoutez du cache ; ajustez les timeouts ; assurez-vous que les services de politique se dégradent proprement.

3) Raffales de 451 sur de nombreux domaines → problèmes de résolveur DNS → corriger les résolveurs, pas Postfix

• Symptôme : livraisons différées pour des domaines non liés ; les logs montrent des délais de lookup ou « temporary failure in name resolution ».
• Cause racine : résolveur local défaillant, DNS upstream bloqué, démon de cache surchargé, mauvais comportement DNSSEC.
• Correctif : validez l’accessibilité du résolveur ; redémarrez le cache ; utilisez des résolveurs redondants ; réduisez les problèmes DNSSEC ; surveillez la latence des requêtes.

4) La file grossit, mais le CPU semble ok → latence disque → déplacer la file / corriger l’IO

• Symptôme : la file différée croît ; load average bas ; mais la livraison est lente.
• Cause racine : latence tail storage ; filesystem presque plein ; épuisement d’inodes ; commits de journal lents.
• Correctif : vérifiez iostat ; déplacez la file vers SSD ; libérez de l’espace ; augmentez la capacité d’inodes ; évitez le filesystem réseau pour la file.

5) Les domaines distants renvoient 451 4.7.1 → throttling/réputation → shapez le trafic et nettoyez

• Symptôme : le distant ou le relais indique « rate limit exceeded », « try again later », « temporarily deferred ».
• Cause racine : trop de concurrence, campagnes en rafale, compte compromis, mauvaise réputation IP/domaine, PTR manquant.
• Correctif : implémentez des limites par domaine ; corrigez PTR et HELO ; appliquez l’authentification sortante ; faites tourner les identifiants ; mettez en quarantaine les comptes compromis.

6) « On a redémarré Postfix et ça a disparu » → réinitialisations de dépendances cachées → trouvez le maillon faible réel

• Symptôme : un redémarrage « résout » temporairement le 451 ; il revient plus tard.
• Cause racine : le redémarrage réinitialise files, sockets ou cache DNS ; le problème sous-jacent persiste (fuite mémoire, filtre bloqué, résolveur surchargé).
• Correctif : corrélez avec les graphiques de ressources ; identifiez quel sous-système se rétablit au redémarrage ; réparez ce composant et ajoutez de la surveillance.

Listes de contrôle / plan pas à pas

Quand on vous appelle : checklist de triage en 15 minutes

1. Obtenez un exemple concret : un expéditeur, un destinataire, un horodatage, une ligne d’erreur SMTP complète.
2. Déterminez la direction : diffèrés entrants vs diffèrés sortants.
3. Vérifiez disque + inodes sur tout système de fichiers impliqué dans la file, les logs, les temporaires et les filtres.
4. Vérifiez la vitesse DNS depuis l’hôte MTA, pas depuis votre laptop.
5. Vérifiez la croissance de la file : le nombre de différés augmente ? la file active est bloquée ?
6. Vérifiez la santé des filtres/politiques : sockets à l’écoute, processus vivants, OOM kills récents.
7. Vérifiez les réponses des relais en amont : êtes-vous throttlé ?
8. Choisissez la contention : limitez les expéditeurs, suspendez le mail en masse, activez le mode dégradé pour les contrôles non critiques.

Actions de contention (faites-les avant le « tuning profond »)

• Protégez le disque : si la partition de file est en danger, arrêtez les sources non essentielles de mail (marketing, rapports) avant qu’elle ne soit pleine.
• Réduisez la concurrence : shapez le sortant vers les domaines ou relais affectés pour cesser de déclencher des throttles.
• Fail open vs fail closed : décidez explicitement pour les filtres. Si vous devez échouer fermé, scalez-le maintenant, pas plus tard.
• Étendez les intervalles de retry avec prudence : ne créez pas une tempête de réessais. Le backoff est un outil, pas une cachette.

Plan de stabilisation (même jour)

1. Réparez la dépendance réelle : disque, DNS, filtre, annuaire ou réseau.
2. Vidangez la file en sécurité : vérifiez le débit et surveillez IO et latence pendant la vidange.
3. Confirmez par des tests externes de livraison : choisissez quelques domaines représentatifs et validez bout en bout.
4. Mettez en place des garde-fous : monitoring pour inodes, latence résolveur, temps de réponse des filtres et profondeur de file.

Plan de durcissement (cette semaine)

• Séparez les systèmes de fichiers : file, logs et temporaires ne doivent pas se battre sur la même petite partition.
• Définissez des timeouts raisonnables : les daemons de politique doivent échouer vite, pas bloquer indéfiniment les sessions SMTP.
• Introduisez du shaping par domaine : surtout pour les gros récepteurs qui throttlent.
• Audit de qui peut envoyer : auth sortante et limitation de débit par compte/appli empêchent qu’une compromission n’embrase la réputation.
• Organisez un « exercice feu mail » trimestriel : simulez panne DNS, disque presque plein, et outage de filtre ; confirmez que le comportement correspond à vos intentions.

FAQ

1) Le 451 est-il toujours la faute du serveur récepteur ?

Non. Si vous envoyez, le serveur récepteur peut vous différer. Mais votre propre relais, services de politique, scanners, DNS ou stockage peuvent aussi générer un 451.
La ligne de log vous dit qui l’a dit — lisez attentivement la portion host ... said:.

2) Pourquoi certains serveurs utilisent 451 au lieu d’une erreur claire ?

Parce que SMTP attend des réessais, et différer est plus sûr que rejeter lorsqu’un problème peut se résoudre (pics de charge, panne temporaire de backend).
Aussi, certains opérateurs préfèrent les soft blocks pour gérer les abus sans créer de rebonds définitifs.

3) Quelle est la différence entre 451 et 421 ?

Les deux sont temporaires. 421 signifie généralement « service non disponible » et entraîne souvent la fermeture de la connexion.
451 est plus « erreur locale de traitement » et peut survenir à des étapes spécifiques (RCPT/DATA).

4) Nous ne voyons 451 que pour un seul domaine destinataire. Que faire ?

Supposez d’abord un throttling ou un problème distant, mais validez les bases : réputation IP sortante, PTR, nom HELO, et si vous envoyez en rafales.
Mettez en place des limites de concurrence par domaine et un délai de rate. Si ça persiste, contactez les admins mail du destinataire avec horodatages et IDs de file.

5) Le greylisting peut-il en être la cause ?

Oui. Le greylisting renvoie intentionnellement des erreurs temporaires (souvent des variantes 451 ou 4.7.1) aux expéditeurs inconnus.
Si vous exécutez du greylisting, confirmez qu’il n’est pas mal configuré ou surchargé. Si vous êtes l’expéditeur, assurez-vous que votre système réessaye correctement et ne change pas d’IP source.

6) Pourquoi la latence disque provoque-t-elle un 451 au lieu d’une erreur « disque plein » plus évidente ?

Beaucoup de MTAs et filtres traitent les écritures lentes ou échouées comme une condition transitoire pour éviter de perdre du courrier.
S’ils ne peuvent pas committer rapidement les fichiers de file, ils différent plutôt qu’accepter et risquer la corruption ou un traitement partiel.

7) Combien de temps les expéditeurs réessaieront-ils après un 451 ?

Cela varie. Beaucoup de MTAs réessaient pendant des heures à des jours avec backoff exponentiel. Si votre système est celui qui diffère, vous faites subir la douleur en aval.
Corrigez le problème local rapidement ; ne comptez pas sur les réessais pour « lisser » la situation sauf si vous avez validé la capacité de la file et l’impact métier.

8) SPF/DKIM/DMARC peuvent-ils déclencher un 451 ?

Généralement ils provoquent des rejets permanents (5xx) ou une acceptation avec scoring spam. Mais dans les systèmes réels, les services de politique qui effectuent ces vérifications peuvent expirer.
Quand la vérification de politique expire, un serveur peut retourner 451 même si la « vraie » raison est un lookup DNS TXT lent.

9) Nous avons redémarré le filtre et le 451 a cessé. Sommes-nous hors de danger ?

Vous êtes à l’abri pour l’instant. Trouvez pourquoi il a fallu redémarrer : fuite mémoire, OOM kills, mises à jour de règles, IO disque, ou timeouts de dépendance.
Ajoutez de la surveillance pour la santé du processus du filtre et la latence de réponse afin que la prochaine panne ne soit pas une surprise.

10) Devons-nous augmenter les timeouts Postfix pour éviter le 451 ?

Seulement si vous êtes sûr que la dépendance est lente mais correcte et que vous avez la capacité de maintenir des connexions.
Augmenter les timeouts peut convertir des « échecs temporaires » en « sessions bloquées », ce qui est pire sous charge. Réparez la dépendance d’abord.

Conclusion : étapes suivantes pour éviter la répétition

« 451 problème local temporaire » n’est pas un diagnostic ; c’est une invitation à la méthode.
Les gains rapides viennent à traiter le mail comme n’importe quel autre pipeline de production : identifiez le composant qui parle,
puis vérifiez les contraintes qui provoquent le différé — stockage, DNS, filtres, backends de politique, et throttles en amont.

Étapes pratiques :

1. Ajoutez la surveillance d’inodes sur les systèmes de fichiers de file/log/temp, pas seulement le pourcentage disque.
2. Mesurez la latence du résolveur depuis l’hôte MTA et alertez sur les timeouts.
3. Suivez la profondeur et l’âge des files : nombre de différés et âge du message le plus ancien importent plus que « service up ».
4. Instrumentez les filtres et démons de politique : temps de réponse, taux d’erreur, OOM kills.
5. Implémentez du shaping sortant par domaine récepteur majeur et par relais en amont.
6. Rédigez vos choix fail-open/closed pour le scan et les contrôles, puis testez-les lors d’un exercice.

L’objectif n’est pas d’éliminer le 451 pour toujours. L’objectif est de le rendre ennuyeux : rapide à attribuer, rapide à contenir, et rare à répéter.