Limitation SMTP : Prouvez que c’est le fournisseur et adaptez-vous proprement

novembre 21, 2025 • février 3, 2026 • Lecture : 30 min • Views: 10

Cet article vous a aidé ?

Votre équipe produit parle de « courriels lents ». Le support décrit « des clients qui ne reçoivent pas les liens de réinitialisation ».
Vous dites « la file d’attente a des dents qui poussent ». Quelque part entre votre MTA et le bord du fournisseur,
les envois SMTP commencent à renvoyer des petits codes 4xx polis et vos temps de livraison passent de secondes à heures.

La difficulté n’est pas de corriger la limitation. La difficulté est de prouver où elle se situe, pour éviter d’« optimiser » le mauvais système,
brûler votre réputation, ou déclencher une tempête de réessais qui transforme un petit incident en un examen de carrière nocturne.

À quoi ressemble réellement la limitation SMTP (dans les logs de production)

La limitation SMTP, c’est le fournisseur qui vous dit « pas maintenant ». Elle arrive généralement sous forme d’échecs transitoires (4xx),
parfois avec des codes d’état étendus (comme 4.7.0), parfois avec une prose qui ressemble à un texte juridique.
Votre MTA fait ce que font les MTA : il met en file et réessaie. Si vous ne contrôlez pas la forme des réessais, vous ne contrôlez pas l’incident.

Les signaux classiques :

421 au moment de la connexion ou après le greeting : « Service not available », souvent avec « try again later ».
451/452 pendant la transaction : « Temporary local problem » ou « insufficient system storage » (parfois faux, parfois vrai).
4.7.x statuts étendus : « message deferred », « rate limited », « temporary throttling », « too many connections ».
Différés de connexion : « connexion perdue », « timeout », « l’hôte a répondu : 421 … »
Pics par destinataire : seuls certains domaines de destination ralentissent, d’autres passent normalement.

Voici ce que beaucoup oublient : la limitation n’est pas seulement « trop de messages ». C’est aussi trop de connexions simultanées,
trop de destinataires par message, trop d’échecs, des motifs suspects, ou un problème de réputation déguisé en « capacité ».
Les fournisseurs admettent rarement quel réglage vous avez touché. Ils vous renvoient juste un 4xx et attendent que vous vous comportiez bien.

Faits intéressants et contexte historique (le courrier a toujours été ainsi)

SMTP est plus ancien que la plupart de vos outils. Il date du début des années 1980, conçu pour des réseaux coopératifs, pas pour des économies adversariales de spam.
Les déferrals 4xx sont une fonctionnalité, pas un bug. « Try again later » était destiné à lisser les pannes. Il lisse maintenant aussi l’application des politiques.
Les codes d’état étendus (lignée RFC 3463) ont été introduits car les simples 4xx/5xx étaient trop vagues pour les opérations modernes.
La greylisting a popularisé l’idée d’échec temporaire intentionnel. Certains récepteurs renvoyaient un 4xx au premier contact pour dissuader les spambots qui ne réessaient pas.
Les gros fournisseurs ont déplacé la ligne de l’adresse IP vers le comportement. Les motifs de volume, taux de plaintes, authentification et engagement influencent maintenant la limitation.
Les politiques par domaine sont devenues plus strictes à mesure que les abus entrants ont augmenté. Limiter les connexions par IP d’envoi est devenu normal quand les botnets ont appris le parallélisme.
Séparer bulk et transactionnel est devenu une pratique opérationnelle. Ce n’est pas pour la beauté — mélanger les deux empire les deux pendant les incidents de limitation.
DNS et timeouts font partie des symptômes de « limitation ». Quand un fournisseur est surchargé, on voit souvent des handshakes TLS plus lents et des délais de bannière avant un 4xx explicite.

Une citation à coller sur votre écran :

« L’espoir n’est pas une stratégie. » — Gene Kranz

Kit de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

L’objectif est simple : trouver le goulot en moins de 15 minutes. Pas « tout comprendre ».
Juste identifier si le point d’étranglement est votre hôte, votre politique MTA, votre réseau, ou le fournisseur de destination.

Premier : est-ce global ou par domaine ?

Si toutes les destinations ralentissent, suspectez des limites locales de ressources, des problèmes DNS, ou un relais en amont partagé (relay/smarthost).
Si seul un fournisseur/domaine ralentit (par ex. outlook.com ou un seul MX d’entreprise), suspectez une limitation du destinataire ou un problème de réputation/politique.

Deuxième : est-ce « impossible de se connecter » ou « impossible de livrer après connexion » ?

Délais de connexion/greeting (timeouts, 421 à la connexion) : probablement des limites de connexion, du tarpitting, ou une surcharge distante.
Déferrals RCPT/DATA (451/452/4.7.x après MAIL FROM/RCPT TO/DATA) : politique/limite de débit, réputation, déclencheurs de contenu, ou problèmes côté destinataire.

Troisième : la forme de vos réessais empire-t-elle la situation ?

