E-mail : Trop de destinataires — Stopper les abus et corriger les envois en masse légitimes

février 2, 2026 • février 3, 2026 • Lecture : 30 min • Views: 7

Cet article vous a aidé ?

Le ticket arrive toujours sur le même ton : « Email rejeté — trop de destinataires. »
L’assistant exécutif est furieux. L’équipe RH ne parvient plus à joindre le personnel. Un système de supervision cesse discrètement d’alerter parce que sa liste de notifications a été « optimisée » en un seul courriel monstre.

Et quelque part en arrière-plan, un attaquant (ou juste un employé trop zélé) essaie d’asperger votre domaine d’e-mails sortants jusqu’à ce que la réputation de votre IP ressemble à un feu de poubelle. Votre travail consiste à arrêter l’abus sans casser les envois en masse légitimes dont votre entreprise a réellement besoin.

Ce que « trop de destinataires » signifie vraiment (et pourquoi ça existe)

« Trop de destinataires » n’est pas une seule erreur. C’est une famille de limites, appliquées à différents niveaux, pour des raisons variées :
protéger les serveurs, préserver la réputation, prévenir les abus, maintenir des files gérables et empêcher les humains d’envoyer accidentellement deux fois le même message à tous les clients.

Selon l’endroit où vous heurtez la limite, vous verrez des codes SMTP différents et des comportements différents :

Pendant la transaction SMTP (phase RCPT TO) : Le serveur récepteur rejette des destinataires supplémentaires. Réponses typiques : 452 4.5.3 Too many recipients, 550 5.5.3 Too many recipients, ou un texte spécifique au fournisseur.
Avant SMTP (politique de soumission) : Votre service de soumission (Exchange, soumission Postfix, passerelle cloud) rejette le message selon la politique, les limites par expéditeur ou les plafonds de destinataires.
Après acceptation (règle de transport/politique) : Le message est accepté, puis différé, mis en quarantaine ou rejeté parce que l’expansion (listes de diffusion) le fait dépasser la politique.
Côté application : Votre bibliothèque applicative (ou fournisseur d’API) rejette la requête car vous avez dépassé le nombre de destinataires par message ou la limite de lot par requête.

Les limites ne sont pas optionnelles. Sans elles, les systèmes de messagerie deviennent des canons bon marché pour les spammeurs et des consommations coûteuses pour votre CPU. Les plafonds de destinataires sont l’un des rares contrôles qui réduisent simultanément les abus et empêchent les envois légitimes en masse de griller votre infrastructure.

Une citation à garder près de vous :
L’espoir n’est pas une stratégie. — Gene Kranz

Blague n°1 : Les systèmes de messagerie sont comme les ascenseurs : si vous essayez d’entasser 200 personnes, vous descendrez toujours.

Faits intéressants et contexte historique (rapide, concret)

SMTP supposait à l’origine des pairs amicaux. L’architecture de messagerie primitive traitait la plupart des participants comme coopératifs ; de véritables garde-fous anti-abus sont apparus plus tard, après que le spam soit devenu un modèle économique.
RFC 5321 fixe des attentes, pas votre politique. Les standards SMTP définissent la mécanique de la conversation ; les limites de destinataires sont explicitement laissées aux implémentations et à la politique locale.
Les listes de diffusion ont changé le rayon d’impact. Une fois l’expansion de listes devenue courante, une seule adresse « To: » pouvait signifier des milliers de livraisons en aval, surchargeant les files et la réputation.
« Trop de destinataires » est souvent un 4xx, pas un 5xx. De nombreux systèmes différent plutôt que rejettent définitivement pour éviter de perdre du courrier légitime lors de pics de charge transitoires.
Les plafonds de destinataires sont anti-abus et anti-mauvaise-config. Un bug qui boucle sur une table de contacts peut générer un seul message avec des milliers de commandes RCPT ; les limites arrêtent l’hémorragie tôt.
Certaines solutions comptent les destinataires après expansion, d’autres non. Le « 50 destinataires » d’un système peut signifier « 50 commandes RCPT » tandis qu’un autre signifie « 50 après expansion de liste ». Cette différence ruine les migrations.
Les grands nombres de destinataires peuvent affecter TLS et le CPU. La transaction SMTP peut être correcte, mais les contrôles par destinataire, la signature DKIM et l’analyse du contenu coûtent plus avec chaque adresse.
La réputation est par identité d’envoi, pas par intention. Les FAI ne font pas la différence entre vos 5 000 destinataires envoyés pour un « avis de sécurité » ou un « oups » ; ils voient le volume et les plaintes.
Les MTAs classiques étaient conçus pour le store-and-forward. C’est pourquoi vous pouvez « accepter maintenant, livrer plus tard » dans une file. C’est résilience — mais aussi l’endroit où les arriérés se cachent.

Un modèle pratique : où apparaissent les limites de destinataires

1) L’expéditeur (application ou utilisateur)

