Limitation de débit Postfix : prévenir les abus sans bloquer les utilisateurs réels

Ce que signifie réellement la limitation de débit dans Postfix (et ce que ce n’est pas)

La limitation de débit dans Postfix n’est pas une fonctionnalité unique. C’est un ensemble de soupapes de sécurité à différents niveaux :

• Contrôles au niveau de la connexion : combien de sessions TCP un client peut ouvrir, la vitesse d’ouverture et combien de temps vous tolérerez qu’elles restent inactives.
• Contrôles au niveau du protocole : combien de destinataires par message, combien de commandes par session, à quelle vitesse un client peut pipeliner.
• Contrôles au niveau de l’authentification : limiter les envois SASL authentifiés pour qu’un compte compromis ne puisse pas envoyer 50 000 messages avant que vous ne réagissiez.
• Contrôles de la file et de la livraison : empêcher un seul domaine ou une destination de consommer tous les créneaux de livraison et de vous faire throttler par les grands fournisseurs.
• Contrôles de politique : «cerveaux» externes qui appliquent des règles par utilisateur/expéditeur/client selon l’état, la réputation ou le contexte métier.

La limitation de débit n’est pas un filtre anti-spam. Elle ne décidera pas si un message est du spam. Elle décide quelle quantité de dégâts une source peut causer par unité de temps. Elle vous achète du temps et préserve le service pour les autres.

De plus, la limitation de débit n’est pas du «blocage». La meilleure limitation est déférer d’abord—ralentir les comportements suspects tout en laissant passer le trafic normal. Les rejets sont réservés aux violations de politique claires, pas à «mon serveur est occupé». Si vous rejetez parce que vous êtes surchargé, vous exportez votre incident chez quelqu’un d’autre, et ils s’en souviendront.

Véracité sèche et amusante #1 : SMTP laisse volontiers un ordinateur portable dans un café tenter de devenir votre «plateforme d’envoi en masse». Il a la confiance d’un bambin avec un marqueur indélébile.

Trois principes pour éviter les pannes auto-infligées

1. Façonnez le trafic, n’improvisez pas. Utilisez des limites mesurables (par IP, par utilisateur, par destination) plutôt que des intuitions.
2. Privilégiez l’échec temporaire au refus définitif. Les réponses 4xx préservent les schémas de délivrabilité et réduisent les tickets support.
3. Rendez les exceptions explicites. Si vous devez autoriser un partenaire relais ou un expéditeur massif, placez-les dans une voie contrôlée plutôt que d’augmenter les limites globales.

Une citation à garder sur un post-it

L’espérance n’est pas une stratégie. — Général Gordon R. Sullivan

La limitation de débit, c’est remplacer l’espérance par des contrôles.

Contexte et faits : pourquoi les limites Postfix fonctionnent ainsi

Un peu de contexte aide à comprendre pourquoi Postfix vous offre un assortiment de réglages plutôt qu’un bouton unique «limiter le spam» :

1. Le SMTP est antérieur à l’internet commercial. Il a été conçu pour des hôtes coopératifs, pas pour des clients hostiles, si bien que la limitation de débit est devenue une compétence de survie ajoutée ensuite.
2. Postfix a été créé comme alternative à Sendmail avec la sécurité et les performances comme objectifs primaires, incluant une architecture multi-processus capable de continuer à fonctionner quand des parties sont sous contrainte.
3. «anvil» existe parce que compter les connexions coûte cher. Postfix a ajouté le service anvil(8) pour suivre efficacement les taux par client sans que chaque processus ne le réinvente.
4. Le greylisting a popularisé l’idée de «ralentir le mauvais». La limitation de débit est sa cousine : faire payer en temps l’automatisation abusive.
5. Les gros récepteurs ont commencé à appliquer la réputation à grande échelle (taux, plaintes, rebonds), transformant la limitation sortante en fonctionnalité de délivrabilité, pas seulement de sécurité.
6. Les botnets ont changé la donne pour l’entrée. Une seule IP n’est plus forcément «la source». L’abus vient maintenant d’essaims, ce qui rend les limites par IP nécessaires mais insuffisantes.
7. Le credential stuffing a migré vers la soumission mail parce que la réutilisation de mots de passe est intemporelle. Limiter les tentatives d’authentification est maintenant une hygiène de base.
8. Le NAT dans le cloud complique la «justice par IP». Des centaines d’utilisateurs légitimes peuvent apparaître sous une même IP ; il faut donc des limites qui considèrent l’identité authentifiée, pas seulement l’adresse client.