Si votre file grossit et que les intervalles de réessai sont courts, vous générez peut-être une tempête de réessais qui convainc le fournisseur que vous êtes un mauvais citoyen.
Si la concurrence est élevée pour un même domaine, vous dépassez les limites de connexions par domaine.
Si vous regroupez trop de destinataires par message, un destinataire différé peut pénaliser l’ensemble de l’enveloppe.

Règle rapide : stabilisez avant d’optimiser

Réduisez la concurrence, ajoutez du backoff, préservez le courrier transactionnel, et cessez de frapper le fournisseur.
Vous pouvez restaurer les performances après avoir retrouvé un état de file stable.

Prouvez que c’est le fournisseur : preuves valables pour un post-mortem

« Le fournisseur nous limite » se dit facilement et se prouve difficilement. On vous demandera :
Est-ce notre réseau ? Notre configuration TLS ? Sommes-nous surchargés ? Sommes-nous sur une liste noire ? Envoyons-nous des déchets ?
Il vous faut des preuves qui séparent l’échec local d’une politique distante.

À quoi ressemble la preuve

Les réponses SMTP distantes montrent un langage ou des codes explicites de limitation (421/451/4.7.x) après l’établissement réussi de TCP/TLS.
Regroupement par destination : un fournisseur diffère, d’autres acceptent à un rythme normal, depuis le même hôte et la même fenêtre temporelle.
Ressources locales stables : CPU, RAM, disque, réseau corrects pendant que la file grossit — ce qui pointe loin d’une saturation locale.
Signatures de limites de connexion : « too many connections », resets fréquents pendant le greeting, ou bannière retardée uniquement pour certains MX.
Corrélation avec des changements de pattern d’envoi : déploiement, campagne marketing, pic de réinitialisations de mot de passe, ou incident provoquant des réessais.

Ce qui NE compte PAS comme preuve

« Nous n’avons rien changé. » (Vous l’avez probablement fait. Ou le fournisseur. Ou votre trafic.)
« La file est grosse. » (Les files grossissent pour des dizaines de raisons.)
« Le fournisseur est toujours capricieux. » (Vrai en esprit, inutile dans un post-mortem.)

Blague #1 : SMTP est le seul protocole qui peut poliment vous dire « revenez plus tard » tout en ruinant votre après-midi.

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

Les tâches ci‑dessous supposent un hôte Linux exécutant Postfix. Si vous utilisez Exim, Sendmail, ou un relais managé,
la philosophie reste : collecter des preuves solides, puis façonner le trafic pour ne pas combattre le récepteur.

Tâche 1 : Compter les messages différés et identifier les principales destinations

cr0x@server:~$ postqueue -p | awk '
/^[A-F0-9]/ {id=$1}
/@/ && /to=</ {for (i=1;i<=NF;i++) if ($i ~ /to=</) {addr=$i; gsub(/.*to=<|>.*/,"",addr); split(addr,a,"@"); dom=a[2]; print dom}}
/status=deferred/ {deferred=1}
' | sort | uniq -c | sort -nr | head
  913 outlook.com
  402 protection.outlook.com
  177 gmail.com
   61 yahoo.com
   44 example-corp.com

Ce que cela signifie : Les différés se regroupent par domaine de destination ; c’est votre premier discriminateur « fournisseur vs local ».
Si un domaine domine, suspectez une limitation distante ou une politique.

Décision : Appliquez des limites de concurrence/taux par domaine pour les domaines dominants et protégez les voies de mail transactionnel.

Tâche 2 : Extraire les réponses SMTP distantes pour les livraisons différées

cr0x@server:~$ sudo grep -E "status=deferred" /var/log/mail.log | tail -n 5
Jan 04 10:12:21 mx1 postfix/smtp[22119]: 3F2C41A2B: to=<user1@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.36]:25, delay=182, delays=0.2/0/12/170, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.36] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to MAIL FROM command))
Jan 04 10:12:22 mx1 postfix/smtp[22121]: 7B9DF1A31: to=<user2@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.38]:25, delay=164, delays=0.1/0/10/154, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.38] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to RCPT TO command))
Jan 04 10:12:24 mx1 postfix/smtp[22118]: 9C1C11A40: to=<user3@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0/0.2/0.9, dsn=2.0.0, status=sent (250 2.0.0 OK  1704363144 x7si123456qka.321 - gsmtp)
Jan 04 10:12:25 mx1 postfix/smtp[22125]: 1A7D21A55: to=<user4@example-corp.com>, relay=mx.example-corp.com[203.0.113.10]:25, delay=0.8, delays=0.1/0/0.2/0.5, dsn=2.0.0, status=sent (250 2.0.0 queued as 8F2A9C)
Jan 04 10:12:27 mx1 postfix/smtp[22130]: 5E0B71A66: to=<user5@outlook.com>, relay=outlook-com.olc.protection.outlook.com[104.47.56.37]:25, delay=211, delays=0.2/0/9/201, dsn=4.7.0, status=deferred (host outlook-com.olc.protection.outlook.com[104.47.56.37] said: 421 4.7.0 Temporary server error. Please try again later. (in reply to end of DATA command))

