Email «421 trop de connexions» : ajuster la concurrence sans retarder la livraison

Ce que signifie réellement «421 trop de connexions»

SMTP 421 est une erreur temporaire : «Service non disponible» dans le langage des RFC. En pratique, elle est utilisée comme soupape de sécurité : «Je n’accepte pas ceci pour l’instant, réessayez plus tard.» La mention «trop de connexions» indique que vous avez dépassé une limite — souvent des sessions concurrentes depuis votre IP, parfois par compte, parfois par domaine de destination, parfois selon un bucket de réputation d’IP entrante.

Deux réalités courantes cachées derrière la même erreur

• Limitation distante : Votre MTA ouvre trop de sessions SMTP simultanées vers le même fournisseur/domaine, et la partie distante renvoie des échecs temporaires 421 pour les nouvelles sessions. C’est fréquent avec les gros fournisseurs de boîtes mail, les passerelles d’entreprise et les relais sortants partagés.
• Limitation locale : Votre propre MTA (ou un relais/intermédiaire équilibrant la charge) limite les connexions — par ex. smtpd_client_connection_count_limit de Postfix en entrée, ou des services de politique qui renvoient volontairement des 421.

La conséquence opérationnelle est la même : des nouvelles tentatives. Les retries font croître la file. La croissance de la file crée davantage de pression de concurrence à moins que vous ne la maîtrisiez. C’est la boucle que vous êtes venu casser.

Une citation à garder sur un post‑it : «L’espoir n’est pas une stratégie.» — Gene Kranz. Si vous «attendez que ça se calme», vous gérez la congestion sans contrôle.

Petite blague #1 : SMTP est le seul protocole où «réessayez plus tard» est considéré comme une fonctionnalité, pas un bug.

Guide de diagnostic rapide

Quand l’alerte sonne, vous n’avez pas besoin de philosophie. Vous avez besoin de répondre à trois questions dans l’ordre :

1) Le 421 vient‑il du serveur distant ou de nous ?

Regardez la transcription SMTP dans les logs. Si Postfix indique «host mx.remote.tld said: 421 …», c’est une limitation distante. Si votre propre smtpd émet 421 aux clients, c’est une limitation locale.

2) Qu’est‑ce qui se sature : connexions, bande passante, CPU, disque ou DNS ?

Les limites de connexion sont souvent un symptôme. Le vrai goulot peut être :

• DNS lent provoquant des sessions SMTP de longue durée.
• Surcharge CPU due aux négociations TLS.
• Latence d’E/S disque causant de la contention sur les fichiers de queue.
• Limitation spécifique au fournisseur par IP/sous‑réseau.

3) Les retries amplifient‑ils le problème ?

Si votre politique de retry est trop agressive (ou la concurrence trop élevée), vous créez une tempête de retries : plus de sessions → plus de 421 → plus de file → plus de sessions. Vous voulez un flux contrôlé, pas un tuyau incendie braqué sur une porte fermée.

Actions rapides généralement sûres

• Réduire la concurrence par destination (pas globale) pour le fournisseur/domaine affecté.
• Augmenter la réutilisation des connexions (garder les sessions ouvertes et envoyer plus par session).
• Ralentir légèrement la cadence des retries pour ce destinataire afin de ne pas marteler leurs limites.
• Vérifier la latence DNS/TLS et la latence d’E/S disque pour s’assurer qu’elles ne sont pas les coupables cachés.

Faits intéressants et contexte historique (parce que les systèmes ont une mémoire)

1. SMTP précède le web : SMTP a été normalisé au début des années 1980, quand «trafic élevé» signifiait autre chose.
2. 421 est volontairement vague : C’est une classe d’échec temporaire conçue pour «revenez plus tard», pas un diagnostic précis.
3. Les échecs temporaires sont la colonne vertébrale de la fiabilité du courriel : Le modèle store‑and‑forward suppose que les réseaux échouent et que les MTAs réessaient.
4. Les limites de connexion sont devenues la norme avec le spam : Les fournisseurs ont commencé à limiter par IP parce que les spammeurs rendaient la concurrence illimitée risquée.
5. La conception de Postfix est explicitement modulaire : Plusieurs démons avec des limites de processus contrôlées, pour éviter le mode «un gros mailer» qui échoue.
6. Le greylisting a popularisé les tempfails contrôlés : Beaucoup de systèmes ont utilisé les échecs temporaires pour filtrer le spam ; les MTAs légitimes réessaient.
7. Le réglage «par destination» existe parce que l’internet est inégal : Certains domaines acceptent une forte parallélisation ; d’autres fondent avec deux connexions.
8. TLS a rendu le coût de la connexion non négligeable : SMTP‑over‑TLS ajoute du CPU et de la latence ; la réutilisation des connexions devient importante.