Choisir un modèle de menace avant de toucher un réglage

Si vous ne décidez pas ce que vous protégez, vous allez implémenter des «limites» qui punissent les mauvaises personnes.

Menaces entrantes (rôle serveur SMTP)

• Inondations de connexions (files SYN/accept, épuisement de processus, CPU TLS) : réglez cela avec postscreen, des limites anvil et du tuning au niveau OS.
• Attaques de récolte d’annuaire (beaucoup de RCPT TO) : réglez cela avec des limites de destinataires, du tarpitting et des restrictions de politique.
• SMTP style Slowloris (garder des sessions ouvertes, sucrer les commandes) : réglez cela avec des timeouts et une concurrence par client minimale.

Menaces sortantes (rôle submission/relay)

• Boîte compromise : plafonnez les taux par utilisateur / par SASL et alertez sur les anomalies.
• Expéditeur massif «accidentel» : appliquez des politiques par client et par expéditeur ; dédiez une instance ou un transport séparé.
• Throttling côté destinataire (gros fournisseurs) : limitez la concurrence par destination et lissez les rafales pour protéger la réputation.

Décidez ce que représente le «bon courriel»

Les vrais utilisateurs ont tendance à suivre des schémas : quelques destinataires, des taux modérés, des destinations cohérentes. L’abus tend à être pointu, large et impatient. Votre configuration doit encoder cette différence.

Procédure de diagnostic rapide : trouver le goulot en quelques minutes

Quand quelqu’un dit «le mail est lent» ou «certains utilisateurs ne peuvent pas envoyer», ne modifiez pas immédiatement main.cf. Déterminez d’abord quel limiteur est actif : réseau, smtpd, politique, file ou récepteurs en aval.

Première question : est-ce l’acceptation entrante ou la livraison sortante ?

• Si les utilisateurs signalent «impossible d’envoyer» depuis leurs clients : vérifiez le service de submission, SASL, le démon de politique et les plafonds sortants.
• Si des expéditeurs distants disent «nous ne vous atteignons pas» : vérifiez les écouteurs entrants, postscreen, les limites de connexion et le DNS.

Deuxième : regardez la file et les raisons de différé

Une file différée qui grossit indique un throttling en aval ou un problème de concurrence de livraison. Une file active qui croît suggère une contention locale ou une concurrence trop basse.

Troisième : confirmez ce que Postfix fait aux clients

Les logs indiquent si vous rejetez (5xx), différez (4xx) ou êtes simplement lent. La limitation de débit apparaît souvent comme «too many connections», «policyd: … action=defer» ou des abandons par postscreen.

Quatrième : identifiez les gros émetteurs

Trouvez quelles IP, quels utilisateurs SASL ou quelles adresses expéditrices dominent le trafic. Appliquez les limites chirurgicalement.

Boîte à outils de limitation : anvil, postscreen, policyd et consorts

1) anvil(8) : suivi par client des connexions et des taux

Anvil conserve des compteurs comme «connexions par client par unité de temps» et «connexions simultanées par client». Il alimente des paramètres Postfix tels que :

• smtpd_client_connection_count_limit
• smtpd_client_connection_rate_limit
• smtpd_client_message_rate_limit
• smtpd_client_recipient_rate_limit

Ce sont des outils bruts mais efficaces. Ils sont aussi faciles à mal appliquer aux populations NATées (universités, entreprises, opérateurs mobiles) où de nombreux utilisateurs légitimes partagent une IP.

2) postscreen : arrêter les déchets avant qu’ils ne deviennent une charge SMTP

postscreen gère la phase initiale de connexion et peut éliminer les évidences de spam à bas coût. C’est votre «videur d’entrée». Utilisez-le quand le SMTP entrant reçoit de grands volumes de spam ou de trafic bot.

postscreen est particulièrement utile lorsque les négociations TLS et SMTP consomment du CPU. Mieux vaut éviter la négociation que de limiter après avoir déjà payé le coût.

3) Services de politique : des limites plus intelligentes selon l’identité et le contexte