Votre CRM, outil de supervision, plateforme RH, et même une tâche cron peuvent générer du mail. Beaucoup de ces
outils considèrent « e-mail » comme « un appel d’API » et placeront volontiers 2 000 destinataires dans un seul message parce que c’est simple.
C’est aussi ainsi que vous vous faites bloquer.

Les limites côté application apparaissent comme des erreurs avant même que le message ne quitte l’application : « trop de destinataires par message », « taille de lot dépassée », « requête rejetée ».
Ce sont les plus faciles à corriger : modifiez le comportement pour fractionner les destinataires, ou passez à un modèle d’envoi en masse qui produit un destinataire par message.

2) Soumission et politique sortante (là où les responsables mettent les règles)

Les serveurs de soumission (SMTP authentifié, transport Exchange, une passerelle e-mail cloud) sont l’endroit approprié pour appliquer des frontières par utilisateur et par application.
Si vous n’appliquez pas de limites ici, vous laissez chaque portable et chaque mot de passe compromis décider de votre réputation d’expéditeur.

Contrôles courants :

Limite de destinataires par message (plafond strict).
Limite de taux de messages par expéditeur (messages par minute).
Limite de taux de destinataires par expéditeur (destinataires par minute) — mieux adaptée aux modèles en masse.
Politiques par domaine destinataire (interne vs externe).
Analyse de contenu et DLP qui peuvent mal monter en charge avec de nombreux destinataires.

3) Le MTA (Postfix/Exchange/etc.) et la file

La plupart des pannes ne proviennent pas d’« un gros email ». Elles proviennent de ce que cet e-mail fait à votre file :
il multiplie le travail. Si votre système se démultiplie en livraisons par destinataire, vous obtenez plus d’entrées de file, plus de requêtes DNS, plus de négociations TLS, plus de tentatives de renvoi.

Une limite de destinataires peut protéger votre file d’un troupeau tonitruant. Ou elle peut masquer un autre goulot : DNS cassé, port 25 bloqué, relais défaillant, ou un filtre de contenu qui bloque sous charge.

4) Les récepteurs en aval (la partie que vous ne contrôlez pas)

Même si votre infrastructure accepte et met en file le message, les récepteurs peuvent appliquer leurs propres limites RCPT, plafonds par connexion, quotas par jour ou politiques anti-spam.
Votre « trop de destinataires » peut être leur « nous n’acceptons pas 100 commandes RCPT dans une seule connexion ».

Fiche de diagnostic rapide : trouver le goulot d’étranglement vite

Quand « trop de destinataires » frappe en production, ne commencez pas par changer les limites. Commencez par trouver quelle limite et qui l’applique.
Ensuite décidez si vous devez relever le plafond ou corriger le comportement.

Première étape : identifier le point d’application (expéditeur, soumission, MTA, aval)

Regardez le texte du bounce ou du rejet. Mentionne-t-il votre serveur, votre passerelle ou un domaine distant ?
Vérifiez le code de réponse SMTP. 4xx suggère un différé ; 5xx suggère une politique/rejet permanent.
Trouvez la ligne de log qui correspond au Message-ID ou à l’ID de la file. C’est la vérité terrain.

Deuxième étape : mesurer le rayon d’impact

Est-ce un expéditeur ? Une application ? Un sous-réseau ? Ou tout le monde ?
Destinataires internes seulement, ou externes aussi ?
Un message énorme, ou beaucoup de messages moyens ?

Troisième étape : décider du mode de réponse

Si un abus est plausible : contenir d’abord (ralentir, bloquer, révoquer des identifiants), puis corriger.
Si c’est un envoi en masse légitime : utilisez des modèles sûrs (fractionnement, messages par destinataire, listes de diffusion conçues pour la masse) plutôt que d’augmenter les plafonds globaux.
Si c’est un goulot de performance : corrigez le débit de la file et les performances des scanners politiques ; relever les limites de destinataires augmente simplement la taille de l’explosion.

Blague n°2 : Augmenter les limites de destinataires pour résoudre un arriéré, c’est comme acheter une poubelle plus grande pour éteindre un feu de cuisine.

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

Les tâches ci‑dessous supposent un environnement MTA Linux (Postfix est courant), avec journaux systemd.
Même si vous utilisez Exchange ou une passerelle cloud, la logique est la même : trouvez le composant qui applique la règle, validez la limite configurée, et confrontez ce qui se passe réellement sous charge.

Task 1: Find the exact rejection in logs (Postfix via journal)

cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep -E "too many recipients|Recipient address rejected|5\.5\.3|4\.5\.3" | tail -n 20
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: NOQUEUE: reject: RCPT from mailclient[10.20.3.44]: 452 4.5.3 Too many recipients; from=<alerts@corp.example> to=<dl-all@corp.example> proto=ESMTP helo=<host44>

Ce que cela signifie : Le rejet s’est produit pendant RCPT SMTP, sur mx1, dans smtpd. C’est une décision de politique entrante vers le MTA (soumission ou relais).
Ce n’est pas un récepteur distant.