Modèle mental opérationnel : concurrence, sessions et files

Pensez à votre système d’envoi comme à un quai de chargement :

• La file est votre entrepôt.
• Les sessions SMTP sont des camions aux quais de chargement.
• La concurrence est le nombre de quais ouverts simultanément.
• Les limites de connexion distantes sont l’entrepôt récepteur qui dit «arrêtez d’envoyer des camions ; nous ne pouvons pas décharger autant».

Quand vous recevez «421 trop de connexions», vous envoyez plus de camions que l’autre côté n’en veut. Si vous réagissez en «ouvrant plus de quais» (augmenter la concurrence globale), vous ne ferez qu’engendrer plus de camions rejetés. Si vous réagissez en «fermаnt entièrement le quai» (throttling global), vous retarderez tout, y compris le courrier qui aurait pu être livré rapidement à d’autres domaines.

Vous voulez donc du modelage ciblé :

• Limiter la concurrence par destination (domaine, MX ou hôte relais).
• Rendre les sessions efficaces (envoyer plusieurs messages par connexion).
• Maintenir la file en bonne santé (éviter les bousculades ; prioriser le courrier récent si nécessaire).

Petite blague #2 : Le courrier électronique, c’est comme la circulation : ajouter des voies (concurrence) marche jusqu’à ce que tout le monde décide d’utiliser la même sortie (un grand fournisseur).

Tâches pratiques (commandes + ce que la sortie signifie + décision)

Ces tâches supposent Postfix sous Linux. Adaptez les chemins et noms de service si vous êtes sur une autre distribution. Chaque tâche vous donne : une commande, une sortie d’exemple, ce que cela signifie, et la décision que vous prenez.

Task 1: Confirm the exact 421 text and whether it’s remote

cr0x@server:~$ sudo grep -R "421" /var/log/mail.log | tail -n 5
Jan 04 09:12:19 mx1 postfix/smtp[19822]: 9A1C12E3F4: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=12, delays=0.1/0.2/5.3/6.4, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
Jan 04 09:12:20 mx1 postfix/smtp[19825]: 0B3E99F1A2: to=<user@example.com>, relay=mx.example.com[203.0.113.20]:25, delay=10, delays=0.1/0.2/4.5/5.2, dsn=4.3.2, status=deferred (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Signification : «host … said» indique que le serveur distant a renvoyé le 421. Votre Postfix se comporte ; vous êtes limité côté destinataire.

Décision : Concentrez‑vous sur la concurrence par destination et la réutilisation des connexions, pas sur les limites entrantes.

Task 2: Identify which destinations are causing most deferrals

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /status=deferred/{print id, $0}' | head
9A1C12E3F4 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)
0B3E99F1A2 (host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later)

Signification : Votre backlog contient du courrier différé avec 421. Ce n’est pas aléatoire ; c’est concentré.

Décision : Créez une politique de throttling pour ce domaine/fournisseur plutôt que de ralentir tous les envois.

Task 3: Count deferred reasons at scale (top N)

cr0x@server:~$ sudo postqueue -p | sed -n 's/.*status=deferred (//p' | sed 's/)$//' | sort | uniq -c | sort -nr | head
  418 host mx.example.com[203.0.113.20] said: 421 4.7.0 Too many connections, try again later
   52 connect to mx.other.tld[198.51.100.10]:25: Connection timed out
   11 host mx.third.tld[192.0.2.55] said: 450 4.2.0 Mailbox busy

Signification : Le 421 domine. Il y a aussi des timeouts, mais ce n’est pas la priorité.

Décision : Traitez le 421 en premier ; ne vous laissez pas distraire par du bruit secondaire sauf si c’est un autre incident.

Task 4: Check how many SMTP client processes you’re running

cr0x@server:~$ ps -eo pid,comm,args | grep -E "postfix/smtp" | grep -v grep | wc -l
74

Signification : Vous avez 74 processus de livraison sortante actifs. Cela peut être normal, ou problématique si 60 d’entre eux frappent un même fournisseur.

Décision : Si une destination bride, réduisez le parallélisme pour cette destination plutôt que de diminuer aveuglément le nombre global.

Task 5: See active connections to port 25/587 and who they’re going to

cr0x@server:~$ sudo ss -ntp '( dport = :25 or dport = :587 )' | head -n 15
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
ESTAB  0      0      10.0.0.10:53422     203.0.113.20:25   users:(("smtp",pid=19822,fd=12))
ESTAB  0      0      10.0.0.10:53426     203.0.113.20:25   users:(("smtp",pid=19825,fd=11))
ESTAB  0      0      10.0.0.10:53430     203.0.113.20:25   users:(("smtp",pid=19826,fd=13))

