File Postfix bloquée : procédure sûre de nettoyage (sans perte de données)

Les règles : ne « nettoyer » pas, récupérer

Quand les gens disent « nettoyer la file Postfix », ils veulent généralement dire « faire disparaître la douleur ». C’est ainsi que des mails sont supprimés, que des rebonds sont générés en masse et que votre canal d’incidents se remplit d’imprimés de l’équipe juridique.

Une file bloquée est rarement un problème de file. La file est juste le tas visible des symptômes. La cause racine est presque toujours l’une de celles-ci :

• DNS lent ou cassé (les requêtes expirent ; les livraisons s’arrêtent).
• Egress réseau bloqué (règles de pare-feu, routage, exhaustion du NAT).
• Sites distants qui limitent ou ralentissent (réponses 421/450/451, greylisting, limites de débit).
• Services de politique locaux indisponibles (milter, postscreen, rspamd, opendkim, daemon de politique).
• Pression sur le disque ou les inodes (les fichiers de la file ne peuvent pas être créés/renommés).
• Filtre de contenu lent (amavis, antivirus, DLP), causant de la contre-pression.
• Mauvaise configuration (relayhost, politiques TLS, restrictions d’expéditeur, SASL, transports incorrects).
• Corruption réelle des fichiers de la file (plus rare qu’on croit, mais réel après des problèmes de stockage).

La posture sûre est :

1. Geler la scène suffisamment pour arrêter l’aggravation.
2. Mesurer ce qui est bloqué (quelle file, quelle destination, quelle erreur).
3. Corriger la cause (DNS/réseau/service/stockage).
4. Rejouer progressivement (limiter, requeue, vidage ciblé).
5. Ce n’est qu’ensuite que vous supprimez quoi que ce soit — et seulement avec une raison écrite.

Une citation que je garde collée dans ma tête : L’espoir n’est pas une stratégie. — James Cameron. Le travail sur la fiabilité est ce que vous faites à la place de l’espoir.

Petite blague #1 : Les files Postfix sont comme les piles de linge : les ignorer ne les fait pas diminuer, ça vous rend juste créativement aveugle.

Mode d’action diagnostic rapide (premier/deuxième/troisième)

Premier : confirmez ce que « bloqué » signifie dans votre réalité

• La file active est-elle énorme (les envois sont tentés en continu) ou tout est-il dans différé (Postfix a renoncé pour l’instant) ?
• Des messages d’un seul expéditeur/domaine sont-ils bloqués, ou est-ce global ?
• De nouveaux messages entrent-ils dans la file plus vite qu’ils n’en sortent ?

Second : isolez la classe du goulot

• Latence DNS : longs timeouts de résolveur dans les logs, pics de charge système, nombreux « Host not found » qui réussissent ensuite.
• Throttling distant : beaucoup de réponses 4xx, « try again later », « rate limited », greylisting.
• Services locaux : timeouts de milter, daemon de politique qui ne répond pas, accumulation dans le filtre de contenu.
• Stockage : « No space left on device », « File too large », trop de fichiers, ou répertoires de file lents (iowait élevé).
• Réseau : timeouts de connect(), « Network is unreachable », échecs de handshake TLS dus à un MITM/proxy.

Troisième : choisissez le levier le plus sûr

• Si la cause racine n’est pas résolue, ne vidangez pas tout. Vous amplifierez la charge et rendrez les logs inutiles.
• Si une destination est « poison » (un domaine qui se met en timeout), isolez-la avec des transport maps ou des limites de concurrence.
• Si votre serveur surchauffe (charge, disque), ralentissez : réduisez la concurrence, mettez en pause le trafic non essentiel, protégez l’hôte.

Faits intéressants et historique (parce que ça explique les bizarreries)

