SMTP « 421 Too many connections » ou limite de débit : comment le corriger

Ce que ça veut dire

Une réponse 421 signifie « pas maintenant, réessayez plus tard ». Le serveur destinataire ferme la connexion parce que vous en avez ouvert trop en même temps, ou que vous envoyez trop vite. C'est une erreur temporaire : un serveur mail normal garde le message et réessaie. Sur les serveurs Postfix, le message ressemble généralement à ceci :

421 4.7.0 mx.example.com Error: too many connections from 203.0.113.10

D'autres serveurs le formulent autrement (« Too many concurrent SMTP connections », « Try again later, closing connection », « rate limited »). Un message Postfix voisin est 450 4.7.1 Error: too much mail from 203.0.113.10 (limite du nombre de messages).

Certains grands fournisseurs ont leurs propres codes, avec leurs propres guides : Gmail 421 4.7.28 et Microsoft 451 4.7.500 ; Yahoo a ses propres codes TSS.

Pourquoi cela arrive

• Trop de connexions en parallèle. Votre application ou votre serveur ouvre beaucoup de connexions à la fois (une newsletter ou un script qui envoie chaque email dans sa propre connexion).
• Trop de messages par minute depuis une même IP ou un même compte.
• Réputation faible ou nouvelle. Les destinataires acceptent moins d'emails des IP qu'ils ne connaissent pas : un volume sans problème pour une IP ancienne déclenche des limites sur une IP nouvelle.
• IP partagée. D'autres clients sur la même IP consomment une partie du quota.
• Les limites de votre propre serveur, si c'est votre serveur qui répond 421 à vos applications ou à un partenaire.
• Limites du compte d'envoi. Les fournisseurs de messagerie limitent les sessions SMTP et les messages par compte ; un 421 ou un 4.7.0 pendant un gros envoi depuis une boîte normale est fréquent.

Comment vérifier

1. Identifiez qui répond. Le nom d'hôte dans la ligne 421 vous indique s'il s'agit du serveur du destinataire, du relais de votre fournisseur ou de votre propre serveur.
2. Sur votre Postfix d'envoi, regardez les messages différés :

   postqueue -p | grep -i "too many" | sort | uniq -c
   grep "421" /var/log/mail.log | tail

3. Sur votre Postfix de réception, le service anvil journalise les pics :

   grep "anvil" /var/log/mail.log | tail
   postconf smtpd_client_connection_count_limit smtpd_client_connection_rate_limit smtpd_client_message_rate_limit anvil_rate_time_unit

4. Vérifiez la réputation : cherchez votre IP d'envoi sur les listes noires et envoyez un test à l'adresse unique affichée sur la page d'accueil de Delivmail. Un rapport propre signifie que la limite concerne le volume, pas un blocage.

Comment corriger

Si vous êtes l'expéditeur : envoyez plus lentement

Dans une application avec nodemailer, réutilisez quelques connexions au lieu d'en ouvrir une par message :

const transporter = nodemailer.createTransport({
  host: 'smtp.example.com',
  port: 587,
  pool: true,          // reuse connections
  maxConnections: 2,   // parallel connections
  maxMessages: 100,    // messages per connection
  rateDelta: 1000,     // time window in ms
  rateLimit: 5,        // messages per window
  auth: { user: 'you@yourdomain.com', pass: process.env.SMTP_PASS }
});

Avec Postfix, ralentissez uniquement la destination qui se plaint, grâce à un transport dédié. Dans master.cf :

slow      unix  -       -       n       -       2       smtp

Dans main.cf :

transport_maps = hash:/etc/postfix/transport
slow_destination_concurrency_limit = 2
slow_destination_rate_delay = 1s

Et dans /etc/postfix/transport, puis lancez postmap /etc/postfix/transport et systemctl reload postfix :

example.com    slow:

Étalez les grosses campagnes dans le temps et, si votre IP ou votre domaine est nouveau, augmentez le volume progressivement (voir chauffer un nouveau domaine ou une nouvelle IP). Ne faites pas tourner les IP ou les comptes pour contourner les limites : les destinataires le voient et cela nuit à votre réputation.

Si c'est votre propre serveur qui répond 421

Les valeurs par défaut (smtpd_client_connection_count_limit = 50 par client, limites de débit désactivées) conviennent à la plupart des serveurs. Si vous avez fixé des limites plus strictes, relevez-les, ou excluez les expéditeurs de confiance comme vos propres applications :

smtpd_client_event_limit_exceptions = $mynetworks, 203.0.113.10

Pour les applications, la meilleure solution reste d'envoyer via le port de soumission avec un pool de quelques connexions, comme ci-dessus.

Vérifiez que c'est corrigé

Surveillez le journal pendant le prochain envoi : les messages différés doivent quitter la file d'attente avec status=sent, et les nouvelles lignes 421 doivent cesser. Lancez un nouveau test Delivmail pour confirmer que l'authentification et la réputation sont propres, puis renvoyez votre message à l'adresse qui avait été différée si elle a finalement renvoyé une erreur.