Signification : Plusieurs connexions vers la même IP suggèrent que vous déclenchez des limites par IP ou par client.

Décision : Limitez la concurrence vers ce relais/destination et augmentez le débit par connexion.

Task 6: Check Postfix per-destination concurrency defaults

cr0x@server:~$ sudo postconf | egrep "default_destination|smtp_destination|initial_destination"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = $default_destination_concurrency_limit
initial_destination_concurrency = 5

Signification : Vous pouvez atteindre 20 livraisons concurrentes par destination par défaut (selon version/config). C’est agressif pour certains fournisseurs.

Décision : Si la limite distante est plus basse (chose courante), vous avez besoin d’un plafond plus bas pour cette destination.

Task 7: Inspect transport map usage (are you already routing through a relay?)

cr0x@server:~$ sudo postconf | egrep "transport_maps|relayhost"
transport_maps =
relayhost =

Signification : Vous livrez directement aux MX destinataires. Les politiques de throttling doivent être appliquées par domaine/MX.

Décision : Envisagez les transport maps pour les destinations problématiques afin d’appliquer proprement des limites par transport.

Task 8: Check whether Postfix is reusing SMTP connections

cr0x@server:~$ sudo postconf | egrep "smtp_connection_cache|smtp_destination_recipient_limit|smtp_extra_recipient_limit"
smtp_connection_cache_destinations =
smtp_destination_recipient_limit = 50
smtp_extra_recipient_limit = 1000

Signification : La mise en cache des connexions peut être désactivée (vide). Sans cache, vous payez une nouvelle connexion par processus de livraison, augmentant la pression de concurrence.

Décision : Activez la mise en cache des connexions pour la destination ou le relais bridé afin d’envoyer plus de messages par session.

Task 9: Check retry and backoff behavior (are you retrying too aggressively?)

cr0x@server:~$ sudo postconf | egrep "minimal_backoff_time|maximal_backoff_time|queue_run_delay"
queue_run_delay = 300s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Signification : Les retries commencent à 5 minutes et montent jusqu’à ~66 minutes. Si vous avez réduit ces valeurs, vous pouvez créer une tempête de retries.

Décision : Pour une destination qui dit «trop de connexions», le backoff est votre ami. Ne mettez pas minimal_backoff à 10 secondes et n’espérez pas du respect.

Task 10: Check for DNS latency (a sneaky concurrency multiplier)

cr0x@server:~$ time dig +tries=1 +timeout=2 mx example.com @127.0.0.53
;; ANSWER SECTION:
example.com.     1800 IN MX 10 mx.example.com.

real    0m0.018s
user    0m0.004s
sys     0m0.004s

Signification : Le DNS est rapide ici. Si cela prend des centaines de millisecondes ou bloque, vos processus SMTP restent inactifs en attente, ce qui augmente le chevauchement et la concurrence perçue.

Décision : Si le DNS est lent, corrigez la performance du résolveur/caching avant de toucher aux réglages de concurrence.

Task 11: Check TLS handshake cost and failures

cr0x@server:~$ sudo grep -E "TLS|SSL" /var/log/mail.log | tail -n 5
Jan 04 09:12:18 mx1 postfix/smtp[19822]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
Jan 04 09:12:19 mx1 postfix/smtp[19825]: Trusted TLS connection established to mx.example.com[203.0.113.20]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

Signification : TLS fonctionne et est moderne. Si vous voyez des échecs répétés de handshake ou une négociation lente, les sessions durent plus longtemps et s’accumulent.

Décision : Si TLS est instable, stabilisez‑le (ciphers, SNI, chaîne de certificats, problèmes MTU) avant de supposer que «trop de connexions» est purement une limite politique.

Task 12: Check disk latency and queue directory health

cr0x@server:~$ iostat -xz 1 3
Linux 6.2.0 (mx1)  01/04/2026  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.12    0.00    1.44    0.80    0.00   94.64

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1          3.00   55.00   120.0  2400.0   6.40   1.20

Signification : Faible await et utilisation. Le disque ne s’étouffe pas. Si l’await monte à des dizaines/centaines de ms, les opérations de queue Postfix ralentissent et votre pattern de livraison devient en rafales — exactement ce qui déclenche des throttles distants.

Décision : Si le disque est le goulot, corrigez le stockage (isoler les E/S, médias plus rapides, tuning système de fichiers) avant de «tuner la concurrence».