Décision : Confirmez quel paramètre Postfix ou quel démon de politique applique les plafonds de destinataires pour ce service (port 25 vs 587), puis décidez s’il faut corriger le comportement de l’expéditeur ou ajuster la politique pour un expéditeur approuvé.

Task 2: Identify the client and whether it’s authenticated submission

cr0x@server:~$ sudo journalctl -u postfix --since "1 hour ago" | grep "sasl_username" | tail -n 10
Jan 04 10:12:09 mx1 postfix/smtpd[21455]: warning: unknown[10.20.3.44]: SASL LOGIN authentication failed: authentication failure

Ce que cela signifie : La même IP cliente apparaît, mais l’authentification échoue. C’est soit une mauvaise configuration, soit un abus.

Décision : Traitez cela comme suspect jusqu’à preuve du contraire. Bloquez/limitez cette IP, vérifiez les verrouillages de comptes et confirmez si l’application devrait soumettre ici du tout.

Task 3: Inspect Postfix recipient limit settings

cr0x@server:~$ sudo postconf | grep -E "smtpd_recipient_limit|default_recipient_limit|smtpd_client_recipient_rate_limit|smtpd_recipient_restrictions"
default_recipient_limit = 1000
smtpd_recipient_limit = 100
smtpd_client_recipient_rate_limit = 0
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination

Ce que cela signifie : smtpd_recipient_limit=100 est un plafond strict pendant le dialogue SMTP pour ce démon.
default_recipient_limit affecte les livraisons internes et certains comportements de file ; ce n’est pas la même porte.

Décision : Si 100 destinataires dans une seule transaction SMTP est trop bas pour des modèles en masse approuvés, envisagez des exceptions sur le service de soumission uniquement, pas sur le port 25.
Sinon : corrigez l’expéditeur pour fractionner en ensembles de destinataires plus petits.

Task 4: Check per-service overrides in master.cf (submission vs smtp)

cr0x@server:~$ sudo postconf -n | head
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no

cr0x@server:~$ sudo grep -nE "^(smtp|submission|smtps)\s" /etc/postfix/master.cf
13:smtp      inet  n       -       y       -       -       smtpd
26:submission inet n       -       y       -       -       smtpd

cr0x@server:~$ sudo sed -n '13,40p' /etc/postfix/master.cf
smtp      inet  n       -       y       -       -       smtpd

submission inet n       -       y       -       -       smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_limit=500

Ce que cela signifie : La soumission a un plafond de destinataires plus élevé (500) que le port 25. Bon modèle : plus strict pour l’entrée non authentifiée, plus flexible pour les utilisateurs/applications authentifiés.

Décision : Si le rejet provient du service smtp (port 25) mais que l’expéditeur devrait utiliser la soumission (587), corrigez le routage et les identifiants plutôt que d’augmenter les limites sur le port 25.

Task 5: Confirm which port the client used (packet capture, short and surgical)

cr0x@server:~$ sudo timeout 15 tcpdump -ni any 'host 10.20.3.44 and (port 25 or port 587)' -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
10:12:09.112233 eth0  IP 10.20.3.44.51234 > 10.20.1.10.25: Flags [S], seq 123456789, win 64240, options [mss 1460,sackOK,TS val 1 ecr 0,nop,wscale 7], length 0
10:12:09.112300 eth0  IP 10.20.1.10.25 > 10.20.3.44.51234: Flags [S.], seq 987654321, ack 123456790, win 65160, options [mss 1460,sackOK,TS val 2 ecr 1,nop,wscale 7], length 0

Ce que cela signifie : Le client atteint le port 25, pas le 587. C’est typique des MTAs, pas des applications/utilisateurs.

Décision : Déplacez le client vers la soumission (587) avec authentification et contrôles par expéditeur appropriés. Gardez le port 25 strict.

Task 6: Check queue size and whether limits are hiding a throughput problem

cr0x@server:~$ mailq | head -n 30
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
6F2A512345      3292 Thu Jan  4 10:10:01  alerts@corp.example
                                         user1@external.example
                                         user2@external.example

9C8B7128AA      8410 Thu Jan  4 10:10:05  hr@corp.example
                                         dl-all@corp.example
-- 52 Kbytes in 2 Requests.

Ce que cela signifie : Il y a des messages en file ; pas nécessairement mauvais. Mais si la file croît en continu, les limites de destinataires peuvent être un effet secondaire de la rétro-pression.

Décision : Si la file augmente : investiguez la connectivité sortante, le DNS, la limitation distante et les filtres de contenu. Ne « résolvez » pas cela en autorisant des lots plus grands.

Task 7: Inspect a queued message for recipient count and headers

cr0x@server:~$ sudo postcat -q 9C8B7128AA | sed -n '1,80p'
*** ENVELOPE RECORDS ***
message_size:            8410             8410
message_arrival_time: Thu Jan  4 10:10:05 2026
sender: hr@corp.example
named_attribute: rewrite_context=local
recipient: dl-all@corp.example
*** MESSAGE CONTENTS ***
Received: from hr-app (10.20.9.15) by mx1 with ESMTPA; Thu, 4 Jan 2026 10:10:05 +0000
To: dl-all@corp.example
Subject: Updated handbook policy