La délégation de politique Postfix (check_policy_service) permet à un service externe de décider d’accepter/différer/rejeter selon :

• Nom d’utilisateur SASL
• Adresse de l’expéditeur
• IP client et HELO
• Destinataire, domaine et métadonnées du message

C’est ici que vous implémentez «messages par heure par utilisateur», «limites par plan client» et «voie spéciale pour systèmes de confiance» sans transformer votre smtpd en tableur vivant.

4) Modelage de la livraison : ne vous faites pas throttler par les gros récepteurs

Postfix peut limiter la concurrence et le taux par destination, via les transports et les réglages par destination (par exemple, ajuster la concurrence et les délais). Il s’agit moins d’arrêter l’abus que de rester bienvenu chez vos destinataires.

5) Séparation du service de submission : protéger l’entrée de la sortie

Si vous exécutez à la fois MX entrant et submission sortante sur le même hôte, isolez les services. Ports différents, restrictions différentes, limites différentes. Même binaire, comportement différent. La bonne configuration est ennuyeuse. Gardez-la ennuyeuse.

Baselines sensées : valeurs de départ qui ne ruinent pas votre journée

Il n’existe pas de chiffre universel. Mais il existe des erreurs universelles : fixer des limites si basses que les retries légitimes déclenchent une tempête de support, ou si hautes qu’une compromission devient un événement médiatique.

Suggestions pour l’entrée (MX)

• Utilisez postscreen si vous recevez un volume significatif de bots.
• Fixez une concurrence par client conservatrice (smtpd_client_connection_count_limit) pour empêcher un seul IP de monopoliser les workers.
• Employez des timeouts pour tuer les sessions lentes : smtpd_timeout, smtpd_helo_timeout, smtpd_recipient_limit (le nombre de destinataires n’est pas un timeout, mais il limite un schéma d’abus courant).

Suggestions pour la sortie (submission/relay)

• Limiter par utilisateur SASL, pas par IP, si vous avez des clients NATés.
• Privilégier le defer au rejet en cas d’excès de taux. Les utilisateurs réessayent ; les maliciels réessaient aussi, mais cela vous donne du temps de détection.
• Plafonner strictement le nombre de destinataires par message pour la soumission afin d’éviter les catastrophes «un message à 10 000 destinataires».

Véracité sèche et amusante #2 : Tout serveur mail finit par devenir un serveur d’envois massifs. La seule question est de savoir si cela se produit avec votre accord.

Tâches pratiques (commandes, sorties, décisions)

Voici les actions à mener lors d’incidents réels et lors d’ajustements. Chaque tâche inclut : la commande, ce que signifie une sortie typique, et la décision suivante.

Tâche 1 : Confirmer que Postfix est actif et quels services écoutent

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

Sens : Postfix est en cours d’exécution. Si ce n’est pas le cas, les limitations de débit ne sont pas votre problème ; c’est la disponibilité du service, la syntaxe de config ou les dépendances.

Décision : Si inactive/failed, inspectez journalctl -u postfix et exécutez postfix check avant de toucher au tuning.

Tâche 2 : Inspecter les paramètres clés de limitation en vigueur

cr0x@server:~$ postconf -n | egrep 'anvil|client_.*rate|client_.*count|recipient_limit|smtpd_timeout|postscreen'
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 60
smtpd_client_message_rate_limit = 120
smtpd_client_recipient_rate_limit = 600
smtpd_recipient_limit = 200
smtpd_timeout = 60s

Sens : Ce sont des réglages non‑par défaut dans votre config active. Beaucoup d’incidents commencent par «quelqu’un a modifié ça il y a des mois».

Décision : Notez ces valeurs. En cas d’incident, considérez les changements comme des rollbacks planifiés, pas des expériences.

Tâche 3 : Vérifier qu’anvil est activé (ces limites en dépendent)

cr0x@server:~$ postconf anvil
anvil = unix - - n - 1 anvil

Sens : Le service anvil est disponible pour suivre les taux. S’il manque, certains paramètres de limitation ne se comporteront pas comme prévu.

Décision : Si anvil est désactivé ou en échec, corrigez cela d’abord ; sinon vous poursuivrez des «limites» fantômes.

Tâche 4 : Vérifier la taille et la composition de la file