Task 13: Check Postfix’s own rate limiting counters (anvil)

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|anvil_rate_time_unit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 0
anvil_rate_time_unit = 60s

Signification : Ce sont des contrôles entrants, mais ils comptent si vous êtes un relais pour des apps internes. Si vos applis reçoivent des 421 de votre Postfix, ces réglages sont suspects.

Décision : Si des clients internes atteignent vos limites, scalez horizontalement ou imposez du pooling côté client ; n’augmentez pas ces limites à l’infini sans vous assurer que le relais peut encaisser.

Task 14: Confirm whether the affected traffic is concentrated in one sender/app

cr0x@server:~$ sudo pflogsumm -d today /var/log/mail.log | head -n 30
Grand Totals
------------
messages
  12450   received
  12110   delivered
  310     deferred  (2.4%)
...
Per-Sender Totals
-----------------
  8200   noreply@service.local
  2400   billing@service.local

Signification : Un expéditeur domine. Si «noreply@service.local» est un expéditeur massif, ses pics peuvent noyer le courrier transactionnel.

Décision : Séparez le trafic par transport (transactionnel vs bulk), donnez la priorité au transactionnel, et bridez plus fortement le bulk.

Task 15: Verify queue size and age distribution

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

Signification : Le nombre d’éléments différés est un indicateur rapide de problème. Le vrai risque est l’âge : si le courrier reste trop longtemps, vous violez des SLA et vous créez de la confusion chez les utilisateurs.

Décision : Si le nombre différé augmente et que les âges s’allongent, vous avez besoin de throttling + priorisation maintenant, pas plus tard.

Task 16: Inspect one stuck message’s headers (routing, recipient, transport)

cr0x@server:~$ sudo postcat -q 9A1C12E3F4 | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size: 4289
recipient: user@example.com
sender: noreply@service.local
*** MESSAGE CONTENTS ***
Received: by mx1 (Postfix, from userid 1001)
Date: Sat, 04 Jan 2026 09:11:58 +0000
Subject: Your login code

Signification : Ceci montre l’expéditeur, le destinataire et des métadonnées basiques. Utile pour confirmer s’il s’agit d’un mail transactionnel qui ne doit pas être retardé.

Décision : Si c’est transactionnel, routez‑le via un transport à priorité supérieure avec une concurrence plus sûre et de meilleurs contrôles de réputation.

Ajuster Postfix correctement (sans retarder le courrier)

Principe 1 : Ne «réparez» pas un problème par destination avec un throttling global

Des changements globaux comme baisser default_destination_concurrency_limit peuvent réduire les 421, certes. Ils ralentissent aussi la livraison pour tout le monde, y compris les domaines qui étaient parfaitement contents. C’est ainsi que vous transformez la politique d’un fournisseur en panne universelle chez vous.

Principe 2 : Faire moins de connexions, mais meilleures

Les limites distantes sont souvent basées sur les connexions concurrentes. Si vous réutilisez les connexions et envoyez plusieurs destinataires/messages par session, vous réduisez le churn de connexion tout en déplaçant le volume.

Les réglages concrets qui comptent généralement

1) Limites de concurrence par destination (le levier principal)

Dans Postfix, vous pouvez plafonner la concurrence par destination. Si vous livrez directement, la «destination» est typiquement le domaine (et parfois l’hôte MX, selon la façon dont Postfix groupe les livraisons). Le schéma le plus sûr en environnement d’entreprise est d’utiliser des transport maps pour créer des «canaux» explicites pour les grands fournisseurs.

Approche exemple : router un domaine spécifique (ou un ensemble de domaines) via un transport nommé, puis appliquer des limites à ce transport dans master.cf.

cr0x@server:~$ sudo postconf -n | egrep "transport_maps"
transport_maps = hash:/etc/postfix/transport

cr0x@server:~$ sudo tee /etc/postfix/transport > /dev/null
example.com      slowmx:
example.net      slowmx:

cr0x@server:~$ sudo postmap /etc/postfix/transport

Puis dans /etc/postfix/master.cf, définissez le transport avec une concurrence plus faible. (Ceci est le modèle ; ajustez les valeurs à votre environnement.)

cr0x@server:~$ sudo postconf -M | grep -E "^slowmx"
slowmx/unix=slowmx unix - - n - - smtp

Signification : Un transport dédié vous permet de définir une concurrence et un comportement différents pour un sous‑ensemble de mails. Vous ne traitez plus toutes les destinations à égalité.

Décision : Si un fournisseur vous bride, isolez‑le dans son propre transport et ajustez‑le indépendamment.

2) Mise en cache des connexions (réutilisation)