Ce que cela signifie : Vous avez des livraisons réussies vers d’autres domaines tandis qu’un fournisseur spécifique renvoie « Server busy » et des codes 4.7.x.
C’est proche d’une preuve recevable : le pair distant différencie explicitement.

Décision : Traitez cela comme une limitation fournisseur. Réduisez le parallélisme vers ce fournisseur et augmentez le backoff ; n’« accélérez » pas les réessais.

Tâche 3 : Vérifier si vous satuez les processus clients SMTP localement

cr0x@server:~$ sudo postconf -n | egrep "default_process_limit|max_use|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_connect_timeout"
default_process_limit = 200
max_use = 100
smtp_destination_concurrency_limit = 50
smtp_destination_rate_delay = 0s
smtp_connect_timeout = 30s

Ce que cela signifie : Une forte concurrence et un délai de taux nul peuvent ressembler à une inondation de connexions pour un fournisseur.
Vous pouvez déclencher des plafonds par IP ou par locataire.

Décision : Limitez la concurrence par destination et introduisez un petit délai de taux. Gardez des limites globales raisonnables.

Tâche 4 : Mesurer les connexions SMTP actives vers le fournisseur

cr0x@server:~$ sudo ss -tnp | awk '$4 ~ /:25$/ || $4 ~ /:587$/ {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  62 104.47.56.36
  59 104.47.56.38
  57 104.47.56.37
  12 142.250.102.26
   4 203.0.113.10

Ce que cela signifie : Vous maintenez beaucoup de connexions concurrentes vers le fournisseur qui limite.
Même si chaque message est petit, la seule concurrence de connexions peut déclencher la limitation.

Décision : Réduisez la concurrence par destination. Vérifiez aussi si les réponses lentes du distant font que votre client garde les sockets ouverts plus longtemps.

Tâche 5 : Vérifier les délais de greeting (tarpitting) pendant la poignée de main SMTP

cr0x@server:~$ time bash -c 'echo | nc -w 10 outlook-com.olc.protection.outlook.com 25'
220 DM6PR10CA0001.outlook.office365.com Microsoft ESMTP MAIL Service ready at Thu, 4 Jan 2026 10:13:12 +0000

real	0m6.412s
user	0m0.002s
sys	0m0.002s

Ce que cela signifie : Une bannière de 6 secondes n’est pas « une latence internet normale ». C’est soit de la charge, du tarpitting, soit un rythme délibéré.
Si ce délai n’affecte qu’un fournisseur, vous avez probablement du shaping côté distant.

Décision : Baissez la concurrence encore plus ; de longs délais de greeting multiplient votre nombre effectif de connexions et amplifient la croissance de la file.

Tâche 6 : Valider la vitesse et la correction de résolution DNS pour le MX cible

cr0x@server:~$ dig +tries=1 +time=2 MX outlook.com
;; ANSWER SECTION:
outlook.com.		1800	IN	MX	5 outlook-com.olc.protection.outlook.com.

;; Query time: 21 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Thu Jan  4 10:13:20 UTC 2026
;; MSG SIZE  rcvd: 98

Ce que cela signifie : Le DNS est rapide et sain. Si le temps de requête est de centaines/milliers de ms ou des timeouts, vous pouvez mal diagnostiquer une limitation.

Décision : Si le DNS est lent, corrigez d’abord les résolveurs. Ne réglez pas Postfix autour d’une panne DNS.

Tâche 7 : Vérifier la santé de l’hôte local ( disque et I/O ) pour ne pas accuser le fournisseur à tort

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  200G   48G  143G  26% /

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          3.20    0.00    1.10    0.30    0.00   95.40

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
nvme0n1          12.0    21.0   540.0  1120.0    0.02   0.7    2.1

Ce que cela signifie : Beaucoup d’espace ; pas d’étranglement I/O. La croissance de la file n’est pas due à un spool lent ou plein.

Décision : Continuez à chercher en amont. Si le disque est plein ou l’I/O saturée, réglez cela d’abord — le courrier est très sensible au comportement d’fsync.

Tâche 8 : Vérifier si le gestionnaire de file est submergé

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3F2C41A2B      5120 Thu Jan  4 09:58:11  noreply@service.example
                                         user1@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.56.36] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to MAIL FROM command))

7B9DF1A31      4891 Thu Jan  4 10:01:03  noreply@service.example
                                         user2@outlook.com
                                         (host outlook-com.olc.protection.outlook.com[104.47.56.38] said: 451 4.7.500 Server busy. Please try again later. (S3150) (in reply to RCPT TO command))

Ce que cela signifie : Les différés sont annotés avec les réponses distantes. Vous pouvez montrer cela à quiconque.

Décision : Si le même différé se répète pour un domaine, arrêtez de marteler. Réglez les limites par domaine et les intervalles de réessai.

Tâche 9 : Confirmer que vous n’êtes pas bloqué derrière un smarthost ou un relais limitant

cr0x@server:~$ sudo postconf -n | egrep "^relayhost|^smtp_sasl_auth_enable|^smtp_tls_security_level"
relayhost =
smtp_sasl_auth_enable = no
smtp_tls_security_level = dane