cr0x@server:~$ mailq | tail -n 20
-- 12 Kbytes in 23 Requests.

Sens : File petite. Votre problème est probablement l’acceptation (clients bloqués) plutôt qu’un arriéré de livraison.

Décision : Si la file est énorme, pivotez vers les raisons de différé et le shaping des destinations (Tâches 5–7).

Tâche 5 : Résumer les raisons des différés depuis les logs (ce qui échoue réellement)

cr0x@server:~$ grep -E "status=deferred|status=bounced" /var/log/mail.log | tail -n 5
Jan 03 09:12:44 mx postfix/smtp[22184]: 8A3C73C2F: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.140.27]:25, delay=12, delays=0.2/0.1/9.6/2.1, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[74.125.140.27] said: 421-4.7.0 Try again later, closing connection. (in reply to end of DATA command))

Sens : L’aval vous throttle (421 4.7.0). Ce n’est pas résolu en augmentant vos limites d’acceptation entrante. C’est résolu en lissant la sortie et en réduisant le volume suspect.

Décision : Implémentez le shaping par destination et vérifiez que vous n’êtes pas la source de spam ou d’ouragans de rebonds.

Tâche 6 : Identifier les principaux utilisateurs SASL envoyeurs (qui génère le volume)

cr0x@server:~$ grep "sasl_username=" /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  842 sales.bot@example.com
  113 j.smith@example.com
   77 alerts@example.com

Sens : Une identité domine. Cela peut être une automatisation légitime ou une compromission.

Décision : Si inattendu : désactivez les identifiants, forcez la réinitialisation et ajoutez des limites par utilisateur via une politique. Si attendu : déplacez-le vers un relais/transport dédié.

Tâche 7 : Identifier les principales IP clientes sur le SMTP entrant (qui se connecte)

cr0x@server:~$ grep "connect from" /var/log/mail.log | awk '{print $NF}' | sed 's/[][]//g' | sort | uniq -c | sort -nr | head
  502 203.0.113.44
  311 198.51.100.77
  148 192.0.2.10

Sens : Quelques IP vous martèlent. Si ce sont des réseaux inconnus, vous subissez du trafic bot/abus ou des relais en amont mal configurés.

Décision : Utilisez postscreen/limites anvil ou du rate limiting côté pare-feu ; ne whitelistez que si vous pouvez prouver la légitimité.

Tâche 8 : Vérifier si les clients sont limités par Postfix

cr0x@server:~$ grep -E "too many (connections|commands|messages)|rate limit" /var/log/mail.log | tail -n 8
Jan 03 09:10:02 mx postfix/smtpd[21901]: warning: too many connections from 203.0.113.44
Jan 03 09:10:03 mx postfix/smtpd[21902]: warning: 203.0.113.44: SMTP command rate limit exceeded

Sens : Votre serveur bride activement. Cela peut être correct (bots) ou incorrect (bureau NATé, load balancer, système de supervision).

Décision : Si c’est un envoi en amont légitime, créez une exception contrôlée. Sinon, serrez et ajoutez postscreen.

Tâche 9 : Valider l’état de postscreen (si activé)

cr0x@server:~$ systemctl status postfix@postscreen --no-pager
● postfix@postscreen.service - Postfix postscreen
     Loaded: loaded (/lib/systemd/system/postfix@.service; enabled)
     Active: active (running) since Fri 2026-01-02 08:14:03 UTC; 1 day ago

Sens : postscreen fonctionne. Si vous avez des symptômes d’inondation entrante et que postscreen est arrêté, vous payez le coût SMTP complet pour chaque bot.

Décision : Si non actif, corrigez l’activation dans master.cf et vérifiez que le port 25 est bien routé vers postscreen comme prévu.

Tâche 10 : Inspecter les limites de concurrence actuelles pour la livraison

cr0x@server:~$ postconf | egrep 'default_process_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_destination_recipient_limit'
default_process_limit = 100
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_destination_recipient_limit = 50

Sens : Vous pouvez subir les throttles des gros fournisseurs parce que vous livrez trop agressivement (rate_delay=0s) ou de façon trop concurrente.

Décision : Si vous voyez des 421 de domaines, ajoutez un rate delay et baissez la concurrence pour cette destination via des transport maps.

Tâche 11 : Détecter la pression CPU due au TLS (un limiteur caché fréquent)