La mise en cache des connexions garde une session SMTP ouverte pour réutilisation. Cela signifie moins de handshakes TCP, moins de handshakes TLS, moins de chances d’entrer en collision avec des politiques de «max connections».

cr0x@server:~$ sudo postconf -e "smtp_connection_cache_destinations = example.com example.net"

Signification : Postfix mettra en cache les connexions pour ces destinations quand c’est possible.

Décision : Activez la mise en cache pour les destinations bridées, surtout si votre trafic est en rafales (réinitialisations de mot de passe, notifications, factures).

3) Équilibrer le nombre de destinataires par connexion

Les fournisseurs acceptent souvent une seule session avec plusieurs livraisons mais rejettent plusieurs sessions parallèles. Faites en sorte que chaque session fasse plus de travail, raisonnablement.

cr0x@server:~$ sudo postconf -n | egrep "smtp_destination_recipient_limit"
smtp_destination_recipient_limit = 50

Signification : Jusqu’à 50 destinataires par destination par requête de livraison, selon la structure de la file et le batching. Trop élevé peut provoquer des transactions longues qui échouent en cours de session ; trop bas augmente le nombre de sessions.

Décision : Si vous atteignez des limites de connexion et que les messages sont petits, augmenter modestement le batching peut réduire les sessions. Ne montez pas à 1000 et n’ayez pas l’air surpris quand un mauvais destinataire ralentit tout le lot.

4) Rendre les retries moins stupides pour la destination bridée

Si la partie distante dit «trop de connexions», réessayer au bout de 30 secondes revient à discuter avec un pare‑feu. Façonnez vos retries pour que votre système cesse naturellement de provoquer des bousculades.

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

Signification : C’est global. Les changements globaux affectent toutes les destinations.

Décision : Préférez le contrôle par transport (queue/transport séparé) si vous avez besoin d’un comportement de retry spécifique pour un fournisseur ; gardez le retry global banal et stable.

Ce qu’il ne faut pas faire (sauf si vous aimez les incidents récurrents)

• Ne pas augmenter la concurrence globale pour «forcer le passage». Le 421 n’est pas un problème de débit ; c’est un problème de coordination.
• Ne pas désactiver TLS pour accélérer les handshakes.Vous échangerez un problème de file contre un incident de sécurité et une dégradation de réputation.
• Ne pas «réparer» en ajoutant plus de MTAs derrière le même IP NAT.Les limites distantes sont généralement par IP source. Vous ne ferez que paralléliser les rejets.

Quand la partie distante vous bride

Le throttling distant est souvent dicté par la politique. La partie distante peut plafonner :

• Les sessions concurrentes par IP d’envoi
• Les messages par minute/heure par IP ou par compte authentifié
• Les destinataires par message
• Les connexions par minute (pas seulement les connexions concurrentes)
• Le débit selon la réputation, le taux de plaintes, le taux de rebonds ou la catégorie de contenu

Comment distinguer «limite politique» de «surcharge distante»

Les limites politiques ont tendance à être cohérentes et propres : vous atteignez un plafond et l’erreur se répète de manière prévisible. La surcharge distante se corrèle souvent avec l’heure de la journée, des fenêtres de maintenance distantes, ou des augmentations sporadiques de latence/timeouts.

Recherchez ces motifs dans vos logs :

• Beaucoup de déferrals rapides avec 421 immédiatement après la connexion : limite politique classique.
• Longs délais puis 421 : le distant peut accepter puis décharger la charge ; ou votre TLS/DNS lent prolonge les sessions.
• Mélange de 421 + timeouts : peut indiquer des problèmes réseau ou une limitation distante combinée à une dégradation.

Jeu opérationnel : isoler, façonner et garder le mail transactionnel en mouvement

Dans les environnements réels, vous avez souvent deux classes de mail :

• Transactionnel : codes de connexion, MFA, reçus. Les utilisateurs remarquent en quelques secondes.
• Bulk/engagement : newsletters, relances, campagnes. Les utilisateurs remarquent… éventuellement.

Quand vous êtes bridé, la meilleure stratégie est de séparer les transports et d’appliquer des stratégies de concurrence et de retry différentes. Le transactionnel obtient la voie propre : concurrence stable, réutilisation des connexions, retry conservateur et hygiène de réputation. Le bulk est plus bridé et planifié.

Modes de défaillance qui ressemblent à de la concurrence (mais ne le sont pas)

DNS lent : l’extension silencieuse des sessions

Si les recherches DNS pour les enregistrements MX ou les vérifications rDNS sont lentes, chaque tentative de livraison prend plus de temps, ce qui augmente le nombre de tentatives qui se chevauchent. Vous n’avez pas augmenté la concurrence ; c’est le temps qui l’a fait.

