Postfix : Manuel de crise des files d’attente (quand le courrier s’arrête soudainement)

Playbook de diagnostic rapide (15 premières minutes)

Si le courrier « s’arrête soudainement », vous avez une mission : identifier le goulet d’étranglement qui limite le débit. La seconde mission est de ne pas amplifier accidentellement les dégâts en vidant les files à l’aveugle ou en redémarrant tout dans la panique. Postfix sait livrer lentement et sûrement. Vous pouvez toujours le forcer à livrer rapidement et dangereusement.

Minute 0–2 : Confirmer le mode de défaillance

• Le courrier n’entre-t-il pas dans le système ? (problème d’acceptation SMTP entrant, postscreen, échecs TLS, pare-feu)
• Le courrier entre mais ne sort pas ? (problèmes de livraison distante, croissance de la file deferred)
• Le courrier sort mais met du temps ? (goulot d’étranglement de débit : disque, DNS, filtre de contenu, limites de débit)

Minute 2–5 : Identifier quelle file augmente

• Bouchon à l’étape incoming/cleanup : beaucoup de messages dans maildrop ou activité intense de cleanup
• Bouchon de la file active : active reste énorme ; qmgr ne peut pas déplacer assez vite
• Bouchon de la file deferred : livraison distante échoue ou est lente ; timers de backoff qui s’empilent

Minute 5–10 : Trouver la ressource saturée

• Disque/IOPS : churn dans le répertoire de la file ; tempêtes d’fsync ; contrôleur RAID qui souffre en silence
• DNS : recherches MX lentes, recherches RBL, timeouts DNS
• Réseau : port 25 sortant bloqué/filtré ; perte de paquets ; MTU problématique
• CPU : handshakes TLS, scan de contenu, maps regex, milters
• Limites de concurrence : concurrence par domaine, default_destination_concurrency_limit, limites anvil

Minute 10–15 : Choisir une action sûre

• Si le disque est plein : arrêter l’hémorragie (rejets temporaires), libérer de l’espace, ne pas vider la file.
• Si le DNS est lent : corriger le résolveur ou contourner temporairement les recherches RBL ; ne pas augmenter la concurrence.
• Si un filtre en aval est lent : le contourner ou le mettre à l’échelle ; ne pas redémarrer Postfix en boucle.
• Si un fournisseur distant met en échec : limiter par domaine ; ne pas forcer avec une boucle de flush.

Une citation pour rester honnête. Paraphrasant W. Edwards Deming : « Sans données, vous n’êtes qu’une autre personne avec une opinion. » Dans les défaillances de file d’attente, les opinions sont la façon dont on se retrouve avec un second incident.

Modèle mental de la défaillance de la file d’attente

Postfix est une chaîne de traitement avec des tampons. Quand une étape ralentit, les tampons en amont se remplissent. Votre travail est de localiser l’étape lente et soit l’accélérer, soit réduire l’entrée pour que le système puisse se vider. Le danger est que la file elle-même devienne la charge : chaque message est un petit fichier, chaque nouvelle tentative génère plus d’IO disque, chaque rebond produit davantage de courrier.

Ce que « panne » veut dire réellement

Une véritable défaillance de file d’attente n’est pas juste « beaucoup de courrier ». C’est « le système passe plus de temps à gérer la file qu’à livrer le courrier ». On l’observe par :

• croissance rapide des files deferred et/ou active
• charge moyenne qui grimpe sans débit utile correspondant
• utilisation disque et attente IO en hausse
• lignes de logs répétant les mêmes échecs temporaires
• processus mail qui s’accumulent : smtp, qmgr, cleanup, trivial-rewrite, tlsmgr

Trois catégories d’arrêt

1. Arrêt d’acceptation : connexions entrantes échouent, soumissions échouent ou les messages ne peuvent pas être mis en file.
2. Arrêt de planification : les messages sont en file mais qmgr ne peut pas planifier/livrer assez vite.
3. Arrêt de livraison : la livraison distante échoue, est lente ou est limitée, donc deferred domine.

La clé est de résister à la tentation de « tout vider ». C’est comme résoudre un embouteillage en ouvrant toutes les bretelles d’accès et en demandant aux gens de rouler plus vite. Le bouchon se déplace juste vers l’intersection suivante, généralement le disque.

Blague n°1 : SMTP signifie « Sometimes Mail Takes a Pause ». Malheureusement, la pause a toujours lieu pendant les heures de bureau.

Faits intéressants et contexte historique

Le courrier est plus ancien que le branding de votre fournisseur cloud, et beaucoup de ses aspérités sont des artéfacts historiques. Quelques faits concrets qui aident pendant les incidents :