cr0x@server:~$ top -b -n 1 | head -n 12
top - 09:13:01 up 12 days,  2:41,  1 user,  load average: 7.82, 6.90, 5.11
Tasks: 212 total,   3 running, 209 sleeping,   0 stopped,   0 zombie
%Cpu(s): 78.2 us,  3.1 sy,  0.0 ni, 18.3 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st

Sens : CPU élevé avec faible IO wait suggère un travail CPU-bound (handshakes TLS, filtres de contenu, appels de politique). La limitation au niveau SMTP peut être votre soulagement le moins coûteux.

Décision : Activez postscreen et réduisez le travail cher pour les clients inconnus ; envisagez le réemploi de sessions TLS et des choix de chiffrements raisonnables plus tard.

Tâche 12 : Confirmer que vous ne vous bloquez pas vous-même avec des timeouts trop bas

cr0x@server:~$ postconf | egrep 'smtpd_.*timeout|smtp_.*timeout'
smtpd_timeout = 60s
smtpd_helo_timeout = 30s
smtpd_client_connection_timeout = 10s
smtp_connect_timeout = 30s
smtp_data_done_timeout = 600s

Sens : Des timeouts agressifs côté serveur peuvent tuer des expéditeurs lents mais légitimes (surtout sur des liaisons à haute latence).

Décision : Si vous voyez beaucoup de «lost connection after CONNECT/HELO» de partenaires légitimes, augmentez modestement les timeouts et comptez sur les limites de concurrence plutôt.

Tâche 13 : Vérifier les appels au service de politique (et leur latence) dans les logs

cr0x@server:~$ grep -E "check_policy_service|policy.*timeout|policyd" /var/log/mail.log | tail -n 6
Jan 03 09:11:22 mx postfix/smtpd[22010]: warning: problem talking to server 127.0.0.1:10031: Connection timed out
Jan 03 09:11:22 mx postfix/smtpd[22010]: NOQUEUE: reject: RCPT from mail.example.net[192.0.2.10]: 451 4.3.0 <127.0.0.1:10031>: Temporary lookup failure; from=<a@b> to=<c@d> proto=ESMTP helo=<mail.example.net>

Sens : Votre démon de politique est le goulot ; Postfix diffère parce qu’il ne peut obtenir de décision.

Décision : Corrigez les performances/la disponibilité du démon de politique ou bypassez-le temporairement pour les flux critiques. Ne «réglez» pas cela en augmentant les limites de processus smtpd ; vous ne ferez que créer un plus gros entassement.

Tâche 14 : Confirmer la séparation des services dans master.cf (submission vs smtp)

cr0x@server:~$ postconf -Mf | egrep '^(smtp|submission|smtps)'
smtp/inet=smtp inet n - y - - smtpd
submission/inet=submission inet n - y - - smtpd
smtps/inet=smtps inet n - y - - smtpd

Sens : Les services existent. Mais la séparation concerne les options par service, pas seulement l’ouverture des ports.

Décision : Appliquez des exigences d’authentification plus strictes et des limites par utilisateur sur submission, et renforcez postscreen/anti-abus sur le smtp entrant.

Trois mini-récits d’entreprise tirés du terrain

Incident n°1 : La mauvaise hypothèse (le NAT = «un utilisateur»)

Une entreprise de taille moyenne exécutait Postfix pour les mails sortants des employés et le MX entrant sur la même VM. Ils venaient de déménager et, comme souvent, l’équipe réseau a mis en place un NAT «temporaire» devenu permanent. Des centaines d’utilisateurs partageaient désormais une IP publique pour la submission.

L’administrateur mail a remarqué une légère augmentation des tentatives de spam sortant (réelles, mais pas massives). Ils ont réagi vite : ont défini smtpd_client_message_rate_limit et smtpd_client_connection_rate_limit sur le service de submission. Les chiffres semblaient généreux—si on imagine une personne par IP.

À 09:00 le lendemain, le helpdesk a explosé. Les clients Outlook montraient des échecs intermittents d’envoi. Les mobiles subissaient des retards. L’assistante du PDG a découvert que «réessayer plus tard» n’est pas un message satisfaisant pour réserver un vol.