Contention disque : les opérations de queue deviennent en rafales

Sur des disques surchargés, Postfix ne peut pas déplacer efficacement les fichiers de queue. Les processus de livraison sont planifiés par paquets. Les paquets créent des rafales. Les rafales déclenchent le throttling. Vous voyez 421 et vous blâmez le fournisseur, alors que votre stockage pousse des coudes.

Hypothèses de réutilisation de connexion cassées

Certaines NAT, pare‑feu ou middleboxes n’aiment pas les sessions SMTP de longue durée. S’ils resetent agressivement les connexions inactives, le caching ne fonctionne plus et vous retombez dans un comportement de «poussée de connexions».

Asymétrie IPv6 vs IPv4

Les fournisseurs peuvent appliquer des limites différentes aux plages IPv6. Si votre MTA bascule entre familles, vous pouvez observer un comportement inconsistant. Parfois la «correction» consiste à rendre le chemin cohérent, pas forcément plus rapide.

Trois mini‑récits d’entreprise du terrain

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

L’entreprise avait une architecture propre : des serveurs applicatifs soumettaient le mail à un relais interne, qui livrait directement sur Internet. Ça fonctionnait depuis des années, principalement parce que le trafic était modeste et prévisible.

Puis l’entreprise a lancé une «amélioration de sécurité» : chaque connexion nécessitait un code à usage unique par e‑mail. L’équipe a supposé que l’email se comporterait comme leurs API HTTP — scaler horizontalement, augmenter la concurrence, voir le débit monter. Ils ont fait ce que font les gens web : augmenté le nombre de workers. Plus de processus clients SMTP, plus de tentatives de livraison parallèles.

En une heure, les grands fournisseurs de boîtes mail ont commencé à renvoyer des 421 trop de connexions. La file a gonflé. Les utilisateurs ont demandé plus de codes parce qu’ils n’arrivaient pas, ce qui a généré plus de mails, ce qui a généré plus de retries. Boucle de rétroaction classique, avec en prime l’anxiété client.

L’hypothèse erronée n’était pas «les fournisseurs sont méchants». C’était de croire que SMTP est un protocole push où le récepteur n’a pas son mot à dire. La concurrence se négocie socialement, pas seulement techniquement.

La correction fut ennuyeuse : séparer les transports pour les gros fournisseurs, plafonner la concurrence par destination à un niveau sous leurs limites, et activer la mise en cache des connexions. Les codes de connexion ont commencé à arriver plus vite parce que le système a cessé de gaspiller des tentatives sur des sessions rejetées.

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

Une autre organisation voulait améliorer les métriques de livraison. Quelqu’un a noté que le courrier en file souvent restait quelques minutes, ils ont donc configuré Postfix pour exécuter la file plus fréquemment et réduit les backoffs. Les graphiques ont été beaux une semaine.

Puis ils ont accepté un nouveau client avec une passerelle mail d’entreprise stricte sur le nombre de connexions. Le MTA a commencé à recevoir des 421. Avec des backoffs réduits, le MTA a réessayé agressivement. La passerelle a interprété cela comme un comportement abusif et a encore resserré les throttles.

La livraison est passée de «parfois retardée» à «constamment retardée». Pire, les retries agressifs ont augmenté le churn de connexions, multiplié les handshakes TLS et la charge CPU, ce qui a ralenti d’autres livraisons. Le monitoring interne criait «erreurs SMTP» tandis que le produit criait «inscriptions en baisse».

L’optimisation a échoué parce qu’elle traitait les échecs temporaires comme un obstacle à écraser. Dans le monde SMTP, le backoff poli n’est pas optionnel ; c’est la façon d’éviter une auto‑attaque par déni de service.

Ils ont annulé les tweaks globaux de retry, créé un transport séparé pour le domaine du client avec une concurrence stricte (et un backoff un peu plus long), et le reste du système s’est remis immédiatement.

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

Une équipe avait pour habitude : chaque fois qu’ils ajoutaient une nouvelle source de mail, ils la taguaient avec un expéditeur d’enveloppe unique et loggaient l’identité de soumission. Pas glamour. Juste régulier. La plupart des ingénieurs trouvaient ça «processus en plus».

Pendant un incident 421, cette habitude est devenue de l’or. Ils ont rapidement déterminé que 90 % du trafic bridé venait d’un job batch récemment déployé envoyant des e‑mails de rapprochement de comptes. Il était censé tourner toutes les heures. Il tournait toutes les cinq minutes à cause d’une erreur de scheduler.