Ce que cela signifie : Aucun relayhost configuré ; vous livrez directement aux MX. Bien : l’analyse de limitation par domaine est pertinente.
Si relayhost est défini, votre goulot peut être votre fournisseur relais, pas le domaine de destination.

Décision : Si vous utilisez un relayhost, déplacez le diagnostic à la frontière du relais : leurs réponses, vos limites d’auth, leurs quotas.

Tâche 10 : Tracer une tentative de livraison unique bout en bout avec un journal SMTP verbeux

cr0x@server:~$ sudo postconf -e "debug_peer_list = outlook-com.olc.protection.outlook.com"
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo grep -E "outlook-com\.olc\.protection\.outlook\.com|postfix/smtp" /var/log/mail.log | tail -n 20
Jan 04 10:14:10 mx1 postfix/smtp[22301]: connect to outlook-com.olc.protection.outlook.com[104.47.56.36]:25: Connected
Jan 04 10:14:16 mx1 postfix/smtp[22301]: << 220 DM6PR10CA0001.outlook.office365.com Microsoft ESMTP MAIL Service ready
Jan 04 10:14:16 mx1 postfix/smtp[22301]: >> EHLO mx1.service.example
Jan 04 10:14:17 mx1 postfix/smtp[22301]: << 250-DM6PR10CA0001.outlook.office365.com Hello [198.51.100.10]
Jan 04 10:14:17 mx1 postfix/smtp[22301]: >> MAIL FROM:<noreply@service.example>
Jan 04 10:14:17 mx1 postfix/smtp[22301]: << 451 4.7.500 Server busy. Please try again later. (S3150)

Ce que cela signifie : La connexion TCP a réussi. La bannière est arrivée. EHLO a fonctionné. Le fournisseur a différé au MAIL FROM.
Ce n’est pas votre pare-feu. Ce n’est pas votre DNS. C’est le récepteur qui dit « ralentissez ».

Décision : Mettez en place un pacing par domaine et un backoff plus long ; conservez les logs pour une escalation auprès du fournisseur.

Tâche 11 : Vérifier la posture d’authentification (SPF/DKIM/DMARC) depuis votre domaine d’envoi

cr0x@server:~$ dig +short TXT service.example
"v=spf1 ip4:198.51.100.10 -all"
"google-site-verification=..."

cr0x@server:~$ dig +short TXT selector1._domainkey.service.example
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

cr0x@server:~$ dig +short TXT _dmarc.service.example
"v=DMARC1; p=quarantine; rua=mailto:dmarc@service.example"

Ce que cela signifie : Une authentification manquante ou bâclée n’engendre pas toujours des hard-bounces ; elle peut augmenter la pression de filtrage et la limitation.
Les fournisseurs peuvent accepter plus lentement pendant qu’ils décident si vous êtes digne de confiance.

Décision : Si l’auth est manquante/cassée, corrigez-la avant de négocier des « limites de débit ». On ne règle pas la méfiance par configuration.

Tâche 12 : Inspecter les déclencheurs de composition du message (taille, nombre de destinataires, batch)

cr0x@server:~$ sudo postcat -q 3F2C41A2B | egrep -i "^(message_size|recipient_count|sender|original_recipient|message_arrival_time)"
message_size:            5120
recipient_count:         15
sender:                  noreply@service.example
message_arrival_time:    Thu Jan  4 09:58:11 2026

Ce que cela signifie : Un seul élément en file a 15 destinataires. Certains fournisseurs pénalisent un large fanout de destinataires,
et un destinataire différé peut retarder la livraison de toute l’enveloppe (selon la façon dont votre application regroupe).

Décision : Si vous batchiez fortement les destinataires, réduisez le nombre par message pour les domaines limités. Plus d’entrées dans la file, moins de blocages multi-destinataires.

Tâche 13 : Vérifier si la négociation TLS bloque ou échoue (souvent confondu avec une limitation)

cr0x@server:~$ openssl s_client -starttls smtp -connect outlook-com.olc.protection.outlook.com:25 -servername outlook-com.olc.protection.outlook.com -brief </dev/null
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=*.protection.outlook.com
Verification: OK

Ce que cela signifie : TLS est OK. Si cela échoue ou bloque, vous pourriez avoir des middleboxes, des problèmes de MTU, ou une charge TLS côté fournisseur.

Décision : Si TLS est l’étranglement, ajustez les timeouts et investiguez le chemin réseau. Ne vous contentez pas de réduire le taux et prétendre que c’est résolu.

Tâche 14 : Confirmer que votre pare-feu/NAT ne droppe pas les connexions sortantes sous charge

cr0x@server:~$ sudo conntrack -S | head
entries  32768
searched 154832
found    98211
new      2211
invalid  0
ignore   0
delete   2179
delete_list 2179

Ce que cela signifie : Si invalid est élevé, ou si la table conntrack est presque pleine, vous verrez des timeouts et des resets SMTP aléatoires
qui ressemblent à de la limitation. Le fournisseur est accusé ; votre boîtier NAT brûle en silence.

Décision : Si conntrack est saturé, réduisez le churn de connexions sortantes (baisser la concurrence, augmenter la réutilisation) et augmentez la capacité conntrack si approprié.