Les logs étaient clairs : «too many connections from [office public IP]». Le système n’était pas attaqué. Il était utilisé normalement, mais le limiteur regardait la mauvaise dimension. Ils avaient supposé IP == utilisateur ; le réseau a prouvé le contraire.

La correction n’a pas été «augmenter la limite jusqu’à ce que les plaintes cessent». Ils ont déplacé les contrôles de submission vers l’identité SASL via un service de politique et ajouté un petit plafond de concurrence par IP comme filet de sécurité. L’abus a été contenu et les vrais utilisateurs n’ont plus marché sur les pieds les uns des autres.

Incident n°2 : L’optimisation qui s’est retournée contre eux (plus de concurrence, plus de throttling)

Un fournisseur SaaS envoyait des mails transactionnels—réinitialisations, reçus, alertes—via Postfix. La délivrabilité comptait. Quelqu’un a remarqué que la file sortante s’accumulait parfois aux heures de pointe, et a fait un mouvement classique d’optimisation : augmenter default_process_limit et la concurrence par destination pour que la livraison «aille plus vite».

Ça a effectivement accéléré—pendant environ une heure. Puis la file différée a commencé à se remplir de 421 en provenance d’un grand fournisseur de boîtes mail. Le fournisseur ne réagissait pas au volume quotidien ; il réagissait à la rafale et à la churn des connexions. Plus de concurrence ressemblait à un comportement agressif.

Les tickets support ont suivi : «Je ne reçois pas mon e-mail de réinitialisation.» L’ingénierie, sous pression, a augmenté encore la concurrence. Cela a incité le fournisseur à restreindre encore plus. C’est l’équivalent mail d’appuyer plusieurs fois sur le bouton d’ascenseur.

La solution a été de faire la chose ennuyeuse : réduire la concurrence par destination, introduire un petit smtp_destination_rate_delay pour le domaine affecté, et garder les mails transactionnels dans un transport prioritaire. La file s’est stabilisée et le fournisseur a arrêté de claquer la porte.

La leçon : la vitesse de livraison n’est pas seulement votre débit. C’est aussi la perception que les récepteurs ont de votre comportement. Limiter la sortie est parfois le moyen le plus rapide de livrer.

Incident n°3 : La pratique ennuyeuse et correcte qui a sauvé la situation (voies séparées)

Une société de services financiers avait appris que «un Postfix pour tout» devient un domaine de défaillance unique. Ils faisaient tourner des instances Postfix séparées : une pour le MX entrant, une pour la submission authentifiée, et une pour les relais d’applications internes. Même hôtes, ports différents, politiques différentes, files séparées.

Un vendredi soir, une application legacy est devenue folle après un déploiement. Elle a commencé à générer un volume élevé de notifications à cause d’une boucle. Pas malveillant, juste erroné. Elle a touché l’instance de relais interne en premier.

Les limites sur cette voie étaient strictes : plafonds par expéditeur et par identifiants d’app étaient en place, et les allowances de rafale étaient petites. L’instance relais a différé l’excès et gardé sa file sous contrôle. L’envoi de l’application a ralenti, des alertes ont déclenché et l’astreinte a trouvé le bug.

Pendant ce temps, la soumission des employés fonctionnait, et le MX entrant acceptait le courrier. Aucun incident visible par les clients. Pas de décision d’urgence «tout couper». Le système a dégradé au bon endroit.

C’est ce à quoi ressemble une bonne ingénierie : ni héroïque, ni futée, juste conçue pour contenir les pannes. Vous pouvez appeler cela du «sur-ingénierie» jusqu’à ce que ça vous sauve le weekend.

Erreurs courantes : symptômes → cause fondamentale → correctif

1) Symptom : «Trop de connexions» depuis une IP, et c’est votre bureau

Cause fondamentale : Vous avez appliqué des limites anvil par IP à une population NATée (trafic de submission).

Correctif : Limitez par utilisateur SASL via un service de politique ; gardez un cap par IP léger pour stopper les vraies inondations.

2) Symptom : Des partenaires se plaignent de connexions abandonnées

Cause fondamentale : Timeouts trop agressifs ou tests postscreen qui échouent pour des MTAs légitimes (systèmes anciens, haute latence).

Correctif : Augmentez modestement les timeouts ; ajoutez en whitelist les partenaires connus dans les tables d’accès postscreen ; gardez la sévérité pour les inconnus.