1. Postfix a été conçu comme une alternative sécurisée à Sendmail, avec plusieurs petits processus pour réduire la portée d’un incident.
2. SMTP a été créé pour un Internet plus accueillant ; les échecs temporaires et les retries sont fondamentaux, pas une exception — votre file est une fonctionnalité voulue.
3. Le comportement de backoff est délibéré : Postfix n’harcèle pas continuellement un domaine distant ; il espace les tentatives pour être poli et éviter l’auto-DDoS.
4. Le design « file d’attente en fichiers » signifie que les performances de stockage comptent bien plus que ce que beaucoup d’équipes anticipent ; des milliers d’opérations sur petits fichiers peuvent terrasser un disque lent.
5. Le DNS fait partie du chemin critique pour la livraison distante. Quand les résolveurs sont lents, le courrier « s’arrête » même si Postfix est sain.
6. Le greylisting est revenu à la mode à l’ère du spam ; il provoque volontairement des échecs temporaires, ce qui peut faire exploser la taille de la file si vous ne prévoyez pas la capacité.
7. Les recherches RBL sont une dépendance cachée : un fournisseur de blacklist lent ou cassé peut bloquer les sessions SMTP et affamer le débit.
8. TLS partout a augmenté le coût CPU par connexion ; sur des relais chargés, le coût du handshake est un facteur de montée en charge, pas une erreur d’arrondi.
9. Le throttling des fournisseurs de boîtes mail est normal : les grands fournisseurs différeront agressivement quand vous augmentez le volume ou heurtez des contrôles de réputation ; vous ne pouvez pas « dépasser la réputation » par la seule concurrence.

Tâches pratiques : commandes, ce que le résultat signifie, quelle décision en tirer

Voici les tâches que j’exécute quand la pager sonne. Chacune a trois parties : commande, comment la lire, et la décision qu’elle impose. Utilisez-les dans l’ordre, pas à la carte.

Tâche 1 : Confirmer que Postfix est actif et ce qu’il pense faire

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 Tue 2026-02-04 09:12:08 UTC; 2h 14min ago
   Main PID: 1243 (master)
      Tasks: 6 (limit: 18689)
     Memory: 21.3M
     CGroup: /system.slice/postfix.service
             ├─1243 /usr/lib/postfix/sbin/master -w
             ├─1301 qmgr -l -t unix -u
             ├─1302 pickup -l -t unix -u
             └─1303 tlsmgr -l -t unix -u

Signification : Si Postfix n’est pas actif, vous êtes en territoire « service down ». S’il est actif, le problème vient généralement en aval (DNS, réseau, distant, filtres) ou en amont (disque plein, permissions).

Décision : Si inactive/failed, vérifiez les logs du journal immédiatement avant de redémarrer. Si active, ne redémarrez pas par réflexe ; rassemblez d’abord des preuves.

Tâche 2 : Voir la taille et la forme de la file en un coup d’œil

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2456 Tue Feb  4 11:23:05  alerts@example.net
                                         user1@corp.tld

F6G7H8I9J0     1879 Tue Feb  4 11:23:06  noreply@corp.tld
                                         external@bigmail.tld

-- 4821 Kbytes in 217 Requests.

Signification : La dernière ligne est le titre. Les requests sont des entrées de file ; pas nécessairement des e-mails uniques si vous avez plusieurs destinataires par message.

Décision : Si les requests augmentent rapidement, passez à « quelle file grandit » et « pourquoi la livraison échoue ».

Tâche 3 : Séparer les comptes active vs deferred vs maildrop

cr0x@server:~$ postqueue -p | tail -n 1
-- 4821 Kbytes in 217 Requests.

cr0x@server:~$ find /var/spool/postfix/active -type f | wc -l
53

cr0x@server:~$ find /var/spool/postfix/deferred -type f | wc -l
10241

cr0x@server:~$ find /var/spool/postfix/maildrop -type f | wc -l
0

Signification : Un énorme deferred avec peu d’active signifie souvent que la livraison distante échoue/est throttlée. Un gros maildrop peut indiquer des problèmes pickup/cleanup ou un filtre de contenu lent.

Décision : Gros deferred : concentrez-vous sur les réponses distantes et le réseau/DNS. Gros maildrop : concentrez-vous sur le pipeline local (cleanup, milters, disque, permissions).

Tâche 4 : Lire les 15 dernières minutes de logs mail comme un adulte

cr0x@server:~$ journalctl -u postfix --since "15 min ago" --no-pager | tail -n 80
Feb 04 13:18:02 server postfix/smtp[22190]: connect to bigmail.tld[203.0.113.10]:25: Connection timed out
Feb 04 13:18:02 server postfix/smtp[22190]: A1B2C3D4E5: to=<external@bigmail.tld>, relay=none, delay=620, delays=0.1/0.1/620/0, dsn=4.4.1, status=deferred (connect to bigmail.tld[203.0.113.10]:25: Connection timed out)
Feb 04 13:18:05 server postfix/qmgr[1301]: warning: private/anvil: connection refused
Feb 04 13:18:05 server postfix/master[1243]: warning: process /usr/lib/postfix/sbin/anvil pid 22144 exit status 1

Signification : « Connection timed out » pointe vers la sortie réseau, un blocage pare-feu, un blocage fournisseur ou un routage. Anvil failing est un symptôme local (épuisement de ressources, limites ou problème de système de fichiers).