• Postfix a été conçu comme un remplaçant de Sendmail axé sur la sécurité à la fin des années 1990, privilégiant le principe du moindre privilège et plusieurs petits daemons plutôt qu’un monolithe.
• La file est basée sur des fichiers par conception. C’est ennuyeux et excellent : les messages survivent aux redémarrages des daemons et à certaines pannes partielles.
• « Différé » n’est pas un état d’erreur ; c’est une décision d’ordonnancement. Postfix rétrograde volontairement pour éviter d’écraser une destination cassée.
• Postfix sépare les responsabilités (pickup, cleanup, qmgr, smtp, local). Quand l’un de ces composants cale, la file devient votre système d’alerte précoce.
• Les identifiants de file ne sont pas de la décoration aléatoire. Ce sont des poignées stables que vous pouvez utiliser pour tracer un message dans les logs et les opérations sur la file.
• Le comportement de backoff fait partie du bon voisinage internet. L’écosystème SMTP punit les réessauteurs agressifs par du throttling et du blocklisting.
• Historiquement, les systèmes de mail ont appris aux équipes d’exploitation la durabilité bien avant que « event sourcing » ne soit à la mode : accepter, persister, réessayer, et ne déclarer l’échec qu’avec des preuves.
• Maildir vs mbox ont enseigné des leçons douloureuses sur la corruption et le verrouillage ; le format de file de Postfix hérite de cette mentalité « ne pas miser sur un gros fichier ».

Tâches en production : commandes, sens des sorties et décision suivante

Ce ne sont pas des commandes « lancez et priez ». Chaque tâche indique quoi surveiller et quelle décision prendre ensuite. Exécutez-les en root ou avec les privilèges appropriés.

Tâche 1 : Mesurer la taille de la file (et quelle file)

cr0x@server:~$ postqueue -p | tail -n 20
-- 18451 Kbytes in 392 Requests.
A1B2C3D4E5*     1234 Fri Jan  3 10:41:22 sender@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
                                         recipient@remote.tld
...

Ce que ça signifie : Le résumé indique la taille totale et le nombre de requêtes. La ligne par message montre une erreur dominante : des timeouts de connexion vers une destination précise.

Décision : Si vous voyez une ou quelques destinations qui se répètent, faites une mitigation ciblée (throttling via transport, isolation) plutôt qu’un vidage global.

Tâche 2 : Séparer les comptes active vs différée

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

Ce que ça signifie : Principalement en différé. Postfix a essayé puis a effectué un backoff. Cela pointe généralement vers des problèmes distants, DNS, ou timeouts de politique — pas une boucle d’envoi locale.

Décision : Concentrez-vous sur pourquoi les livraisons sont différées. Ne redémarrez pas Postfix à répétition ; cela ne rendra pas les MTA distants plus réactifs.

Tâche 3 : Vérifier si Postfix est sain en tant que service

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 Fri 2026-01-03 10:12:01 UTC; 42min ago
   Main PID: 1123 (master)
      Tasks: 6 (limit: 4672)
     Memory: 34.2M
        CPU: 1min 12s

Ce que ça signifie : Le processus master tourne. Cela n’indique pas que le mail circule, mais cela écarte « il est mort ».

Décision : S’il n’est pas en cours d’exécution, démarrez-le puis inspectez immédiatement les logs pour comprendre pourquoi il s’est arrêté. S’il tourne, passez aux vérifications des goulots.

Tâche 4 : Trouver la raison dominante des diffusions dans les logs

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "deferred|timed out|refused|4[0-9][0-9]" | tail -n 20
Jan 03 10:43:10 server postfix/smtp[2451]: A1B2C3D4E5: to=, relay=mx.remote.tld[203.0.113.10]:25, delay=120, delays=0.1/0/120/0, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
Jan 03 10:43:22 server postfix/smtp[2454]: F6E7D8C9B0: to=, relay=none, delay=4, delays=0.1/0.1/3.8/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=mx.other.tld type=MX: Host not found)

Ce que ça signifie : Vous avez des timeouts de connexion (réseau/distant) et des échecs DNS (résolveur/chemin). C’est suffisant pour choisir les deux tests suivants : DNS et réseau.

Décision : Si les erreurs sont majoritairement 4.4.3 (DNS), corrigez le résolveur en premier. Si ce sont surtout des timeouts de connexion, vérifiez le pare-feu/egress et la reachabilité distante.

Tâche 5 : Vérifier la latence et la correction de la résolution DNS

cr0x@server:~$ dig +tries=1 +time=2 mx remote.tld
;; ANSWER SECTION:
remote.tld.              300     IN      MX      10 mx.remote.tld.
;; Query time: 12 msec

Ce que ça signifie : Le DNS est rapide pour ce domaine au moins. Si vous voyez 2000 msec et SERVFAIL/timeouts, c’est votre file qui est « bloquée ».