Ce que cela signifie : L’enveloppe n’a qu’un destinataire : une liste de diffusion. L’explosion se produira lors de l’expansion.

Décision : Déterminez où l’expansion de la liste a lieu (service d’annuaire, maps d’alias MTA, gestionnaire de listes). Définissez des limites sur les destinataires étendus et fournissez un mécanisme d’envoi en masse approuvé.

Task 8: Check alias/database expansion size (example: Postfix virtual aliases)

cr0x@server:~$ sudo postmap -q dl-all@corp.example /etc/postfix/virtual
user1@corp.example,user2@corp.example,user3@corp.example,user4@corp.example,user5@corp.example

Ce que cela signifie : La liste s’étend localement en plusieurs destinataires. Si ce mapping devient énorme, vous atteindrez des limites ou des problèmes de performance.

Décision : Pour les grandes listes, migrez vers un gestionnaire de listes ou un groupe adossé à l’annuaire avec envoi contrôlé ; évitez de fourrer des milliers d’adresses dans des maps plates.

Task 9: Validate DNS health (because “too many recipients” sometimes is just “too slow”)

cr0x@server:~$ dig +time=2 +tries=1 mx external.example
;; ANSWER SECTION:
external.example.   300  IN  MX  10 mx.external.example.

cr0x@server:~$ dig +time=2 +tries=1 mx.external.example a
;; ANSWER SECTION:
mx.external.example. 300 IN A 203.0.113.25

Ce que cela signifie : Le DNS résout rapidement. Si cela était lent ou en timeout, votre MTA pourrait accumuler et commencer à différer, ce que les gens lisent mal comme « limites de destinataires ».

Décision : Si le DNS est lent : corrigez les résolveurs, le caching et le pare‑feu. La pression sur la file se manifeste souvent par des symptômes de politique étranges.

Task 10: Test remote acceptance behavior with a controlled SMTP session

cr0x@server:~$ nc -v mx.external.example 25
Connection to mx.external.example 25 port [tcp/smtp] succeeded!
220 mx.external.example ESMTP

cr0x@server:~$ printf "EHLO mx1.corp.example\r\nMAIL FROM:<test@corp.example>\r\nRCPT TO:<a@external.example>\r\nRCPT TO:<b@external.example>\r\nDATA\r\nSubject: test\r\n\r\ntest\r\n.\r\nQUIT\r\n" | nc mx.external.example 25
220 mx.external.example ESMTP
250-mx.external.example
250 PIPELINING
250-SIZE 52428800
250 HELP
250 2.1.0 Ok
250 2.1.5 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF>
250 2.0.0 Accepted
221 2.0.0 Bye

Ce que cela signifie : Le distant accepte au moins quelques destinataires. Pour tester les plafonds de destinataires, ajoutez beaucoup de lignes RCPT (avec précaution, et jamais à grande échelle en production).

Décision : Si le distant rejette après N commandes RCPT, vous devez fractionner les destinataires par message ou par connexion. Votre limite locale peut être correcte ; l’internet n’est pas d’accord.

Task 11: Detect a single sender generating abnormal volume

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | grep " from=<" | sed -n 's/.*from=<\([^>]*\)>.*/\1/p' | sort | uniq -c | sort -nr | head
  842 alerts@corp.example
  115 hr@corp.example
   23 noreply@corp.example

Ce que cela signifie : Un expéditeur domine. C’est soit un incident réel (orage de supervision, jeton compromis) soit une campagne planifiée qui a oublié d’utiliser le canal bulk.

Décision : Si ce n’est pas prévu, throttlez/bloquez cet expéditeur immédiatement. Ensuite inspectez le système générateur pour boucles, retries ou compromission d’identifiants.

Task 12: Verify outbound concurrency settings (Postfix), because “just raise recipient limit” is a trap

cr0x@server:~$ sudo postconf | grep -E "default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|qmgr_message_active_limit"
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Ce que cela signifie : Vous pouvez pousser jusqu’à 20 livraisons concurrentes par destination par défaut. Si vous augmentez le batching de destinataires, vous pouvez amplifier la concurrence et déclencher des limitations en aval.

Décision : Réglez la concurrence et les délais par destination (surtout pour les gros fournisseurs) plutôt que d’augmenter le nombre de destinataires par message. « Plus rapide » signifie souvent « bloqué plus vite ».

Task 13: Confirm whether a content filter is the real bottleneck

cr0x@server:~$ systemctl status rspamd | sed -n '1,12p'
● rspamd.service - Rspamd Mail Filter
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-04 08:01:22 UTC; 2h 12min ago
       Docs: man:rspamd(8)

cr0x@server:~$ sudo journalctl -u rspamd --since "30 min ago" | tail -n 5
Jan 04 10:11:58 mx1 rspamd[1322]: lua; task; slow task: 2.34 seconds: id: <20260104101158.12345@mail>