Décision : Pour les timeouts, validez la connectivité sortante et la politique du port 25. Pour les échecs anvil, vérifiez l’espace disque/inodes et les limites de processus avant un redémarrage.

Tâche 5 : Vérifier la connectivité sortante sur le port 25 vers le monde

cr0x@server:~$ nc -vz -w 5 203.0.113.10 25
nc: connect to 203.0.113.10 port 25 (tcp) timed out: Operation now in progress

Signification : Si ceci timeoute largement, votre chemin réseau est bloqué ou cassé. S’il fonctionne vers certains hôtes mais pas d’autres, vous traitez peut-être un blocage fournisseur ou un routage spécifique.

Décision : Si le port 25 sortant est bloqué, arrêtez d’ajuster Postfix et commencez à parler à votre équipe réseau ou fournisseur cloud. Aucun vidage de file ne résoudra une politique.

Tâche 6 : Inspecter la santé DNS et la latence des requêtes

cr0x@server:~$ dig +tries=1 +time=2 MX bigmail.tld
;; communications error to 10.0.0.53#53: timed out
;; no servers could be reached

Signification : Si le DNS ne peut pas répondre rapidement, Postfix ne peut pas router le courrier de façon fiable. Vous verrez des deferrals, des sessions lentes et des files qui grossissent.

Décision : Corrigez d’abord les résolveurs (accessibilité, performance, cache). Envisagez de réduire temporairement les vérifications dépendantes du DNS (RBL) pendant l’incident — en sécurité, avec rollback clair.

Tâche 7 : Identifier les principales raisons de report

cr0x@server:~$ grep -h "status=deferred" /var/log/mail.log | tail -n 2000 | sed -E 's/.*deferred \((.*)\)$/\1/' | sort | uniq -c | sort -nr | head
  312 connect to bigmail.tld[203.0.113.10]:25: Connection timed out
  141 host mx.other.tld[198.51.100.25] said: 451 4.7.1 Try again later
   88 lost connection with mx.slow.tld[192.0.2.77] while receiving the initial server greeting

Signification : Cela transforme une plainte « le mail est en panne » en causes classées. Les timeouts diffèrent des 451 ; les corrections diffèrent aussi.

Décision : Timeouts : réseau. 451 try later : throttling distant/réputation, donc limiter. Lost greeting : distant lent/surchargé ou réseau instable ; réduire la concurrence et les timeouts.

Tâche 8 : Vérifier si vous êtes lié par le CPU ou par l’IO

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1      0 184320  22112 612300    0    0   120   980  900 1400 12  8 55 25  0
 3  2      0 182900  22120 612400    0    0   110  2200 1100 1800 10  7 40 43  0

Signification : Un wa élevé signifie attente IO : le disque est le goulet. Un us/sy élevé signifie limitation CPU (TLS, milters, scan).

Décision : Attente IO élevée : réduire le churn de la file, ralentir l’entrée, envisager de déplacer les files sur un stockage plus rapide. CPU élevé : réduire le overhead TLS, mettre à l’échelle le scanning, ou réduire la concurrence jusqu’à stabilisation.

Tâche 9 : Vérifier l’espace du filesystem spool et l’épuisement des inodes

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  700M  97% /

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

Signification : Les files de courrier consomment beaucoup d’inodes. Vous pouvez avoir de l’espace libre et être tout de même bloqué, ou avoir des inodes et être bloqué. Dans les deux cas, l’utilisateur perçoit « le courrier s’est arrêté ».

Décision : Si l’espace/les inodes sont faibles : arrêter d’accepter le courrier non essentiel, nettoyer les déchets non liés au courrier et planifier une vidange contrôlée. Ne lancez pas une boucle de flush sur un système de fichiers à 97 %.

Tâche 10 : Vérifier quels processus Postfix s’accumulent

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,args --sort=-pcpu | head -n 15
 22501 smtp       22.4  0.2 postfix/smtp
 22480 smtp       18.1  0.2 postfix/smtp
 22310 cleanup    12.5  0.1 postfix/cleanup
 1301  qmgr        6.2  0.2 qmgr -l -t unix -u
 1243  master      0.1  0.1 /usr/lib/postfix/sbin/master -w

Signification : Beaucoup de smtp peut indiquer un ralentissement distant ou que vous avez autorisé trop de concurrence. Un cleanup élevé peut signaler des header_checks, milters ou contentions disque.

Décision : Si smtp domine et que les deferrals sont distants : throttlez et réduisez la concurrence. Si cleanup domine : inspectez les filtres de contenu, les maps et la santé du disque.

Tâche 11 : Confirmer quelles limites Postfix utilise réellement

cr0x@server:~$ postconf -n | egrep -i 'queue|concurrency|recipient|timeout|anvil|milter|smtpd_client|stress|dns'
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_connect_timeout = 30s
smtp_helo_timeout = 30s
smtp_data_xfer_timeout = 180s
smtpd_milters = inet:127.0.0.1:8891
milter_command_timeout = 30s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Signification : Cela vous dit si vous êtes réglé pour un débit sain ou le chaos. Les timeouts de milter et DNS sont des tueurs silencieux courants.