Décision : Si le DNS est lent, corrigez les résolveurs, le cache local ou le chemin réseau. Ne touchez pas encore à la file ; vous ne ferez que générer plus de requêtes ratées.

Tâche 6 : Vérifier la connectivité TCP/25 et TLS sortante

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

Ce que ça signifie : L’OS ne parvient pas à se connecter. Ce n’est pas Postfix. C’est du routage, un pare-feu, un trou noir distant ou un blocage de l’ISP sur le port 25.

Décision : Escaladez vers le réseau/pare-feu. Si le 25 sortant est bloqué par politique, vous avez besoin d’un relayhost (submission/587) ou d’un smart host approuvé.

Tâche 7 : Inspecter la concurrence Postfix et les contrôles de débit

cr0x@server:~$ postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|qmgr_message_active_limit|default_process_limit"
default_destination_concurrency_limit = 20
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20

Ce que ça signifie : Ces nombres dictent à quelle force vous tapez sur le monde. Si vous videz une grosse file différée avec une forte concurrence, vous pouvez faire un DDoS auto-infligé ou vous faire bloquer.

Décision : Pendant la récupération, baissez temporairement la concurrence (surtout par destination) si vous subissez du throttling distant.

Tâche 8 : Chercher des timeouts milter/politique (le frein invisible)

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "milter|policy|timeout" | tail -n 20
Jan 03 10:31:07 server postfix/cleanup[1881]: warning: milter inet:127.0.0.1:8891: connect to Milter service: Connection refused
Jan 03 10:31:08 server postfix/smtpd[1876]: warning: problem talking to server 127.0.0.1:8891: Connection refused

Ce que ça signifie : Postfix bloque l’acceptation ou le traitement parce qu’un milter configuré ne répond pas. Le courrier peut s’accumuler en incoming, active ou hold selon la configuration.

Décision : Réparez le service milter (démarrez-le) ou désactivez-le temporairement si la politique le permet. Ne supprimez pas le courrier en file parce que votre filtre est tombé.

Tâche 9 : Vérifier l’espace disque et les inodes (la file est des fichiers)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  600M  97% /
cr0x@server:~$ df -i /var/spool/postfix
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       1310720 1299000  11720   100% /

Ce que ça signifie : Vous êtes à court d’inodes. C’est catastrophique pour une file basée sur des fichiers : Postfix ne peut pas créer de fichiers même s’il reste quelques octets.

Décision : Libérez des inodes en sécurité (logs, caches), agrandissez le filesystem ou déplacez le spool vers un volume plus grand. Ne lancez pas de « scripts de nettoyage » supprimant au hasard des fichiers de la file.

Tâche 10 : Identifier les destinations les plus fautives dans deferred

cr0x@server:~$ postqueue -p | awk '/\(.+\)/{print}' | sed -E 's/.*\((.*)\).*/\1/' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  812 connect to mx.remote.tld[203.0.113.10]
  503 Host or domain name not found. Name service error for name=mx.other.tld type=MX
  221 451 4.7.1 Try again later

Ce que ça signifie : Quelques modes d’échec dominent. C’est une bonne nouvelle : corrigez un petit nombre de causes et la file se vide naturellement.

Décision : Si une destination domine, isolez-la pour l’empêcher de monopoliser les tentatives de livraison et le volume de logs.

Tâche 11 : Inspecter un message spécifique en sécurité

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS active ***
message_size:           1234             1234
message_arrival_time: Fri Jan  3 10:41:22 2026
sender: sender@example.com
recipient: recipient@remote.tld
*** MESSAGE CONTENTS active ***
Received: from app01.internal (app01.internal [10.0.0.12])
        by server with ESMTP id A1B2C3D4E5
        for ; Fri, 03 Jan 2026 10:41:22 +0000 (UTC)
Subject: Password reset

Ce que ça signifie : Vous pouvez vérifier expéditeur/destinataire/en-têtes sans deviner. C’est ainsi que vous évitez de supprimer du « bruit » qui est en réalité critique pour l’activité.

Décision : Si le mail est légitime, vous le conservez et corrigez la livraison. S’il s’agit de spam provenant d’un hôte compromis, coupez d’abord la source.

Tâche 12 : Mettre un message en hold plutôt que de le supprimer