Adaptez proprement : limites de débit, backoff, concurrence et hygiène de file

Une fois que vous êtes sûr que la limitation est en amont, vous avez deux objectifs :
livrer ce que vous pouvez sans énerver davantage le fournisseur, et garder vos propres systèmes stables pendant que l’arriéré s’écoule.
C’est de la rétropression, pas un sprint.

Principe 1 : Séparer les classes de courriel (le transactionnel a la priorité)

Si vous mélangez réinitialisations de mot de passe et newsletters dans la même file, vous méritez l’incident à venir.
Le mail transactionnel a un utilisateur qui attend. Le bulk a un calendrier marketing.
Ce ne sont pas des choses équivalentes aux yeux de votre incident commander.

Faites-le au niveau applicatif (flux séparés) ou au MTA (transports séparés), mais faites-le.
Dans Postfix, cela signifie typiquement des routes transport_maps dédiées et des réglages de concurrence différents.

Principe 2 : Les limites par domaine battent les limites globales

Les throttles globaux sont des instruments grossiers : ils vous protègent, mais punissent les domaines qui accepteraient normalement rapidement.
Les fournisseurs limitent par IP d’envoi, par locataire, par expéditeur, par destination, et via des heuristiques comportementales.
Votre meilleur ajustement est la concurrence et le pacing par domaine.

Principe 3 : Le backoff doit être exponentiel-ish, avec jitter, et assez long pour avoir de l’effet

Les MTA réessaient déjà, mais les valeurs par défaut peuvent être inadaptées pour la limitation moderne. Si vous réessayez trop vite, vous ressemblez à un botnet.
Si vous réessayez trop lentement, le mail transactionnel perd sa fenêtre d’utilité.
L’astuce est d’appliquer un comportement de réessai différent selon les classes et les destinations.

Patrons concrets de tuning Postfix

Vous pouvez faire cela proprement sans transformer votre MTA en snowflake surajusté.
Commencez par la concurrence par domaine et un petit délai de taux.

cr0x@server:~$ sudo postconf -e "smtp_destination_concurrency_limit = 10"
cr0x@server:~$ sudo postconf -e "smtp_destination_rate_delay = 1s"
cr0x@server:~$ sudo postconf -e "default_destination_concurrency_limit = 20"
cr0x@server:~$ sudo systemctl reload postfix

Ce que cela signifie : Vous plafonnez les livraisons concurrentes par destination et ajoutez un espacement minimum entre livraisons.
Cela réduit les inondations de connexions et lisse le trafic.

Décision : Si le fournisseur renvoie explicitement « too many connections » ou « server busy », c’est votre premier levier.

Pour des destinations particulièrement sensibles, définissez un transport dédié avec des limites plus strictes.

cr0x@server:~$ sudo tee -a /etc/postfix/master.cf >/dev/null <<'EOF'
slowoutlook unix  -       -       n       -       -       smtp
  -o smtp_destination_concurrency_limit=2
  -o smtp_destination_rate_delay=3s
  -o smtp_connect_timeout=20s
EOF
cr0x@server:~$ sudo tee /etc/postfix/transport >/dev/null <<'EOF'
outlook.com slowoutlook:
protection.outlook.com slowoutlook:
EOF
cr0x@server:~$ sudo postmap /etc/postfix/transport
cr0x@server:~$ sudo postconf -e "transport_maps = hash:/etc/postfix/transport"
cr0x@server:~$ sudo systemctl reload postfix

Ce que cela signifie : Seuls les mails vers ces domaines utilisent le transport ralenti ; les autres domaines conservent un débit normal.

Décision : Utilisez des transports dédiés quand un fournisseur pose problème et que vous ne voulez pas ralentir globalement.

Contrôle des réessais : ne laissez pas « deferred » devenir « DDoS en meilleure grammaire »

Le timing des réessais Postfix est contrôlé par des paramètres du gestionnaire de file. Vous pouvez les ajuster, mais faites-le prudemment :
régler les réessais affecte tous les messages, y compris ceux qui auraient réussi rapidement.
Privilégiez d’abord le pacing et la concurrence par domaine.

cr0x@server:~$ sudo postconf -n | egrep "minimal_backoff_time|maximal_backoff_time|maximal_queue_lifetime"
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d

Ce que cela signifie : Votre MTA n’attaquera pas toutes les minutes ; il recule jusque vers une heure environ entre tentatives.
Si votre backoff minimal est trop petit, vous pouvez auto-amplifier la limitation.

Décision : Si vous voyez des déferrals répétés rapidement, augmentez modestement minimal_backoff_time, mais ne cassez pas la latence transactionnelle pour tous les domaines.

Hygiène de file : protéger le système contre la file

Une file qui grossit n’est pas juste des « messages en attente ». C’est de l’utilisation disque, de la pression sur les inodes, et du CPU passé à scanner les files.
Votre objectif est de garder le MTA réactif même quand il est retardé.