Ils n’ont pas touché Postfix au départ. Ils ont mis le job en pause, laissé la file se vider, puis réintroduit le trafic avec un transport dédié et une concurrence stricte par destination. Le mail transactionnel a eu sa voie avec mise en cache des connexions et limites stables.

Grâce à une attribution propre, ils ont évité le désastre courant : «tuner le serveur mail jusqu’à ce que le symptôme disparaisse», alors que le vrai problème continue de faire pression. La file s’est vidée, les throttles ont cessé, et personne n’a eu à expliquer à la conformité pourquoi TLS avait été désactivé par panique.

Erreurs courantes : symptômes → cause → correction

1) Symptom: «421 trop de connexions» partout

Cause : Vous avez changé la concurrence globale et maintenant plusieurs fournisseurs vous brident, ou vous êtes derrière une IP partagée avec une réputation limitée.

Correction : Revenez sur les changements globaux. Séparez les transports par groupes de destination majeurs. Si vous utilisez un smarthost, assurez‑vous de ne pas dépasser les limites par compte de celui‑ci.

2) Symptom: La file grossit, mais CPU et réseau semblent corrects

Cause : Vous êtes rapidement rejeté (déferrals 421 rapides), donc vous ne consommez pas de ressources — vous générez juste des retries.

Correction : Baissez la concurrence par destination et activez la mise en cache des connexions ; ajustez le batching pour que chaque session réussie transporte plus de mails.

3) Symptom: Pics de 421 seulement aux heures de pointe

Cause : Envois en rafales (cron, campagnes marketing) qui rencontrent des limites horaires du fournisseur.

Correction : Lissez le rythme du bulk ; planifiez les pics ; implémentez des limites par transport et priorisez le transactionnel.

4) Symptom: Vous avez réduit la concurrence et maintenant le courrier est lent pour tous les domaines

Cause : Vous avez appliqué un throttling global au lieu d’isoler la destination qui se plaignait.

Correction : Restaurez les valeurs globales. Utilisez transport maps/master.cf pour appliquer des limites strictes uniquement au domaine/fournisseur affecté.

5) Symptom: Beaucoup de connexions, peu de messages par connexion

Cause : Mise en cache des connexions désactivée, ou middleboxes qui tuent les sessions inactives ; possible aussi que la structure de la file empêche le batching.

Correction : Activez le caching pour ces destinations, vérifiez les timeouts de pare‑feu, et assurez‑vous que votre MTA peut grouper correctement les destinataires.

6) Symptom: 421 accompagné de timeouts et de «lost connection»

Cause : Problèmes de chemin réseau, MTU blackholes, ou instabilité distante ; parfois vous êtes tarpité pour cause de réputation.

Correction : Validez la santé réseau (perte de paquets, retransmissions), vérifiez la stabilité TLS, et réduisez la concurrence pendant que vous enquêtez sur les signaux de réputation.

7) Symptom: Des applis internes reçoivent des 421 en soumettant au relais

Cause : Vos propres limites de connexion entrantes (anvil) protègent le relais d’un client bruyant.

Correction : Corrigez le client (pooling, moins de soumissions parallèles), ou scalez horizontalement les relais ; augmentez les limites uniquement si vous êtes sûr que le relais peut encaisser.

Listes de vérification / plan pas à pas

Étapes : corriger le 421 sans retarder le courrier

1. Classer la source du 421. Confirmez distant vs local depuis les logs. Si distant, continuez. Si local, vérifiez les smtpd_* et les services de politique.
2. Classer les destinations par impact. Comptez les principales raisons de déferrals et identifiez quels domaines/fournisseurs dominent.
3. Protéger d’abord le mail transactionnel. Si vous mélangez bulk et transactionnel, séparez‑les maintenant. Même serveur ok ; même comportement de file non.
4. Créer un transport dédié pour les destinations bridées. Les transport maps vous donnent un levier sans dégâts collatéraux.
5. Baisser la concurrence sur ce transport. Commencez prudemment. Si le fournisseur accepte 2–5 sessions concurrents, démarrez à 2–3 et mesurez.
6. Activer la mise en cache des connexions pour cette destination/transport. Moins de sessions, plus de charge utile par session.
7. Valider la latence DNS et TLS. Les recherches lentes et les handshakes prolongés amplifient la concurrence par accident.
8. Surveiller l’âge de la file, pas seulement sa taille. Vous pouvez tolérer une file plus grande si elle se vide de façon régulière et que le courrier reste jeune.
9. Ajuster le batching prudemment. Augmentez le nombre de destinataires par session modestement si les messages sont petits et les échecs rares.
10. Vérifier que les retries se calment. L’objectif est moins de sessions rejetées et plus de livraisons réussies, pas seulement «moins de lignes de log».
11. Après stabilisation, documenter la limite. Notez le plafond de concurrence efficace qui fonctionne. Le futur vous oubliera.
12. Ajouter un monitoring des déferrals par destination. Attrapez le prochain throttling avant qu’il ne devienne une montagne de file.