cr0x@server:~$ postsuper -h A1B2C3D4E5
postsuper: A1B2C3D4E5: placed on hold

Ce que ça signifie : Le message est retiré des tentatives de livraison normales sans être détruit. C’est votre levier de « quarantaine ».

Décision : Utilisez hold pour les boucles suspectes, les messages « empoisonnés » qui font planter les filtres, ou les mails sensibles légalement pendant l’enquête.

Tâche 13 : Relâcher les mails en hold après correction de la cause

cr0x@server:~$ postsuper -H A1B2C3D4E5
postsuper: A1B2C3D4E5: released from hold

Ce que ça signifie : Le message est de nouveau éligible. Si l’erreur sous-jacente est corrigée, il sera livré lors de la prochaine tentative de la file.

Décision : Relâchez par lots si vous avez mis beaucoup d’éléments en hold. Surveillez la charge système et les réponses distantes.

Tâche 14 : Déclencher une exécution contrôlée de la file (ne pas marteler)

cr0x@server:~$ postqueue -i A1B2C3D4E5

Ce que ça signifie : Cela demande à Postfix de planifier l’ID de file spécifique pour une tentative de livraison immédiate.

Décision : Utilisez ceci pour une vérification chirurgicale (« le correctif a-t-il marché ? ») plutôt que de vider tout l’arriéré d’un coup.

Tâche 15 : Requeue des mails en sécurité (après changement de configuration)

cr0x@server:~$ postsuper -r ALL
postsuper: Requeued: 392 messages

Ce que ça signifie : Postfix réécrit les fichiers de la file dans un état neuf pour l’ordonnancement. Utile après modification des transport maps, relayhost, ou pour corriger une corruption transitoire.

Décision : Requeue est plus sûr que supprimer et renvoyer. Néanmoins, faites-le uniquement après avoir corrigé la cause et réduit la concurrence si nécessaire.

Tâche 16 : Vérifier qu’il n’y a pas de blocage du gestionnaire de file

cr0x@server:~$ ps -eo pid,comm,args | egrep "postfix/qmgr|postfix/master" | grep -v egrep
1123 master  /usr/lib/postfix/sbin/master -w
1388 qmgr    qmgr -l -t unix -u

Ce que ça signifie : qmgr existe. Si qmgr manque ou respawn constamment, la file ne se videra pas indépendamment de la reachabilité distante.

Décision : Si absent, vérifiez les erreurs de master.cf et les logs ; corrigez la configuration avant de toucher au contenu de la file.

Flux de nettoyage sûr : étape par étape (sans perte de données)

Étape 0 : Décidez ce que « sans perte de données » signifie pour votre organisation

La conservation des mails est une politique. Mais opérationnellement, « sans perte de données » signifie que vous ne supprimez pas les mails en file comme première réaction. Vous préservez les preuves, la capacité de délivrance et la possibilité d’expliquer ce qui s’est passé plus tard.

Étape 1 : Arrêtez d’aggraver la situation (sans tout arrêter)

Si la file explose parce qu’une application interne déverse des mails (boucle, bug, hôte compromis), vous devez ralentir l’entrée. Options, de la moins disruptive à la plus :

• Bloquer temporairement l’expéditeur en faute à la périphérie (restrictions smtpd).
• Limiter le débit ou appliquer du tarpitting pour un réseau client spécifique.
• Si vous êtes inondé, rejeter temporairement avec un 4xx pour les sources non essentielles afin que les expéditeurs légitimes puissent retenter.

Évitez « postfix stop » comme premier réflexe. Arrêter peut être approprié, mais cela arrête aussi les livraisons légitimes et peut déclencher des réessais applicatifs créant plus de charge ailleurs.

Étape 2 : Prendre un instantané de la situation (preuves peu coûteuses)

Avant de « réparer », capturez quelques faits rapides pour pouvoir vérifier l’amélioration et rédiger un postmortem convenable :

• Taille de la file maintenant et 15 minutes plus tard.
• Top 3 des raisons de diffusions.
• Top 3 des destinations par volume.
• État disque/inodes.
• CPU/iowait et erreurs réseau.

Ce n’est pas de la bureaucratie. C’est comment éviter de chasser des fantômes.

Étape 3 : Corrigez le goulot, pas la file