Ce que cela signifie : Le filtrage est lent sous la charge actuelle. Les envois à grand nombre multiplient les analyses et opérations de signature selon l’architecture.

Décision : Corrigez les performances du filtre, le scaling ou les règles de contournement pour les canaux bulk internes approuvés. N’augmentez pas les limites de destinataires pour nourrir un filtre lent.

Task 14: Add a targeted temporary throttle to contain an incident (Postfix anvil)

cr0x@server:~$ sudo postconf -e "smtpd_client_message_rate_limit = 60"
cr0x@server:~$ sudo postconf -e "smtpd_client_recipient_rate_limit = 300"
cr0x@server:~$ sudo systemctl reload postfix

cr0x@server:~$ sudo postconf | grep -E "smtpd_client_message_rate_limit|smtpd_client_recipient_rate_limit"
smtpd_client_message_rate_limit = 60
smtpd_client_recipient_rate_limit = 300

Ce que cela signifie : Vous avez défini des taux par client. Cela ne « règle » pas les e-mails en masse, ça vous achète du temps et protège le reste du système.

Décision : Utilisez cela comme contrôle d’incident. Ensuite déplacez les expéditeurs en masse légitimes vers un chemin séparé avec des limites plus élevées et une meilleure authentification/surveillance.

Concevoir des envois en masse légitimes qui ne déclenchent pas de limites

Si vous devez envoyer à des centaines ou des milliers de destinataires, la conception correcte est ennuyeuse :
n’envoyez pas un seul message avec des centaines de destinataires RCPT en espérant que tout ira bien.
Concevez pour la délivrabilité, l’observabilité et la rétro‑pression.

Modèle préféré : un destinataire par message (avec personnalisation)

Pour les envois externes en masse, un destinataire par message est généralement le plus sûr :

Les FAI et passerelles peuvent scorer par destinataire (plaintes, rebonds) sans pénaliser tout le lot.
Vous pouvez réguler par domaine destinataire et temporiser les volumes pour éviter les limites de taux.
Les rebonds se cartographient proprement à un utilisateur. Le support arrête de deviner.
La confidentialité est préservée. Personne ne reçoit une liste surprenante de clients en CC.

Oui, c’est plus de messages. C’est pourquoi l’envoi en masse doit utiliser un canal ingénieré : IP/pool dédié, quotas clairs et contrôle explicite du taux.

Modèle interne acceptable : expansion de liste contrôlée, autorisation stricte des expéditeurs

Le courrier interne a des objectifs différents. Vous pouvez vouloir des listes de diffusion pour :
annonces générales, communications d’incident, transmissions d’équipe. D’accord. Mais faites de l’expansion de liste un service géré, pas un fichier d’alias aléatoire.

Règles pour garder l’interne en masse sain :

N’autorisez que des expéditeurs spécifiques aux grandes listes. Tout le monde doit passer par un processus de demande ou utiliser une liste modérée.
Fixez des plafonds par paliers : petites listes (jusqu’à 50) ouvertes ; listes moyennes (50–500) nécessitent authentification ; grandes listes exigent modération ou outil dédié.
Segmentez par fonction : « tout le personnel » est pour les urgences et avis requis, pas pour les sondages de déjeuner.
Gardez l’expansion visible : journalisez le nombre de destinataires étendus et qui l’a déclenchée.

Fractionnement (quand vous ne pouvez pas faire un message par destinataire)

Certains systèmes (applications legacy, certains outils de notification) ne peuvent pas faire un destinataire par message, mais peuvent envoyer plusieurs destinataires.
Alors le fractionnement est votre ami :

Gardez chaque message sous le plus petit plafond de destinataires connu le long de votre chemin (soumission, passerelle, domaines distants).
Espacez les lots avec un contrôle de taux : destinataires par minute, pas messages par minute.
Séparez destinataires internes et externes. Toujours. Politiques différentes, conséquences différentes.

Ne confondez pas listes de diffusion et mailings en masse

Une liste de diffusion est une commodité d’adressage. Le mailing en masse est une charge de livraison.
Si vous exécutez de grandes campagnes via une DL, vous échouerez de la manière la moins prévisible :
parfois cela marche, jusqu’à ce que ça ne marche plus, et alors vous obtenez des piles de rebonds et une entaille de réputation.

Arrêter les abus sans dommages collatéraux

Les erreurs « trop de destinataires » peuvent signifier que vos contrôles fonctionnent. Ou elles peuvent signifier que vos contrôles sont au mauvais endroit.
La prévention des abus doit être couchée, pas seulement un plafond unique qui punit tout le monde.

À quoi ressemble l’abus dans le domaine des limites de destinataires

Un seul hôte interne essaie d’envoyer des messages avec des centaines de commandes RCPT TO.
Un compte compromis envoie vers de nombreux destinataires externes rapidement, souvent avec des sujets similaires.
Les échecs se regroupent autour d’échecs d’authentification, de noms HELO inhabituels ou de clients inconnus.
Votre file se remplit de mails différés vers de nombreux domaines, avec des retries répétés.