Décision : Si la concurrence est élevée et que les distants sont lents, réduisez-la. Si les timeouts sont trop stricts, vous pourriez provoquer des deferrals auto-infligés ; ajustez prudemment et testez.

Tâche 12 : Localiser les principaux domaines destinataires obstruant la file

cr0x@server:~$ postqueue -p | awk '/^[A-F0-9]/ {id=$1} /@/ {print $NF}' | sed -n 's/.*@//p' | tr -d '><,' | sort | uniq -c | sort -nr | head
  842 bigmail.tld
  317 other.tld
  205 slow.tld

Signification : Souvent un domaine de destination domine. C’est votre levier : limiter ce domaine au lieu de punir tout le monde à parts égales.

Décision : Appliquez des limites de concurrence par domaine ou des transport maps pour isoler le fautif. Ne montez pas la concurrence globale pour « vider plus vite ».

Tâche 13 : Inspecter en sécurité l’histoire d’un seul fichier de file

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS active A1B2C3D4E5 ***
message_size:            2456
message_arrival_time: Tue Feb  4 11:23:05 2026
sender: alerts@example.net
named_attribute: log_ident=postfix/smtp
recipient: external@bigmail.tld
*** MESSAGE CONTENTS A1B2C3D4E5 ***
Received: from app01 (app01 [10.10.10.21])
        by server (Postfix) with ESMTP id A1B2C3D4E5
        for <external@bigmail.tld>; Tue,  4 Feb 2026 11:23:05 +0000 (UTC)
Subject: Alert: job failed

Signification : Vous pouvez confirmer expéditeur, destinataire et horodatage sans deviner. Utile lorsqu’on prétend « ça n’est jamais parti de notre appli ».

Décision : Si les temps d’arrivée sont anciens et que les retries échouent en boucle, ne le traitez pas comme transitoire ; cela peut être une politique (IP bloquée, réputation, filtrage sortant).

Tâche 14 : Mesurer le comportement du gestionnaire de file et les avertissements

cr0x@server:~$ postqueue -j | head -n 5
{"queue_name":"deferred","queue_id":"A1B2C3D4E5","arrival_time":1707055385,"message_size":2456,"sender":"alerts@example.net","recipients":["external@bigmail.tld"]}
{"queue_name":"deferred","queue_id":"F6G7H8I9J0","arrival_time":1707055386,"message_size":1879,"sender":"noreply@corp.tld","recipients":["external@bigmail.tld"]}

Signification : La sortie JSON est script-friendly. Vous pouvez échantillonner et construire des comptes rapides sans parser le format humain.

Décision : Utilisez ceci pour des remédiations ciblées (throttling par domaine, identification des gros messages) plutôt que des vidages aléatoires.

Tâche 15 : Throttler en sécurité par destination (chirurgical, pas global)

cr0x@server:~$ postconf -e "smtp_destination_concurrency_limit=10"
cr0x@server:~$ postconf -e "default_destination_concurrency_limit=10"
cr0x@server:~$ systemctl reload postfix

Signification : Baisser la concurrence réduit la pression sur le disque, le DNS et les serveurs distants. Reload est plus sûr que restart pendant des files lourdes.

Décision : Si vous timeoutez ou voyez des 451, le throttling améliore souvent le débit en réduisant les retries et le churn de connexion.

Tâche 16 : Mettre en pause l’entrée quand le spool meurt

cr0x@server:~$ postconf -e "smtpd_soft_error_limit=5"
cr0x@server:~$ postconf -e "smtpd_hard_error_limit=10"
cr0x@server:~$ systemctl reload postfix

Signification : Ce n’est pas un arrêt complet, mais cela pousse les clients abusifs/brisés à ralentir. Pour une vraie pause d’entrée, vous pouvez firewaller temporairement ou ajuster master.cf, mais commencez par des freins doux.

Décision : Si disque/inodes sont proches de l’épuisement, vous devez réduire l’entrée. Vider ne peut pas gagner la course contre une source infinie.

Tâche 17 : Déclencher un requeue contrôlé (uniquement quand vous savez pourquoi)

cr0x@server:~$ postqueue -f
cr0x@server:~$ postqueue -p | tail -n 1
-- 4809 Kbytes in 214 Requests.

Signification : Flush demande à Postfix de retenter plus tôt. Cela peut aider après la correction d’un DNS ou d’un réseau. Cela peut aussi faire exploser votre disque si la cause racine est toujours présente.

Décision : Ne flush que après avoir corrigé le goulet et réduit la concurrence si nécessaire. Flush est un « réessaye maintenant », pas un « fais disparaître tout ».

Tâche 18 : Vérifier la latence du système de fichiers qui tue le débit

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    7.44   41.20    0.00   41.24

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              8.10  210.30   220.1  5400.7  58.4   3.9   92.1