Exemples de corrections réelles qui vident réellement les files :

• Réparer le DNS : corriger resolv.conf, réparer l’upstream, ajouter un résolveur cache local.
• Ouvrir le TCP/25 sortant ou configurer un relayhost sur 587 avec authentification.
• Redémarrer/réparer les milters et filtres de contenu ; augmenter leur capacité s’ils sont le goulot.
• Corriger l’épuisement disque/inode ; déplacer le spool vers un filesystem dédié si nécessaire.
• Traiter le throttling distant en réduisant la concurrence et en respectant les 4xx.

Étape 4 : Rejouer le mail de façon contrôlée

Une fois la cause corrigée, vous voulez une vidange régulière, pas un stampede.

• Commencez par livrer quelques IDs de file connus (postqueue -i) pour confirmer le succès.
• Réduisez temporairement la concurrence par destination si vous étiez throttlé.
• Utilisez postsuper -r ALL si vous avez changé transports/relayhost et devez reprogrammer.
• Surveillez la profondeur de file et le taux de diffusions pendant la remise en charge.

Étape 5 : Supprimez des mails uniquement avec une raison limitée et traçable

Supprimer des mails en file est parfois correct. Exemples :

• Inondation de spam confirmée depuis un compte compromis qui ne doit pas être délivrée.
• Une boucle de mail prouvée qui n’aboutira jamais (expansion d’adresses incorrecte créant des destinataires infinis).
• Payload malware que vous ne devez pas relayer.

Quand vous supprimez, faites-le de manière étroite : par ID de file, par expéditeur, ou par fenêtre temporelle. Et conservez un enregistrement.

Petite blague #2 : Si quelqu’un propose « supprimez juste la file », demandez-lui quel membre ils veulent amputer pour soigner une entorse.

Où les files se bloquent : goulots par sous-système

DNS : le tueur silencieux de files

Quand le DNS est lent, Postfix n’échoue pas rapidement. Il attend, parce que parfois le DNS est instable et réessayer aide. Cela signifie que les processus smtp passent leur temps bloqués sur des résolutions au lieu de livrer. Symptômes :

• Beaucoup de diffusions avec « Name service error » ou « Host not found » qui réussissent ensuite.
• Charge élevée avec faible utilisation CPU (processus en IO wait / bloqués).
• Les requêtes dig depuis l’hôte sont lentes ou inconsistantes.

Corrigez le DNS en premier. Puis rejouez la file doucement. Une file vidée alors que le DNS est cassé crée juste une meute de timeouts.

Egress réseau : le pare-feu qui a mangé vos mails

Le blocage du TCP/25 sortant est courant en entreprise et dans le cloud. Parfois c’est intentionnel. Parfois une demande de changement a mal tourné. Postfix peut faire de la file indéfiniment, mais les utilisateurs ne se soucieront pas que c’était « prévu ».

Si vous ne pouvez pas faire de delivery direct-to-MX, utilisez un relayhost. La récupération sûre est de configurer le relayhost, tester avec un seul ID de file, puis requeue et vider.

Throttling distant et greylisting : pas cassé, juste hostile

Les MTA distants renvoient des 4xx pour tout un tas de raisons : limites de débit, réputation, contraintes temporaires, greylisting. Postfix traite cela comme transitoire et différera.

Ne « résolvez » pas le greylisting par des réessais brutaux. Respectez le backoff, réduisez la concurrence, et assurez-vous que votre IP et votre reverse DNS sont corrects. Votre file peut être un symptôme de réputation, pas un problème Postfix.

Milters et filtres de contenu : les middleboxes coûteux

Les milters sont excellents jusqu’au moment où ils ne le sont plus. Un milter tombé peut bloquer l’acceptation du mail ou ralentir le nettoyage. Un scan antivirus lent peut devenir un problème de débit global.

Opérationnellement : gardez votre chemin mail simple. Si vous devez exécuter des filtres, surveillez leur latence et leurs modes de défaillance. Traitez-les comme des dépendances, parce que c’en sont.

Stockage : la santé de la file est la santé du stockage

Postfix est une charge de stockage déguisée en messagerie. Il crée beaucoup de petits fichiers, les renomme, les fsync, et s’attend à ce que ce soit bon marché. Si votre disque est plein, à court d’inodes, ou subit des pics de latence, Postfix montrera un buildup de file.