Contrôles efficaces (et qui ne détruisent pas les envois légitimes)

Séparer la soumission pour les applis : identifiants distincts, limites distinctes, journaux distincts. Si ça casse, ça casse seulement ce chemin.
Limites de taux de destinataires par expéditeur : plafonner les destinataires/minute par utilisateur/app, pas seulement destinataires/message.
Caps de destinataires par niveau de confiance : ex. 50 pour les utilisateurs généraux, 500 pour un service applicatif authentifié, 5 000 pour un système bulk dédié avec surveillance.
Autorisation sortante par usage : alertes de supervision vers un petit ensemble ; avis RH internes seulement ; marketing utilise l’infrastructure bulk.
Alerting sur anomalies : « expéditeur a dépassé la base de 10x » vaut mieux que « la file est en feu » à chaque fois.

La règle impopulaire : ne laissez pas les utilisateurs envoyer en masse

Si une personne veut envoyer à 2 000 destinataires, elle ne doit pas le faire depuis Outlook sur la soumission SMTP d’entreprise.
Pas parce que les humains sont mauvais. Parce que les humains sont occupés, et les gens occupés cliquent deux fois sur « envoyer ».

Fournissez un mécanisme : un outil de communication interne, un processus sur ticket, ou une liste modérée avec journaux d’audit.
Votre futur vous remerciera quand le service juridique demandera « qui a envoyé quoi, quand, à qui ».

Trois mini-récits d’entreprise (anonymisés, plausibles)

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

Une entreprise de taille moyenne a migré d’une passerelle mail à une autre. Le plan de projet avait les points habituels :
alignement SPF/DKIM, réglages TLS, connecteurs. Quelqu’un a demandé les limites de destinataires. La réponse fut un haussement d’épaules :
« Nous n’avons jamais eu de problème, donc les valeurs par défaut suffisent. »

Deux semaines plus tard, les RH ont essayé d’envoyer un rappel d’inscription aux avantages à une liste de diffusion du personnel.
Le message a rebondi avec « trop de destinataires ». L’équipe a escaladé vers l’IT, qui a examiné le message et a vu un seul destinataire : all-staff@corp.example.
« Ça ne peut pas être ça », ont-ils dit, et ont relevé la limite de destinataires par message sur la soumission.

L’erreur a persisté. Parce que le point d’application n’était pas la soumission ; c’était la politique d’expansion de la nouvelle passerelle.
La nouvelle passerelle comptait les destinataires après expansion. L’ancienne ne comptait que les destinataires d’enveloppe. Même comportement utilisateur, sémantique différente.

La solution fut ennuyeuse : créer un canal de diffusion interne homologué avec autorisation explicite et taille maximale définie, plus une route séparée pour les messages RH.
La leçon réelle était plus nette : « limite de destinataires » a besoin d’une définition. Comptez‑vous les RCPT, les destinataires d’en‑tête ou les destinataires étendus ? Si vous ne savez pas, vous configurez au doigt mouillé.

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

Une équipe plateforme voulait réduire la charge sur leur service de notifications. Il envoyait de nombreux alertes similaires à de grands groupes d’astreinte.
Quelqu’un proposa : « Au lieu d’un e‑mail par personne, envoyons un e‑mail au groupe. C’est moins de messages et ça devrait être plus rapide. »
Sur le tableau blanc, c’était élégant.

En production, c’était une panne au ralenti. Le service de notifications a commencé à émettre des e‑mails avec 300–800 destinataires chacun.
Le serveur de soumission les acceptait. Puis le MTA a multiplié les livraisons et les a remis au scanning de contenu et à la signature DKIM.
Le CPU a monté, la latence a augmenté, la file mail s’est affûtée les dents, puis les rejets « trop de destinataires » ont commencé quand l’équipe a essayé d’augmenter le débit en relevant la concurrence.

Pendant ce temps, un destinataire s’est plaint et son fournisseur a commencé à temporiser. Parce que tout le monde était empaqueté, les retries ont touché l’ensemble.
Une seule limitation à l’extérieur a causé des renvois répétés à des centaines de personnes, ce qui est devenu suspect et a déclenché d’autres limitations.

Ils sont revenus à un message par destinataire avec limitation par domaine. Cela utilisait plus d’entrées de file, mais se comportait de façon prédictible et dégradait gracieusement.
L’optimisation était juste en comptabilité. En exploitation, elle augmentait le couplage : un mauvais destinataire faisait souffrir tout le monde.

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

Une société de services financiers avait une posture stricte : points de soumission SMTP séparés pour les humains, les applis et les systèmes bulk.
Tout le monde s’en plaignait lors de l’intégration. « Pourquoi ne puis‑je pas juste utiliser le serveur mail normal ? » était un refrain hebdomadaire.
La sécurité aimait. Le SRE le tolérait. Ça a duré.