Checklist opérationnelle : à surveiller en continu

• Taille et distribution d’âge de la file différée
• Principales raisons de déferral (421 vs timeouts vs 5xx)
• Connexions sortantes par IP/domaine de destination
• Taux de livraison SMTP (livrés/min) ventilé par transport
• Latence et taux d’erreur du résolveur DNS
• Latence d’E/S disque sur le filesystem du spool MTA
• Utilisation CPU et taux de handshakes TLS

FAQ

1) Le 421 est‑il un échec permanent ?

Non. C’est un échec temporaire. Votre MTA doit différer et réessayer. La question est de savoir si votre comportement de retry est contrôlé ou chaotique.

2) Pourquoi les fournisseurs limitent‑ils les connexions plutôt que les messages ?

Les connexions sont coûteuses : état TCP, handshakes TLS, et scans par session. Limiter les sessions concurrentes est une façon efficace de protéger l’infrastructure contre les rafales et les abus.

3) Dois‑je simplement baisser default_destination_concurrency_limit ?

Seulement si vous aimez ralentir le courrier vers des destinations non concernées. Utilisez le tuning par transport ou par destination afin qu’un plafond d’un fournisseur ne devienne pas votre plafond global.

4) À quel niveau la concurrence par destination doit‑elle être réglée ?

Assez bas pour arrêter les 421, assez haut pour atteindre vos objectifs de livraison. Commencez à 2–5 pour les fournisseurs stricts, puis augmentez lentement en surveillant les déferrals et l’âge de la file.

5) Activer la mise en cache des connexions aidera‑t‑il toujours ?

Souvent oui — surtout avec TLS. Mais cela peut être vaincu par des pare‑feu qui tuent les sessions inactives. Si le caching ne réduit pas les nouvelles connexions, vérifiez les timeouts des middleboxes.

6) Pourquoi baisser la concurrence a‑t‑il rendu certains e‑mails plus rapides ?

Parce que vous avez arrêté de gaspiller des tentatives. Les sessions réussies livrent du courrier ; les sessions rejetées génèrent des retries et du churn. Moins de concurrence peut signifier un débit utile plus élevé.

7) Que faire si le 421 survient quand des applis se connectent à notre relais (entrant) ?

Alors c’est votre relais qui limite les connexions clients (ou un service de politique). Examinez les réglages anvil de Postfix, le comportement client, et vérifiez si une appli ouvre des centaines de sessions SMTP parallèles.

8) Puis‑je résoudre cela en ajoutant plus de MTAs ?

Seulement si vous ajoutez aussi plus d’IP source et gérez la réputation de manière responsable. Si tout sort par une seule IP NAT, plus de MTAs donnent juste plus de connexions rejetées par seconde.

9) L’IPv6 change‑t‑il quelque chose ?

Oui. Certains fournisseurs appliquent des politiques différentes aux plages IPv6. Assurez‑vous que votre chemin sortant est cohérent et que le PTR et la réputation sont corrects pour la famille que vous utilisez.

10) Comment empêcher le bulk d’affamer le transactionnel ?

Séparez les transports (ou même les relais), appliquez des throttles stricts au bulk, et gardez le transactionnel sur une voie priorisée avec des limites prévisibles et du caching.

Conclusion : étapes pratiques suivantes

«421 trop de connexions» est du contrôle de congestion déguisé. Votre travail est d’arrêter de le traiter comme un mystère et de commencer à modeler le trafic comme un système mature.

1. Confirmez si le 421 est distant ou local grâce au libellé des logs.
2. Identifiez les principales destinations causant des déferrals.
3. Séparez le trafic : transactionnel vs bulk, et isolez les gros fournisseurs dans des transports dédiés.
4. Baissez la concurrence par destination pour le groupe bridé et activez la mise en cache des connexions.
5. Validez le DNS, TLS et les E/S disque pour ne pas amplifier la concurrence par erreur.
6. Mesurez l’âge de la file et les livraisons réussies, pas seulement l’absence d’erreurs.

Faites cela, et vous arrêterez de jouer au «whack‑a‑mole» avec les 421. Le courrier ne se contentera pas de «finir par être livré». Il sera livré à l’heure, avec moins de connexions et moins de drame — ce qui est le plus beau compliment pour un système en production.