La corruption de file est rare, mais survient après une coupure de courant abrupte, des bugs de système de fichiers, ou un stockage virtualisé défaillant. Quand ça arrive, la réponse sûre est de préserver le spool, réparer les problèmes de filesystem, et requeue — pas de faire rm -rf pour faire taire les alertes.

Trois mini-histoires d’entreprise (erreurs à apprendre)

1) L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne avait un relais mail qui « ne touchait jamais le courrier utilisateur », seulement des notifications applicatives. Cette phrase est devenue une sorte de folklore. Un matin, la file a atteint des dizaines de milliers de messages, et l’ingénieur d’astreinte a fait ce que le folklore suggérait : supprimer la file différée pour « laisser passer le nouveau mail ».

Ce qu’ils ont supposé : que le courrier en file était jetable. Ce qu’ils ont manqué : les réinitialisations de mot de passe, les avis de facturation et une part de notifications légales provenaient de ces applications. Certains destinataires étaient des régulateurs externes. Ces systèmes ne « retentent » pas éternellement — certains flux sont à usage unique liés à des actions utilisateur.

Techniquement, le vrai problème était le blocage du TCP/25 sortant après un changement de pare-feu. Postfix se comportait correctement : mettre en file et réessayer. Supprimer la file a effacé la seule copie de ces notifications. Il n’y a pas eu de réessai en amont parce que les applications avaient déjà remis le message avec succès.

La récupération a été pénible et manuelle : relancer des workflows quand possible, présenter des excuses quand ce n’était pas possible, et auditer quels types de messages avaient été perdus. La correction de la cause a pris dix minutes (restauration de la règle de pare-feu). L’impact a duré des semaines parce que « supprimer la file » n’est pas réversible.

La leçon retenue : traitez Postfix comme un tampon durable. Une fois qu’une application a remis, la file est le système d’enregistrement jusqu’à ce que la livraison réussisse ou que vous renvoyiez délibérément.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation exploitait un relais sortant chargé et voulait un débit plus élevé. Quelqu’un a augmenté les limites de concurrence — globalement et par destination — parce que la file semblait « trop lente ». Ça a marché environ un jour. Puis les fournisseurs distants ont commencé à renvoyer plus de 421/451 et le greylisting est devenu constant.

Ce qui s’est passé : leur relais a commencé à ressembler à un expéditeur agressif. Plus de connexions parallèles, plus de livraisons simultanées, et plus de tentatives répétées lors d’échecs transitoires. Certains gros fournisseurs considèrent ce schéma comme suspect ou abusif, indépendamment du contenu.

La file s’est aggravée au lieu de s’améliorer. Chaque tentative échouée créait plus de volume de logs, plus de requêtes DNS et plus de churn de sockets. Le système passait plus de temps à échouer rapidement qu’il n’en aurait passé à livrer plus lentement.

Ils ont réparé en annulant l’« optimisation », en implémentant des throttles par destination sensés, et en ajoutant de la visibilité : top raisons de diffusions, top destinations, et alertes basées sur la tendance. L’essentiel a été d’accepter que le débit SMTP est une négociation, pas une décision unilatérale.

La leçon : ne réglez pas Postfix comme un serveur web. L’email est un jeu long, et les MTA distants ont leur mot à dire.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers considérait le relais mail comme une infrastructure, pas un projet hobby. La configuration était gérée, les changements étaient revus, et — surtout — le spool résidait sur un filesystem dédié avec monitoring des inodes et de la latence.

Pendant un incident sans rapport, leur volume de logs a explosé, et une application distincte a commencé à générer massivement des fichiers temporaires sur le filesystem root. Sur beaucoup de serveurs cela aurait rempli le disque silencieusement jusqu’à ce que Postfix commence à échouer. Ici, le spool avait sa propre marge et son propre pool d’inodes.

La file a grossi, mais elle n’a pas effondré le système. Postfix a continué d’accepter le courrier, de le persister en sécurité et de réessayer les livraisons. L’astreinte a vu des alertes d’inodes pour le filesystem root mais pas pour le spool. Cela leur a donné une information critique : la durabilité du mail était intacte ; le goulot était la capacité de livraison, pas l’acceptation/persistance.