Signification : Un await élevé et un %util élevé suggèrent que le périphérique est saturé. Les opérations de file Postfix sont sensibles à la latence, pas gourmandes en bande passante.

Décision : Si le stockage est saturé, limitez la concurrence, déplacez la file vers un stockage plus rapide ou réduisez temporairement la journalisation/le filtrage. N’augmentez pas la concurrence.

Où Postfix fond : goulets d’étranglement courants

1) Stockage : votre file est un benchmark de petits fichiers que vous n’avez pas demandé

Postfix utilise le système de fichiers comme file durable. Cela signifie que les opérations métadonnées, les recherches de répertoire, le comportement d’fsync et la disponibilité des inodes comptent. Quand les files grossissent, Postfix effectue plus d’opérations fichiers : create, rename, unlink, stat, open, close. Multipliez par des milliers et vous n’êtes pas « en train d’envoyer des e-mails ». Vous chargez ext4/XFS et tout ce qui se trouve en dessous.

Schéma de défaillance : l’attente IO monte, qmgr et cleanup semblent occupés, le débit chute, la file s’accroît plus vite, puis le disque se remplit de mail deferred et de logs. Le système devient une machine de thrash disque en forme de mail.

2) DNS : la dépendance silencieuse qui peut arrêter toute livraison

Chaque livraison distante a besoin du DNS : recherche MX, A/AAAA, parfois PTR, plus toutes vérifications de politique que vous ajoutez. Les échecs DNS apparaissent souvent comme des timeouts et du courrier différé, ce qui donne l’impression que « Postfix est cassé » alors qu’il s’agit en réalité de votre résolveur, du chemin réseau vers lui ou d’une couche de cache surchargée.

Coupable fréquent : recherches RBL ou de réputation. Ce sont aussi des requêtes DNS. Un upstream lent peut ajouter des secondes à chaque session SMTP, ce qui, à l’échelle, devient un arrêt complet.

3) Politique réseau : la réalité du port 25

Beaucoup d’environnements bloquent le port 25 sortant par défaut. Certains le font silencieusement. Si votre relais est dans un réseau cloud avec une politique egress stricte, vous pouvez vous retrouver avec des « connect timed out » vers de nombreuses destinations. Ce n’est pas Postfix. C’est la réalité.

Autre mode de défaillance réseau : routage asymétrique, pare-feu stateful qui expire les sessions SMTP inactives, ou gateways NAT atteignant des limites de connexions. Lors d’une défaillance de file, vous créez beaucoup de connexions. Les tables NAT n’aiment pas ça.

4) Filtres de contenu et milters : la taxe sur le débit

Si vous exécutez Amavis, ClamAV, SpamAssassin, OpenDKIM, OpenDMARC ou des milters personnalisés, félicitations : vous avez un système distribué. N’importe quelle partie peut ralentir, bloquer ou échouer, et Postfix mettra votre douleur en file d’attente consciencieusement.

Symptôme typique : maildrop augmente, processus cleanup montent, logs montrent des timeouts de milter ou « queue file write error ». Une mise à jour lente d’antivirus peut ressembler à une panne complète de mail.

5) Throttling distant et réputation : « 451, try again later » est une décision de politique

Quand un fournisseur majeur renvoie des réponses 4xx, il vous dit de ralentir. Ils peuvent limiter le débit, détecter des pics ou pénaliser la réputation. La pire réaction est d’augmenter la concurrence et de flush. Cela augmente les tentatives de connexion, les deferrals et use encore plus votre réputation.

Meilleure réponse : throttle par domaine, espacer les retries, corriger SPF/DKIM/DMARC, et arrêter d’envoyer des déchets. Si vous envoyez un courrier légitime, stabilisez votre pattern d’envoi.

Blague n°2 : « On redémarre juste Postfix » est l’équivalent mail de l’éteindre/rallumer — sauf que votre laptop n’a pas une file deferred de regrets.

Schémas de récupération qui n’aggravent pas la situation

Stabiliser d’abord : réduire la charge entrante avant d’« optimiser »

Les défaillances de file surviennent souvent pendant des pics : campagnes marketing, tempêtes de réinitialisations de mot de passe, floods d’alertes ou compte compromis envoyant du spam. Si vous continuez d’accepter à pleine vitesse, vous pariez que votre stockage peut rattraper le pic. Ce n’est pas un bon pari la plupart du temps.

Options de stabilisation, de la moins invasive à la plus invasive :

• Throttler la concurrence pour réduire le churn de connexion et l’activité disque.
• Désactiver temporairement les vérifs coûteuses (comme une RBL lente) si c’est clairement le goulot et que vous acceptez le risque.
• Limiter le débit des clients abusifs via postscreen/anvil ou règles pare-feu.
• Rejeter temporairement le courrier non critique (pour certains expéditeurs/domaines) tout en préservant les flux essentiels.

Vidanger intelligemment : cibler les fautifs

Quand la file deferred est dominée par un ou deux domaines (fréquent avec les gros fournisseurs), isolez-les. Si vous traitez toutes les destinations de la même façon, vos destinations saines sont pénalisées par la malade.