3) Symptom : La file grossit, surtout différés avec 421/4.7.x des gros fournisseurs

Cause fondamentale : Vous êtes throttlé ; vous livrez en rafales, ou votre réputation est en suspicion.

Correctif : Baissez la concurrence par destination, ajoutez un rate delay, et vérifiez les sources sortantes (comptes compromis, tempêtes de rebonds).

4) Symptom : CPU qui grimpe pendant des vagues de spam, même si vous rejetez après

Cause fondamentale : Travail coûteux (TLS, politique, filtres de contenu) qui s’exécute avant que vous ne supprimiez le junk.

Correctif : Utilisez postscreen pour filtrer plus tôt ; réduisez les contrôles coûteux avant l’authentification ; mettez en cache ou durcissez les services de politique.

5) Symptom : Les envois massifs légitimes échouent (newsletters, factures)

Cause fondamentale : Vous avez utilisé des limites globales de destinataires/messages sans voies dédiées.

Correctif : Créez une identité/transport de submission séparée avec limites explicites et supervision ; ne montez pas les limites globales.

6) Symptom : Les utilisateurs voient des 451/4.3.0 intermittents (échecs temporaires)

Cause fondamentale : Timeouts du démon de politique ou backend de base de données surchargé.

Correctif : Rendez le service de politique hautement disponible et rapide ; implémentez des timeouts sensés et définissez le mode fail-open/closed intentionnellement par service.

7) Symptom : La livraison est lente même avec une file faible

Cause fondamentale : Vous limitez trop la concurrence globalement (default_process_limit trop bas), ou une destination consomme des slots.

Correctif : Équilibrez les limites de processus et les limites par destination ; isolez les destinations problématiques via des transports.

8) Symptom : Après ajout de limitations, vous avez plus de plaintes pour spam

Cause fondamentale : Vous avez différé trop mollement pour des comptes compromis, laissant du spam s’étaler dans le temps.

Correctif : Pour la submission authentifiée, appliquez des caps durs par utilisateur plus de l’alerte et des workflows d’auto-verrouillage.

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

Étapes : implémenter des limites sortantes sûres pour la submission

1. Séparer la politique du service de submission dans master.cf (submission sur le port 587) avec auth et TLS obligatoires.
2. Définir des plafonds de destinataires pour la submission (protéger contre les «un email à mille»).
3. Mettre en place des limites par SASL via un démon de politique (recommandé) ou à défaut utiliser anvil prudemment.
4. Définir des voies d’exception pour les comptes d’automatisation connus (alerts, facturation) avec des limites supérieures explicites.
5. Instrumenter les logs : extraire les principaux utilisateurs SASL, principales adresses expéditrices et comptes de rejets/différés.
6. Alerter sur les anomalies : pics soudains par utilisateur, croissance rapide de la file différée, échecs d’auth répétés.
7. Effectuer un test contrôlé : un utilisateur normal, un compte d’automatisation, et un expéditeur synthétique abusif en staging si possible.

Étapes : durcir le MX entrant sans bloquer les expéditeurs réels

1. Activer postscreen si le volume entrant le justifie.
2. Appliquer des limites de concurrence modérées par client pour empêcher qu’un hôte n’accapare les workers smtpd.
3. Utiliser des contrôles de protocole sensés : limiter les destinataires, exiger un HELO correct si approprié, et rejeter la poubelle évidente tôt.
4. Privilégier les échecs temporaires pour les rafales suspectes, surtout pour les clients inconnus.
5. Maintenir une petite whitelist pour les partenaires connus ayant des bizarreries légitimes, mais révisez-la chaque trimestre.
6. Revoir les timeouts pour ne pas pénaliser les MTAs légitimes à haute latence.

Étapes : façonner la livraison sortante pour éviter les throttles des récepteurs

1. Mesurer les différés par domaine (gmail, outlook, yahoo, partenaires corporate).
2. Créer des transports par domaine pour les récepteurs problématiques.
3. Baisser la concurrence et ajouter un rate delay là où vous voyez des 421/4.7.x.
4. Prioriser le trafic transactionnel via une file/transport séparé si possible.
5. Arrêter l’hémorragie d’abord : si des utilisateurs compromis existent, les désactiver est plus efficace que «tuner autour» du spam.