Placez /var/spool/postfix sur un stockage rapide et surveillez l’utilisation des inodes.
Évitez les énormes rafales d’une seule file en contrôlant le débit d’envoi côté application en amont.
Privilégiez moins de clients SMTP simultanés vers un fournisseur plutôt que d’ouvrir constamment de nouvelles connexions.

Blague #2 : Si vous fixez mail.log assez longtemps, il finit par vous fixer aussi — et il veut toujours plus de disque.

Trois mini-histoires d’entreprise tirées des mines du courriel

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

Une société SaaS de taille moyenne gérait son propre Postfix pour le mail transactionnel. Ils ont ajouté une nouvelle région et ont commencé à envoyer depuis un bloc d’IP neuf.
Le déploiement s’est bien passé pendant une semaine, puis les réinitialisations de mot de passe ont commencé à arriver avec 30–90 minutes de retard pour des utilisateurs d’un grand fournisseur.
L’on-call ingénieur a vu une grosse file et a supposé que l’hôte Postfix manquait de ressources. Ils ont doublé le CPU et ajouté de la mémoire.

La file a continué de grandir. Ils ont encore augmenté l’instance. Toujours en croissance. Ils ont ajusté les limites de descripteurs de fichiers, puis redémarré Postfix pendant le pic,
ce qui n’a rien amélioré et a définitivement ruiné la confiance de tous. Pendant ce temps, les livraisons Gmail restaient presque instantanées,
ce qui aurait dû être un indice mais a été ignoré parce que « la file est grosse ».

Le vrai problème était dans les logs : des 451 4.7.500 Server busy répétés sur MAIL FROM, uniquement pour les MX de ce fournisseur.
Ils déclenchaient des limites de connexion parce que l’application était passée d’un envoi par événement à du batching
et lançait plusieurs workers parallèles par client. Plus d’événements signifiaient plus de clients SMTP simultanés.

Une fois qu’ils ont limité la concurrence par domaine à 2 et ajouté un délai de taux, l’arriéré s’est résorbé en quelques heures.
Le post-mortem a une ligne sans pitié : « Nous avons mis à l’échelle la mauvaise chose parce que nous n’avons pas segmenté par domaine de destination. »
La leçon n’était pas « achetez des serveurs plus gros ». La leçon : prouvez où est le goulot avant de toucher le matériel.

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

Une grande entreprise voulait réduire le coût des handshakes SMTP. Quelqu’un a proposé « maximiser la réutilisation de connexion » et « augmenter la concurrence »
pour obtenir un meilleur débit vers les destinataires externes. Sur le papier, c’était excellent : moins de handshakes TLS par message, plus de livraisons en parallèle,
files plus courtes. Le changement a été déployé progressivement. Les métriques se sont améliorées. On s’est félicité.

Puis une campagne marketing a croisé un incident non lié qui a causé un pic de réinitialisations de mot de passe.
Le MTA a fait exactement ce pour quoi il avait été optimisé : il a ouvert et maintenu beaucoup de sessions concurrentes vers une poignée de gros fournisseurs.
Ces fournisseurs ont interprété le comportement comme agressif et ont commencé à tarpitter pendant le greeting
et à différer au RCPT et DATA avec des codes 4.7.x.

L’« optimisation » a créé une boucle de rétroaction néfaste. De longs délais de greeting ont signifié que les connexions étaient gardées plus longtemps.
Les connexions gardées signifiaient moins de créneaux disponibles. Moins de créneaux signifiaient que les messages restaient en file plus longtemps.
Les messages en file ont été réessayés. Les réessais ont ouvert plus de connexions. Vous voyez l’idée.
La file a eu un comportement non linéaire. Pas parce que le serveur était lent, mais parce que le distant l’avait ralenti et que le MTA ne s’est pas adapté.

La correction n’a pas été de revenir sur tous les réglages. C’était d’ajouter des contrôles par domaine et une politique :
le bulk et le transactionnel ne doivent pas partager la même classe de concurrence, et aucun fournisseur ne doit avoir un parallélisme illimité.
Ils ont aussi ajouté un « kill switch campagne » côté application. C’est la partie peu sexy :
parfois le meilleur réglage SMTP est un bouton qui arrête votre propre trafic.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une organisation avec une gestion stricte des changements faisait transiter le courrier sortant par une couche de relais dédiée.
Les relais n’étaient pas puissants. Ils n’étaient pas sophistiqués. Mais ils étaient instrumentés :
compteurs de déferrals par domaine, tableaux de bord de profondeur de file, et échantillonnage de logs faisaient partie du build standard.
Chaque classe de domaine avait une limite de concurrence documentée et une justification.

Un après-midi, un grand fournisseur a commencé à renvoyer des échecs transitoires et des bannières lentes. La file a commencé à augmenter.
L’on-call a suivi le runbook : confirmer le regroupement par domaine, confirmer les déferrals 4.7.x distants, confirmer la stabilité des ressources locales.
Le tableau de bord montrait que seul ce fournisseur avait des déferrals en hausse ; les autres domaines allaient bien.

Ils ont basculé le transport pour le fournisseur vers des réglages « voie lente » déjà présents en gestion de configuration.
La concurrence est tombée. Le délai de taux a augmenté. La croissance de la file s’est stabilisée en quelques minutes.
Le mail transactionnel vers d’autres fournisseurs a continué normalement, et l’arriéré s’est évacué une fois que le fournisseur a récupéré.