Approche pratique :

• Trouver les domaines principaux dans la file.
• Appliquer throttling par destination (via transport maps ou paramètres de concurrence).
• Laisser tout le reste circuler normalement.

Prudence avec flush et requeue

Flush est approprié après correction d’un problème transitoire d’infra : outage DNS, changement de politique réseau, redémarrage de résolveur, rollback de pare-feu. Ce n’est pas approprié si le distant différera encore ou si votre disque est en feu.

Méfiez-vous aussi des habitudes de « requeue tout ». Requeuer touche chaque message et peut produire plus d’IO que le backlog initial. Si votre goulot est le disque, requeuer, c’est faire du cardio au composant déjà épuisé.

Savoir quand séparer les rôles : relais vs mailbox vs submission

Une des façons les plus fiables d’éviter les meltdowns est architecturale : séparer la soumission entrante du relais sortant, ou isoler le mail en masse du mail transactionnel. Lors d’un incident, la file du bulk ne doit pas priver les réinitialisations de mot de passe.

Si vous ne pouvez pas séparer physiquement, séparez logiquement : IP séparées, transports séparés, répertoires de file séparés (avancé) ou instances de service séparées. L’objectif est de contenir les modes de défaillance.

Mesures spécifiques au stockage (ce que les SRE détestent apprendre à 3 h du matin)

Si l’IO est le goulot :

• Ne pas aggraver : réduire concurrence et taux d’entrée. Chaque cycle de retry est un IO supplémentaire.
• Envisager de déplacer la file vers un stockage plus rapide (NVMe, meilleure politique cache RAID, volume dédié). Ce n’est pas un mouvement « pendant l’incident » à moins de l’avoir répété en exercice.
• Chercher des hogs IO externes sur le même filesystem : tempêtes de logs, sauvegardes, scans antivirus du spool (oui, ça arrive).

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : la file deferred grossit, les logs montrent « connect timed out »

Cause racine : port 25 sortant bloqué, problème de routage, limites pare-feu/NAT, ou IP distante inaccessible.

Correction : validez la connectivité avec nc vers plusieurs MX ; vérifiez les politiques egress ; réduisez la concurrence ; stoppez les boucles de flush ; engagez réseau/fournisseur.

2) Symptom : maildrop grossit, processus cleanup montent

Cause racine : milter/filtre de contenu lent, disque lent, ou vérifications header/body lourdes.

Correction : inspectez les timeouts de milter dans les logs ; contournez temporairement les milters non critiques ; mettez à l’échelle le service de filtrage ; confirmez l’attente IO ; réduisez l’entrée.

3) Symptom : la file est énorme, mais active est petite et continue de tourner

Cause racine : throttling distant ou deferrals de politique provoquant un cadence de retry lente ; ou concurrence par destination trop basse pour votre profil de trafic.

Correction : identifiez les domaines principaux et les messages de deferral ; appliquez throttling par domaine et une stratégie de retry raisonnable ; améliorez la réputation et les patterns d’envoi.

4) Symptom : Postfix logge « queue file write error » ou « No space left on device »

Cause racine : disque plein ou épuisement des inodes sur le filesystem spool.

Correction : libérez immédiatement espace/inodes ; arrêtez d’accepter les mails volumineux/en masse temporairement ; déplacez les logs ; nettoyez les gros fichiers non liés ; puis vidangez lentement.

5) Symptom : CPU élevé, beaucoup de processus smtp, logs liés à TLS

Cause racine : overhead des handshakes TLS, trop de connexions sortantes simultanées, ou VM sous-dimensionnée en CPU.

Correction : réduisez la concurrence ; assurez-vous de ne pas effectuer d’opérations coûteuses par message ; envisagez le reuse de sessions ; allouez du CPU ou déplacez la charge.

6) Symptom : tout est lent, timeouts DNS, délivrabilité intermittente

Cause racine : résolveur cassé/surchargé, resolv.conf mal configuré, serveurs DNS inaccessibles, ou RBL provoquant des requêtes lentes.

Correction : réparez la connectivité et le cache du résolveur ; retirez temporairement les vérifications DNS les plus lentes ; confirmez avec dig la latence et le taux d’erreur.

7) Symptom : les utilisateurs signalent « envoyé » mais rien n’arrive ; pas de croissance de file

Cause racine : problème de couche de soumission (auth, TLS, pare-feu), application pointant vers un mauvais relais, ou mail routé ailleurs.

Correction : vérifiez les logs de submission (smtpd), les échecs d’authentification et les configs applicatives ; confirmez que les messages apparaissent dans la file via postcat ou les logs.

Checklists / plan étape par étape

Checklist A : incident « Le mail s’est arrêté » (30–60 minutes)