Un lundi matin, un compte de service interne a été compromis (phishing, prévisible et banal).
L’attaquant a tenté d’envoyer du spam sortant à des milliers de destinataires par message, depuis un hôte applicatif compromis.
La tentative a d’abord frappé le point de soumission humain — mauvais identifiants — puis a essayé le point applicatif.

Le point applicatif n’autorisait qu’un plafond bas de destinataires par message et avait des limites strictes de taux de destinataires.
Les journaux avaient un index dédié pour la soumission applicative avec des baselines par expéditeur. L’alerte a déclenché en quelques minutes :
« service-account-x destinataires/min dépassé ». La limitation a empêché un dommage massif et la réputation IP est restée intacte.

Le nettoyage fut simple : révoquer les identifiants, faire pivoter les tokens, ajouter MFA quand possible et revoir les règles de pare‑feu egress.
Le meilleur : les RH et les équipes d’astreinte ne l’ont jamais remarqué. La séparation terne des chemins a contenu l’explosion dans une petite boîte.

Erreurs courantes : symptôme → cause racine → solution

1) Symptom: “Too many recipients” on internal DL sends, even though email shows one address

Cause racine : Le système qui applique la limite compte les destinataires étendus après l’expansion de la liste de diffusion.

Solution : Gérez les grandes listes avec autorisation d’envoi explicite et un mécanisme bulk/broadcast. Documentez si les limites comptent RCPT vs expansion. Ne relevez pas les plafonds globalement.

2) Symptom: Raising `smtpd_recipient_limit` didn’t help

Cause racine : La limite est appliquée ailleurs : override de service de soumission, démon de politique, passerelle ou récepteur distant.

Solution : Identifiez le point d’application via les logs et la réponse SMTP. Vérifiez les overrides par service (master.cf), les services de politique et les réponses distantes.

3) Symptom: Legit bulk sends work sometimes, then fail under load

Cause racine : Pression sur la file et timeouts. Filtrage de contenu lent, problèmes DNS ou limitation distante rendent les transactions plus lentes et déclenchent les défenses de taux/destinataires.

Solution : Améliorez le débit : DNS, scaling des filtres, tuning de la concurrence, pacing par destination. Gardez le nombre de destinataires modeste ; fractionnez les envois.

4) Symptom: One team’s newsletter causes widespread bounces and reputation hits

Cause racine : Utiliser la soumission SMTP d’entreprise comme canal marketing/bulk ; pas d’option de désabonnement, mauvaise hygiène de liste, pas de pacing par domaine.

Solution : Déplacez le marketing/bulk vers un système dédié avec gestion des listes, traitement des plaintes et identité d’envoi séparée.

5) Symptom: “Too many recipients” from a single internal IP, with auth failures

Cause racine : Hôte compromis ou appli mal configurée martelant le port 25 ; possible stuffing d’identifiants ou malware.

Solution : Contenez : bloquez au pare‑feu, activez les limites par client, investiguez l’endpoint, faites pivoter les identifiants et exigez la soumission authentifiée sur 587 pour les applis.

6) Symptom: External providers accept some recipients, reject others mid-transaction

Cause racine : Plafonds distants par connexion, ou règles anti-spam agressives déclenchées par un grand nombre de RCPT.

Solution : Baissez les destinataires par message et/ou ouvrez de nouvelles connexions par lot. Utilisez un pacing par domaine et respectez les déferrals 4xx.

Listes de contrôle / plan pas à pas

Étapes : gérer un incident « trop de destinataires » en production

Collecter les preuves : texte du bounce, code SMTP, fenêtre temporelle, expéditeur et échantillon de destinataires.
Trouver la ligne de log : faire correspondre le Message-ID ou l’ID de file ; identifier le serveur et le service qui appliquent la règle (25 vs 587).
Classer : suspicion d’abus vs envoi en masse légitime vs tempête de CC accidentelle.
Contenir si suspect : throttle par client/expéditeur ; bloquer l’IP fautive ; révoquer des identifiants si nécessaire.
Vérifier la santé de la file : si l’arriéré augmente, investiguez le débit avant de changer les limites.
Identifier le point d’application : politique de soumission, MTA, expansion de liste, passerelle, récepteur en aval.
Choisir la bonne correction :
- Bulk légitime : fractionnement, messages par destinataire, chemin bulk dédié.
- Diffusion interne : liste modérée et groupe d’expéditeurs approuvés.
- Abus : appliquer l’authentification de soumission, limites de taux, détection d’anomalies, réponse endpoint.
Mettre en place une exception sécurisée : seulement si nécessaire ; la restreindre à un compte de service et un listener de soumission spécifique.
Ajouter de l’observabilité : tableaux de bord pour destinataires/minute par expéditeur, top talkers, raisons de rejet, profondeur de file.
Nettoyage post-incident : documenter les définitions (RCPT vs expansion), publier une politique d’envoi en masse et former les équipes à son usage.

Checklist : ce qu’il faut standardiser pour éviter les récidives