Pas d’héroïsme. Pas de changements aléatoires. Pas de redémarrages paniqués. La pratique ennuyeuse était simplement :
pré-définir le comportement de limitation par destination, et livrer l’observabilité avec le MTA.
C’est comme ça qu’on dort.

Erreurs courantes : symptôme → cause racine → correction

Voici les modes d’échec qui reviennent parce que les humains aiment les histoires simples.
SMTP ne récompense pas les histoires simples.

1) Symptom : « Le mail est retardé pour tout le monde » (mais en réalité seul un fournisseur est différé)

Cause racine : Vous appliquez une limitation globale ou le gestionnaire de file consacre la plupart des cycles à un seul domaine limité.

Correction : Implémentez des transports par domaine ou des limites de concurrence par domaine. Gardez les domaines rapides rapides.

2) Symptom : Beaucoup de timeouts et d’erreurs « lost connection »

Cause racine : Soit du tarpitting/délais de greeting distant, soit une exhaustion locale de conntrack/NAT sous le churn de connexions.

Correction : Mesurez les temps de greeting, vérifiez les stats conntrack, et réduisez la concurrence de connexion. Favorisez des sessions plus stables et moins nombreuses.

3) Symptom : Vous voyez 451/4.7.x et quelqu’un suggère « réessayez plus vite »

Cause racine : Mauvaise compréhension des déferrals. Des réessais plus rapides peuvent augmenter la limitation et prolonger le temps de récupération.

Correction : Backoff avec jitter. Baissez la concurrence par domaine. Stabilisez d’abord ; laissez l’arriéré s’évacuer ensuite.

4) Symptom : Seuls les gros messages sont retardés ou différés

Cause racine : Limites de taille côté fournisseur, charge de scan de contenu, ou votre propre réseau/chemin TLS qui souffre lors de transferts plus lourds.

Correction : Confirmez les réponses distantes (elles mentionnent souvent la taille), réduisez les pièces jointes, et envisagez des canaux alternatifs pour le contenu lourd.

5) Symptom : Gmail va bien, Microsoft est lent (ou vice versa)

Cause racine : Politiques différentes selon les fournisseurs, modèles de réputation différents, limites de connexion différentes.

Correction : Ajustez par fournisseur. Ne généralisez pas le comportement d’un domaine à « SMTP » dans son ensemble.

6) Symptom : La file grossit après un déploiement, mais les logs montrent « server busy » du fournisseur

Cause racine : Le déploiement a changé le pattern d’envoi (burstiness, parallélisme, batching) plus que le volume brut.

Correction : Ajoutez un rate limiting en amont côté application ; lissez les rafales. Gardez les contrôles MTA comme seconde ligne de défense.

7) Symptom : Les fournisseurs différent au MAIL FROM et vous suspectez un bug dans votre MTA

Cause racine : Décision de politique chez le récepteur basée sur l’identité de l’expéditeur/la réputation IP ; MAIL FROM est un point d’étranglement pratique en début de transaction.

Correction : Améliorez l’authentification (SPF/DKIM/DMARC), réduisez les pics, et si nécessaire, « warm up » les IP plutôt que de « frapper fort le premier jour ».

Listes de contrôle / plan pas à pas

Pas à pas : Diagnostiquer et stabiliser en une rotation d’on-call

Segmenter le problème par destination : identifier les principaux domaines différés depuis la file.
Lire les réponses distantes : capturer 10–20 lignes représentatives de déferrals avec horodatage et IP distantes.
Confirmer la santé locale : espace disque, iowait, pression mémoire, conntrack, descripteurs de fichiers.
Mesurer le comportement de poignée de main : délai de bannière et résultats STARTTLS pour le fournisseur différé.
Brider la concurrence par domaine : commencer prudemment (2–5) pour le fournisseur limitant.
Ajouter un délai de taux par domaine : quelques secondes comptent ; commencer par 1–3 secondes pour un fournisseur problématique.
Protéger le mail transactionnel : scinder transports ou files ; prioriser réinitialisations/OTP sur le bulk.
Réduire la rafale en amont : si l’application peut mettre en pause le bulk, mettez-la en pause ; si elle peut ralentir, ralentissez.
Surveiller la pente de la file : stabilisation signifie « la file cesse de croître », pas « la file est vide ».
Conserver les preuves : extraits de logs, codes de déferral, et séries temporelles. Vous en aurez besoin pour l’escalade fournisseur et la responsabilité interne.

Checklist : paquet de preuves pour « c’est le fournisseur »

Compte des principaux domaines différés (issu du parsing de la file).
Au moins 5 lignes de log montrant dsn=4.7.x ou 421/451 avec le texte SMTP du fournisseur.
Une trace SMTP verbeuse montrant connect+EHLO réussi suivie d’un différé (Tâche 10).
Données de timing de la poignée de main (délai de bannière) pour ce fournisseur vs au moins un autre fournisseur.
Snapshot des ressources locales montrant l’absence de saturation : disque, iostat, charge, conntrack.