1. Confirmer l’étendue : inbound uniquement, outbound uniquement, ou les deux. Vérifiez la file et les logs.
2. Identifier le type de file qui grandit : maildrop vs active vs deferred. Utilisez les comptes de répertoire.
3. Classer les raisons d’échec : parsez les N derniers deferrals depuis les logs.
4. Vérifier l’espace disque et les inodes : filesystem spool d’abord.
5. Vérifier le DNS : santé des résolveurs et vitesse des recherches MX.
6. Vérifier le port 25 sortant : test de connexion vers quelques IP MX de destination.
7. Vérifier la saturation : vmstat/iostat pour attente IO vs CPU.
8. Choisir un levier : throttler, contourner un filtre, corriger le DNS, corriger l’egress, arrêter l’entrée.
9. Appliquer le changement via reload : préférez systemctl reload postfix aux redémarrages.
10. Réévaluer toutes les 5 minutes : tendance de la file, tendance des raisons de deferral, tendance IO disque.
11. Ensuite seulement envisager le flush : après correction du goulet et concurrence raisonnable.
12. Communiquer clairement : ce qui est cassé, ce qui est atténué, la prochaine étape et le temps de vidage estimé.

Checklist B : vidange contrôlée après correction DNS/réseau

1. Réduire temporairement la concurrence pour éviter une ruée.
2. Effectuer un flush une fois.
3. Surveiller l’attente IO et la tendance de la file pendant 10–15 minutes.
4. Si stable, augmenter la concurrence par petits paliers.
5. Arrêter l’augmentation quand l’attente IO augmente fortement ou que les deferrals reviennent.

Checklist C : quand le stockage est le goulot

1. Arrêter d’accepter les sources de mail optionnelles (bulk/alerts) si possible.
2. Réduire globalement la concurrence.
3. Trouver et tuer les IO non liés au mail sur le volume spool (backups, scans).
4. Libérer espace/inodes ; faire tourner les logs ; déplacer les gros fichiers hors du filesystem.
5. Vider lentement ; éviter les opérations de requeue qui réécrivent tout le spool.
6. Planifier une refonte du stockage de la file après l’incident.

Trois mini-histoires d’entreprise du terrain

Mini-histoire 1 : La panne causée par une mauvaise hypothèse

L’entreprise avait une architecture « simple » : les applis envoyaient le mail à un relais Postfix, le relais envoyait vers Internet. Le relais vivait sur une VM avec un CPU correct et ce qui semblait être suffisamment de disque. Tout le monde supposait que l’e-mail était faible en bande passante, donc ça ne pouvait pas stresser le stockage.

Un lundi, une tempête de réinitialisations de mot de passe a frappé après un changement SSO. Le relais acceptait le mail sans souci. Puis la file deferred a commencé à grossir. Les utilisateurs ont crié. L’ingénieur on-call a redémarré Postfix deux fois — parce que c’est ce que font les gens quand ils veulent se sentir impliqués.

Le vrai problème était l’épuisement des inodes. Le système de fichiers avait de l’espace libre mais plus d’inodes disponibles sur la partition root où /var/spool/postfix vivait. La file était faite de petits fichiers ; chaque message était une taxe d’inode. Le système n’était pas « down », il étouffait sur les métadonnées.

Une fois qu’ils ont vérifié df -i, la correction fut banale : libérer des inodes en nettoyant des artefacts non-mail et déplacer le spool vers un filesystem correctement dimensionné avec une densité d’inodes adéquate. Le redémarrage n’a pas été néfaste, mais il a gaspillé la seule chose qu’on ne peut pas reconstituer pendant un incident : le temps.

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

Une autre organisation exploitait un relais à haut volume et voulait « vider les files plus vite ». Quelqu’un a augmenté les limites de concurrence par destination et raccourci le backoff des retries. Ça brillait en test calme. Les messages partaient vite.

Puis un résolveur DNS upstream a eu une latence intermittente. Avec une forte concurrence, Postfix a ouvert plus de sessions SMTP, ce qui a déclenché plus de recherches DNS, ce qui a encore plus surchargé le résolveur. La livraison a ralenti, les retries se sont accumulés et la file a gonflé. Le disque du relais a atteint une forte attente IO, puis les logs sont devenus un mur de deferrals répétés.

Ils avaient optimisé pour des conditions idéales et construit par accident une boucle de rétroaction en cas d’échec. La forte concurrence avait amplifié la fragilité DNS ; le backoff réduit avait augmenté le churn de retries ; le spool est devenu une usine à travail inutile.

La correction a été d’inverser l’« optimisation » et de la rendre résiliente : concurrence raisonnable, comportement de backoff par défaut, et un chemin résolveur durci avec cache et monitoring. La file se vidait plus lentement les jours parfaits et bien plus vite les jours imparfaits — qui sont précisément les jours pour lesquels il faut concevoir.

Mini-histoire 3 : La pratique ennuyeuse qui a sauvé la journée

Une entreprise liée à la finance avait un contrôle de changement strict et une habitude que les ingénieurs aiment se moquer : ils documentaient les « bons » réglages Postfix et gardaient un runbook léger pour les incidents mail. Personne n’en parlait. C’était juste là.