FAQ

1) Dois-je limiter d’abord l’entrée ou la sortie ?

Si vous exécutez une submission authentifiée, commencez par des limites sortantes par utilisateur. Les comptes compromis ont un fort impact et détruisent la réputation. Les inondations entrantes sont réelles aussi, mais elles sont généralement plus faciles à mitiger avec postscreen et des limites de connexion.

2) Quelle est la différence entre limites de connexion et limites de débit de messages ?

Les limites de connexion restreignent combien de sessions un client peut tenir ou ouvrir par unité de temps. Les limites de débit de messages restreignent combien de messages le client peut soumettre. Les bots peuvent être efficaces : peu de connexions, beaucoup de messages. Vous aurez généralement besoin des deux, mais appliquez-les là où ils correspondent à votre modèle de menace.

3) La limitation doit-elle rejeter (5xx) ou différer (4xx) ?

Pour la plupart des limitations : différer (4xx). Cela ralentit l’abus tout en préservant la délivrabilité pour les expéditeurs légitimes. Utilisez le rejet pour les violations de politique (open relay, destinataires invalides si vous rejetez à RCPT, etc.).

4) Pourquoi mes utilisateurs sont bloqués quand une IP dépasse la limite ?

Le NAT. Hôtels, bureaux, réseaux mobiles et certains VPN concentrent beaucoup d’utilisateurs derrière une même IP. Ne traitez pas l’IP comme une identité pour la submission. Limitez par nom d’utilisateur SASL ou par expéditeur.

5) Puis-je résoudre le throttling de Gmail/Microsoft en augmentant la concurrence Postfix ?

Non. Cela aggrave généralement la situation. Quand un récepteur vous throttle, vous devez livrer plus poliment : baisser la concurrence, ajouter des délais et réduire le volume suspect.

6) Est-il sûr d’activer postscreen sur un MX en production ?

Oui, si vous testez et surveillez. Le risque est des faux positifs avec des expéditeurs inhabituels. Commencez par des réglages conservateurs et maintenez une petite whitelist pour les partenaires importants. Ne whitelistez pas l’internet entier parce qu’un MTA fournisseur est bizarre.

7) Comment limiter par boîte aux lettres sans démon de politique ?

Postfix pur est plus fort pour les limites par client/IP via anvil. Le par‑utilisateur exige de la logique de politique. Sans cela, vous pouvez approximativement utiliser des services de submission séparés (ports différents) et des restrictions clients authentifiés, mais c’est maladroit. Si vous avez besoin de limites par utilisateur, utilisez un service de politique.

8) Quelles métriques importent le plus pour régler les limitations ?

Taille de la file (active vs différée), raisons de différé (surtout 421/4.7.x), principaux utilisateurs SASL par volume, principales IP clientes, et occurrences de hits de rate-limit dans les logs. Suivez aussi les tendances de plaintes/rebonds—les dommages à la réputation apparaissent d’abord là.

9) Comment éviter de casser les envois massifs légitimes ?

Donnez aux expéditeurs massifs une voie séparée avec limites explicites et supervision. Ne montez pas les limites globales «pour eux». Les limites globales sont pour l’internet ; les voies sont pour les exceptions métier.

Conclusion : que faire ensuite

Si vous voulez une limitation de débit qui arrête les abus sans bloquer les véritables utilisateurs, procédez dans cet ordre :

1. Mesurez : trouvez les principaux émetteurs (IP, utilisateur SASL, expéditeur) et lisez les raisons de différé/rejet.
2. Séparez les voies : MX entrant, submission authentifiée et relais d’applications ne doivent pas partager le même seau de politique.
3. Implémentez des limites conscientes de l’identité : plafonds par utilisateur pour la submission ; caps par IP pour l’entrée ; shaping par destination pour la livraison.
4. Privilégiez le defer en cas d’excès de taux, et réservez les rejets aux violations réelles de politique.
5. Documentez vos exceptions et révisez-les. Toute exception permanente commence comme «temporaire».

La plupart des incidents mail ne sont pas causés par un attaquant sophistiqué. Ils sont causés par des systèmes normaux qui se comportent à une échelle anormale, plus quelques mauvaises hypothèses. La limitation de débit est la manière de rendre l’anormal survivable.