Ils ont réduit temporairement la concurrence sortante, corrigé l’application bruyante, et laissé la file se vider sur l’heure suivante. Pas de perte de mail. Pas de suppressions panique. Pas de « notifications disparues mystérieusement ».

La leçon : un filesystem de spool dédié et le monitoring des inodes est la police d’assurance la plus ennuyeuse que vous serez heureux d’avoir achetée.

Erreurs courantes : symptôme → cause racine → correction

1) « mailq affiche des milliers de messages différés »

Cause racine : Throttling distant, problèmes DNS ou blocage du réseau sortant.

Correction : Identifiez la principale raison de diffusion et la destination ; réparez DNS/réseau ; réduisez la concurrence ; requeuez et laissez vider. Ne redémarrez pas Postfix comme thérapie.

2) « La file ne se vide jamais même si le distant est joignable »

Cause racine : qmgr absent, mauvaise configuration de master.cf, ou chemin cleanup/filtre de contenu bloqué.

Correction : Vérifiez les processus qmgr/master ; inspectez les logs pour timeouts cleanup/milter ; restaurez les dépendances ; puis rejouez un message unique pour valider.

3) « Après avoir corrigé le pare-feu, rien ne s’est passé »

Cause racine : Les messages sont différés avec timers de backoff ; Postfix ne retentera pas tout instantanément.

Correction : Déclenchez des réessais contrôlés : postqueue -i pour un ID test ; puis postsuper -r ALL si nécessaire. Évitez les vidages massifs.

4) « Postfix rejette de nouveaux mails avec des erreurs temporaires »

Cause racine : Filtre de contenu/milter tombé, disque/inodes épuisés, ou trop de processus actifs.

Correction : Restaurez la dépendance, libérez inodes/espace, ou ajustez les limites de processus. Préférez les holds aux suppressions pour les éléments suspects.

5) « Fichiers de file manquants / IDs bizarres / erreurs postsuper »

Cause racine : Corruption du système de fichiers, suppression manuelle, ou couche de stockage cassée.

Correction : Résistez à l’envie d’exécuter des nettoyages aléatoires. Validez la santé du filesystem, préservez le spool, et utilisez les opérations de requeue une fois le stockage stable.

6) « Un seul domaine est bloqué ; tout le reste va bien »

Cause racine : L’MX de ce domaine est tombé, il vous limite, ou vous avez un problème de routage vers ce réseau.

Correction : Isolez les livraisons vers ce domaine (baissez la concurrence) ; ne le laissez pas dominer le gestionnaire de file. Communiquez avec le domaine destinataire si nécessaire.

7) « Les bounces explosent ; les utilisateurs reçoivent du backscatter »

Cause racine : Vous générez des rapports de non-distribution pour des expéditeurs usurpés ou vous traitez mal des échecs temporaires comme permanents.

Correction : Rejetez le mauvais mail au moment SMTP quand c’est possible ; évitez de renvoyer des bounces pour du spam accepté provenant de sources non authentifiées ; révisez les politiques autour des 4xx vs 5xx.

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

Checklist A : Première demi-heure (triage sans regrets)

1. Obtenez la taille de la file et l’erreur principale : postqueue -p, grep des logs pour « deferred ».
2. Séparez les comptes active vs différé (comptes de fichiers).
3. Vérifiez disque et inodes pour /var/spool/postfix.
4. Confirmez l’existence des processus Postfix (master/qmgr).
5. Testez la vitesse DNS avec dig pour un domaine défaillant.
6. Vérifiez la reachabilité sortante avec nc vers un MX en échec.
7. Décidez si la source d’entrée est en train d’inonder (applications internes). Si oui, limitez ou bloquez temporairement.

Checklist B : Récupération sûre (corriger + rejouer)

1. Corrigez la cause racine (DNS/réseau/filtre/stockage).
2. Testez la livraison avec un seul message : postqueue -i QUEUEID.
3. Baissez temporairement la concurrence si vous attendez du throttling.
4. Requeuez si l’ordonnancement/transport a changé : postsuper -r ALL.
5. Surveillez la profondeur de file et le taux d’erreurs dans les logs pendant 15–30 minutes.
6. Relâchez les messages en hold par lots si vous en avez mis en quarantaine.
7. Ce n’est qu’ensuite que vous envisagez de supprimer des mails réellement indésirables, de manière restreinte.