Un après-midi, le mail sortant a commencé à différer avec « Try again later » chez un grand fournisseur de boîte mail. La file a grossi, mais pas explosivement. L’ingénieur on-call a sorti le runbook et a suivi un script simple : identifier les domaines principaux, appliquer du throttling par domaine, éviter les boucles de flush globales et maintenir le courrier transactionnel en flux.

Ils avaient aussi des tableaux de bord préexistants pour l’utilisation du filesystem spool et la latence des résolveurs. En quelques minutes, ils ont confirmé que le DNS allait bien et que le fournisseur throttlait. Ils ont throttlé la destination, communiqué le temps de vidage estimé, et empêché l’incident de devenir une crise.

Le fournisseur a récupéré plus tard dans la soirée. La file s’est vidée pendant la nuit. Pas d’héroïsme, pas de tempêtes de requeue, pas d’histoire « on a redémarré et ça a marché ». Le meilleur incident est celui qui reste ennuyeux.

FAQ

1) Dois-je redémarrer Postfix pendant une défaillance de file d’attente ?

Rarement. Reload est généralement plus sûr. Restart peut interrompre des sessions en vol et provoquer plus de churn de file. Redémarrez uniquement si un processus est bloqué et que vous avez identifié la raison.

2) Est-il sûr d’exécuter postqueue -f quand la file est énorme ?

Sûr pour l’intégrité des données, risqué pour la stabilité du système. Flush augmente la pression de retry immédiatement. Utilisez-le après avoir corrigé une cause transitoire (DNS restauré, pare-feu corrigé), et envisagez de baisser la concurrence d’abord.

3) Pourquoi deferred est énorme mais active est petite ?

Parce que Postfix planifie un nombre limité de livraisons actives et diffère le reste, surtout quand la livraison distante échoue ou est limitée. La petite file active peut être signe de politesse, pas de faiblesse.

4) Quelle est la manière la plus rapide de trouver la cause racine ?

Classer les raisons de deferral depuis les logs, puis valider la dépendance pertinente : port 25 sortant pour les timeouts, DNS pour les problèmes de recherche, stockage pour l’attente IO et l’épuisement des inodes. Ne devinez pas.

5) Comment savoir si le goulet est le DNS ?

Si dig timeoute ou est lent, et que les logs montrent des échecs liés au DNS ou des « no servers could be reached ». Aussi, si les sessions SMTP se bloquent avant même de se connecter aux MX distants, le DNS est souvent en cause.

6) La file peut-elle provoquer l’épuisement du disque même après le pic initial ?

Oui. La file génère des IO continus à cause des retries, des écritures de logs et des rebonds. Si votre backoff est agressif ou que la concurrence est trop élevée, la file devient une charge auto-entretenue.

7) Et si un seul fournisseur me diffère ?

C’est courant. Isolez-le : throttlez par destination, réduisez la concurrence pour ce domaine et laissez passer le reste. Ensuite travaillez la réputation, l’authentification et des patterns d’envoi réguliers.

8) Pourquoi me soucier des inodes ? J’ai de l’espace disque libre.

Parce que la file est composée de nombreux petits fichiers. Si vous manquez d’inodes, vous ne pouvez pas créer de fichiers de file même avec des octets disponibles. C’est une panne classique « le système semblait ok jusqu’à ce qu’il ne le soit plus ».

9) Comment savoir si un milter est le problème ?

Cherchez des messages de timeout de milter, une augmentation du maildrop et une activité cleanup élevée. Contourner temporairement le milter (si autorisé) est un test de confirmation rapide.

10) Dois-je supprimer la file pour récupérer plus vite ?

Seulement si vous choisissez explicitement la perte de données et avez l’approbation nécessaire. Supprimer des files peut violer des politiques, faire perdre des mails clients et créer des problèmes juridiques. Il existe des leviers plus sûrs : throttling, stopper l’entrée, corriger les dépendances.

Prochaines étapes (la partie ennuyeuse qui évite le drame)

Si vous êtes en plein incident : arrêtez de vider à l’aveugle, identifiez le type de file qui grandit, classez les raisons de deferral, et vérifiez les trois grandes dépendances — stockage, DNS, egress réseau. Puis appliquez un changement contrôlé et mesurez la tendance. Répétez. Les incidents se terminent quand la file diminue, pas quand quelqu’un dit « ça devrait aller maintenant ».

Après l’incident, faites le travail ingrat :

• Mettre en place la surveillance de l’espace spool et des inodes sur des tableaux de bord avec alerting.
• Surveiller la latence DNS et le taux d’erreur depuis l’hôte mail, pas depuis une sonde happy-path.
• Documenter et appliquer des valeurs de concurrence raisonnables, plus des procédures de throttling par domaine.
• Séparer les chemins transactionnel vs bulk si le mail compte pour votre activité (ça compte).
• Pratiquer une vidange contrôlée en fenêtre de maintenance pour ne pas improviser à 3 h du matin.

Postfix est stable. Votre environnement peut ne pas l’être. La file est l’endroit où cette vérité devient visible.