Checklist : adaptation propre (sans créer un monstre)

Transport par domaine pour les fournisseurs connus pour limiter.
Valeurs par défaut prudentes pour smtp_destination_concurrency_limit et smtp_destination_rate_delay.
Séparation des flux bulk/transactionnel.
Paramètres de backoff raisonnables ; pas de boucles de réessai rapides.
Dashboards : profondeur de file, taux de différés par domaine, percentiles de latence de livraison.
Bouton d’arrêt pour le bulk au niveau applicatif.

FAQ

1) Les erreurs 4xx signifient-elles toujours limitation ?

Non. 4xx signifie « échec temporaire », ce qui peut inclure limitation, greylisting, maintenance distante, ou problèmes de routage transitoires.
La limitation est probable quand les 4xx se regroupent par destination et incluent un langage 4.7.x comme « rate limited », « server busy », ou « too many connections ».

2) Comment distinguer une limitation fournisseur d’un problème réseau local ?

Si la connexion TCP et l’EHLO réussissent et que le récepteur répond 451/421/4.7.x, c’est fortement côté fournisseur.
Si vous ne pouvez pas vous connecter, voyez beaucoup de timeouts sur plusieurs domaines, ou que conntrack est saturé, vous avez une douleur réseau locale.

3) Pourquoi la limitation apparaît-elle parfois comme des greetings lents plutôt que des 4xx explicites ?

Le tarpitting est une tactique : retarder la bannière ou les réponses pour réduire votre débit sans consommer leur budget de politique sur des rejets explicites.
De votre côté, cela ressemble à « SMTP est lent ». Mesurez le temps de bannière pour confirmer.

4) Dois-je augmenter la concurrence Postfix pour vider la file plus vite ?

Pas quand le récepteur vous différencie. Une plus grande concurrence augmente généralement le taux de déferrals, maintient plus de sockets ouverts,
et ralentit la récupération. Quand vous êtes limité, on évacue en étant ennuyeux et constant, pas en étant bruyant.

5) Mieux vaut-il envoyer directement aux MX ou via un service relais ?

Direct-to-MX vous donne du contrôle et une visibilité immédiate sur les réponses des récepteurs. Un relais peut offrir une meilleure gestion de réputation IP,
mais devient aussi un point de goulot supplémentaire avec ses propres quotas et politiques. Choisissez-en un, instrumentez-le, et sachez où se situe la frontière.

6) Un SPF/DKIM/DMARC cassé peut-il provoquer une limitation plutôt que des bounces ?

Oui. Certains fournisseurs dégradent le comportement d’acceptation : plus de déferrals, acceptation plus lente, ou filtrage plus lourd quand l’authentification est manquante ou incohérente.
Vous n’aurez peut‑être pas un message clair « auth failed » ; vous aurez « server busy » et une journée plus longue.

7) Comment garder les réinitialisations de mot de passe rapides pendant un événement de limitation ?

Séparez le mail transactionnel dans son propre flux et transport, et plafonnez agressivement le trafic bulk.
Envisagez d’envoyer le transactionnel depuis une identité chauffée et stable (domaine/sous-domaine/IP) distincte du marketing.

8) Quelle est la façon la plus propre de s’adapter sans accumuler des hacks permanents ?

Utilisez de petits blocs de config explicites : transports par domaine avec limites documentées, plus des tableaux de bord et un runbook.
Évitez les réglages globaux aléatoires. Privilégiez des changements réversibles avec des propriétaires clairs et un impact mesuré.

9) Quand dois-je escalader vers le fournisseur ?

Escaladez lorsque vous avez un paquet de preuves : réponses SMTP représentatives, horodatages, IP d’envoi, et preuve que d’autres domaines fonctionnent.
Les fournisseurs répondent mieux à des données structurées qu’à « nos emails sont lents ».

10) Puis-je « prouver » la limitation si le fournisseur ne renvoie jamais de 4xx mais seulement des timeouts ?

Vous pouvez constituer un dossier solide : montrez que la connexion réussit mais que la bannière/les commandes se bloquent uniquement pour ce fournisseur,
et que le même hôte livre normalement à d’autres. Ce n’est pas aussi propre qu’un 451, mais c’est une preuve exploitable.

Conclusion : étapes pratiques suivantes

La limitation SMTP est normale. La nier, c’est finir avec une file si grande qu’elle devient un événement business.
Votre travail est de prouver où vit le délai, puis de façonner le trafic pour que le fournisseur puisse l’accepter et que vos utilisateurs n’attendent pas indéfiniment.

Tout de suite : segmentez les différés par domaine de destination, capturez les réponses distantes, et confirmez la santé locale.
Dans l’heure : bridez la concurrence par domaine et ajoutez un délai de taux par domaine pour le fournisseur limitant.
Avant le prochain incident : séparez les flux transactionnel et bulk, ajoutez des tableaux de bord pour le taux de différés par domaine, et implémentez un kill switch.
Pour le post-mortem : conservez le paquet de preuves. Il empêche le « on pense » de devenir du « on a deviné ».