Checklist C : Quand vous devez supprimer (contrôlé, traçable)

1. Prouvez que le mail est indésirable ou dangereux (inspectez avec postcat -q).
2. Coupez la source (compte/app compromis) en premier.
3. Préférez hold plutôt que delete s’il y a une incertitude.
4. Supprimez par ID de file ou par expéditeur avec une référence de ticket d’incident.
5. Enregistrez ce que vous avez supprimé et pourquoi. Le vous du futur posera des questions.

FAQ

1) Est-ce sûr d’exécuter postsuper -d ALL ?

C’est « sûr » au même titre que formater un disque : ça fait ce que l’on demande. Ce n’est pas un workflow de récupération. Utilisez les holds, des suppressions ciblées, et corrigez la cause racine d’abord.

2) Dois-je redémarrer Postfix quand la file est bloquée ?

Redémarrer peut débloquer un processus coincé, mais cela règle rarement le DNS, les règles de pare-feu ou le throttling distant. Si vous redémarrez, faites-le une fois en documentant la raison, puis analysez immédiatement les logs.

3) Pourquoi tout est en différé même après correction du réseau ?

Les messages différés obéissent à des timers de backoff. Postfix ne réessayera pas instantanément tout. Utilisez postqueue -i pour un spot-check, et considérez postsuper -r ALL pour reprogrammer quand vous êtes confiant.

4) Quelle est la différence entre « flush » et « requeue » ?

Flush (exécution de la file) tente la livraison des mails éligibles. Requeue réécrit/réordonne les mails dans la file. Requeue est utile après des changements de configuration ; flush est ce qui se produit normalement avec le temps.

5) Comment éviter qu’un seul mauvais domaine monopolise les tentatives ?

Réduisez la concurrence par destination pour ce domaine et envisagez des transport maps pour le router différemment. L’objectif est de maintenir le flux du reste de vos mails pendant que ce domaine récupère.

6) Comment savoir si le problème de file vient du stockage local ?

Vérifiez df -h et df -i pour le spool, et cherchez des messages Postfix concernant des échecs de création/rename de fichiers. Un iowait élevé et l’épuisement d’inodes sont des signes classiques.

7) Puis-je déplacer le spool Postfix vers un autre filesystem ?

Oui, et c’est souvent une bonne idée pour la durabilité et la performance. Faites-le soigneusement : arrêtez Postfix, copiez en préservant les permissions, mettez à jour la configuration, et vérifiez l’intégrité de la file avant de démarrer.

8) Quelle est la manière la plus sûre d’inspecter le courrier en file pour contenu sensible ?

Utilisez postcat -q QUEUEID et restreignez l’accès aux répertoires du spool. Traitez l’accès au spool comme l’accès à une base de données de production : journalisé, justifié et minimal.

9) Pourquoi y a-t-il plein d’erreurs 4xx mais presque pas de 5xx ?

4xx signifie « temporaire » et déclenche des réessais. Beaucoup de fournisseurs utilisent volontairement 4xx pour contrôler le comportement des expéditeurs. Votre travail est de reculer, pas de discuter avec la physique SMTP.

Étapes suivantes (après avoir éteint l’incendie)

Une fois la file en train de se vider et que les utilisateurs cessent de vous envoyer des captures d’écran, ne vous contentez pas de partir. Faites ces actions pratiques tant que la douleur est fraîche :

1. Ajoutez le monitoring de profondeur de file et des raisons de diffusion (alertes sur tendances, pas seulement des seuils).
2. Surveillez les inodes et la latence du spool, pas seulement le pourcentage disque.
3. Documentez la règle « hold, ne pas supprimer » et exigez une raison pour les actions destructrices.
4. Fixez des valeurs de concurrence sensées et des limites par destination adaptées à votre mix de mail.
5. Rendez explicites les dépendances : milters, résolveurs DNS, relayhosts. S’ils tombent, vous devez le savoir avant que la file devienne votre tableau de bord.
6. Faites un exercice de récupération : choisissez un scénario de backlog en staging et entraînez-vous sur le workflow sûr afin que la production ne soit pas votre environnement d’apprentissage.

La file n’est pas votre ennemie. C’est votre casier à preuves et votre amortisseur de choc. Traitez-la comme telle.