Documenter les limites de destinataires pour chaque voie : inbound 25, soumission 587, relais applicatif, relais bulk.
Rendre les limites par paliers (humains vs applis vs bulk), avec identifiants et logs séparés.
Définir « nombre de destinataires » dans votre environnement : RCPT d’enveloppe, destinataires d’en‑tête, destinataires étendus.
Définir la gouvernance des grandes listes : propriétaire, but, autorisation d’expéditeur, règles de modération, taille maximale.
Introduire un service d’envoi en masse (interne) pour les diffusions approuvées, avec journaux d’audit et contrôle de taux.
Fixer des limites de taux sur messages/minute et destinataires/minute ; alerter sur les anomalies.
Opérationnaliser l’hygiène des listes : gestion des rebonds, suppression des adresses obsolètes, revue des membres de groupe.
Organiser des game days : simuler un compte compromis envoyant à 1 000 destinataires ; vérifier throttles et alertes.

FAQ

1) Est‑ce que « trop de destinataires » signifie toujours un abus ?

Non. C’est souvent un cas d’usage en masse légitime qui entre en collision avec une limite établie pour de bonnes raisons. Traitez-le comme un décalage de politique jusqu’à ce que les logs suggèrent une compromission (échecs d’auth, clients inhabituels, pics soudains de volume).

2) Dois‑je simplement augmenter la limite de destinataires ?

Pas globalement. Augmentez les limites uniquement sur un chemin dédié et authentifié pour des expéditeurs de confiance, et associez‑les à des limites de taux de destinataires. Sinon vous élargissez le rayon d’impact du prochain compromis.

3) Pourquoi un message vers une liste de diffusion compte‑t‑il comme plusieurs destinataires ?

Parce que l’expansion transforme une adresse en de nombreuses livraisons. Certains systèmes appliquent les limites après expansion. C’est souvent le comportement approprié : il reflète la charge réelle et le risque.

4) Quelle est la manière la plus sûre d’envoyer à 10 000 destinataires externes ?

Un destinataire par message, rythmé par domaine destinataire, en utilisant un système d’envoi en masse avec traitement des retours (rebonds/plaintes). Les MTAs de soumission d’entreprise ne sont pas conçus pour des campagnes.

5) Pourquoi je vois 452 (4xx) au lieu de 550 (5xx) ?

4xx est un échec temporaire : le serveur dit « pas maintenant » (charge, throttling, limites de taux). 5xx est un échec permanent ou de politique. Opérationnellement, 4xx indique souvent une rétro‑pression ou un contrôle de taux plutôt qu’une règle stricte.

6) Comment éviter de casser les diffusions internes légitimes ?

Fournissez un mécanisme homologué de diffusion : grandes listes modérées, expéditeurs autorisés spécifiques et un endpoint de soumission séparé pour les communications internes. Maintenez ensuite des limites conservatrices sur la soumission générique des utilisateurs.

7) Mon fournisseur d’app dit « nous avons besoin de 1 000 destinataires par message ». Que faire ?

Argumentez. Demandez quel problème ils résolvent en regroupant les destinataires. S’ils ne peuvent pas faire un destinataire par message, implémentez un fractionnement de votre côté ou insérez un relais qui étend en toute sécurité tout en appliquant des limites de taux et en journalisant.

8) Sur quelles métriques dois‑je alerter pour détecter ça tôt ?

Top expéditeurs par destinataires/minute, taux de rejets par code de raison, taux d’augmentation de la profondeur de file, livraisons différées par domaine de destination, et échecs d’authentification sur les endpoints de soumission.

9) Les limites de destinataires peuvent‑elles affecter le stockage ?

Oui. Un fort fan‑out augmente les entrées de file et l’activité du spool. Si votre file mail est sur un stockage lent, vous verrez latence et différés qui masquent des échecs de politique. Gardez le spool sur des disques fiables et à faible latence et surveillez l’I/O wait.

10) Comment expliquer cela aux parties prenantes non techniques ?

Dites : « Nous limitons combien de personnes un seul e‑mail peut cibler en même temps pour prévenir le spam et les pannes. Pour les envois massifs, nous utilisons un processus de diffusion plus sûr. »

Conclusion : prochaines étapes pratiques

« Trop de destinataires » est une fonctionnalité qui porte le masque d’une panne. Votre objectif n’est pas de la faire taire. Votre objectif est de la rendre précise :
bloquer l’abus tôt, router le bulk légitime via un canal contrôlé, et garder le chemin e‑mail par défaut sûr pour le travail quotidien.

Prochaines étapes qui font vraiment avancer les choses :

Écrivez vos limites par service et définissez ce que « destinataire » signifie dans votre environnement.
Séparez la soumission mail par niveau de confiance (humains, applis, bulk) avec identifiants et journaux séparés.
Implémentez la limitation de taux de destinataires et alertez sur les expéditeurs anormaux avant que la réputation ne soit endommagée.
Corrigez les modèles d’envoi en masse (un destinataire par message ou fractionnement), plutôt que d’augmenter les plafonds globaux.
Gérez les grandes listes internes avec des propriétaires, de la modération et un processus de diffusion approuvé.