E-mail : Déferlante de spam entrants — survivre à l’attaque sans bloquer les vrais utilisateurs

Ce contre quoi vous luttez (et ce que ce n’est pas)

Une déferlante de spam entrant n’est pas « quelqu’un nous a envoyé des spams ». C’est un problème de débit et d’équité qui arrive via SMTP.
L’attaquant (ou l’expéditeur en vrac mal configuré, ou un botnet compromis) n’a pas besoin d’être astucieux. Il doit juste être suffisamment nombreux et persistant pour faire trébucher votre pipeline mail.

Les modes de défaillance qui vous mettent réellement à terre

• Explosion de la file : votre MTA accepte les messages plus vite qu’il ne peut les traiter (filtrage, requêtes DNS, livraison), la file grossit jusqu’à atteindre la pression disque ou inode.
• Effondrement CPU : le filtrage de contenu (AV, score anti-spam, décompression) devient votre chemin le plus chaud. Un mauvais type de pièce-jointe peut se transformer en bombe de forks de travail.
• Amplification de latence DNS : chaque vérification SPF/DKIM/DMARC et chaque lookup RBL devient un multiplicateur sur les connexions entrantes. Résolveur lent = tout lent.
• Épuisement de la table de connexions : trop de sessions SMTP simultanées ; votre noyau et votre MTA commencent à laisser tomber des connexions légitimes.
• Backscatter et retries : si vous acceptez puis rejetez plus tard, vous générez des bounces ou forcez des retries ; vous devenez partie du problème et votre file reste chaude pendant des heures.
• Faux positifs : le « correctif » bloque des clients, des systèmes partenaires et des réinitialisations de mot de passe. C’est ainsi que les incidents deviennent des escalades auprès de la direction.

L’astuce est de rendre votre système « peu coûteux pour dire non », et « prévisible pour dire oui ». Rejetez tôt pendant le dialogue SMTP,
et réservez l’analyse coûteuse du contenu au courrier qui a de fortes chances d’être légitime.

Une citation à coller sur votre écran : L’espoir n’est pas une stratégie. — Gene Kranz.
Les inondations d’e-mails sont l’endroit où « on va juste surveiller » va mourir.

Blague n°1 : L’e-mail est le seul protocole où « Veuillez réessayer plus tard » est un workflow métier légitime.

Faits intéressants et un peu d’histoire

Les inondations de spam semblent modernes, mais l’écosystème évolue depuis des décennies. Voici des points concrets qui influencent les défenses actuelles :

1. SMTP a été conçu avant le spam : le modèle original supposait des hôtes coopératifs, ce qui explique pourquoi tant de contrôles sont des greffes plutôt que natifs.
2. Les relais ouverts furent un vecteur majeur : l’abus de relais dans les années 1990 a poussé les MTAs à verrouiller le relaying par défaut.
3. Les DNSBL/RBL sont devenus populaires car ils étaient peu coûteux : une requête DNS pouvait remplacer un scan de contenu onéreux pour des sources manifestement mauvaises.
4. Le greylisting est apparu comme arme économique : retarder la première tentative et beaucoup de bots spammeurs n’effectuent pas correctement de retry, alors que les vrais MTAs le font.
5. SPF a été conçu pour arrêter le spoofing de l’enveloppe-from : utile, mais ça ne prouve pas l’expéditeur humain ; ça prouve l’autorisation de domaine pour ce chemin.
6. DKIM a rendu l’authentification des messages évolutive : signer le contenu dans les en-têtes permet aux récepteurs de vérifier l’intégrité sans secrets partagés.
7. DMARC a ajouté une politique et du reporting : c’est une couche d’application et de visibilité, pas un bouton magique « plus de spam ».
8. Les botnets ont modifié les profils de volume : au lieu de quelques sources géantes, vous avez beaucoup de sources à faible volume qui contournent les seuils simples par IP.
9. L’analyse du contenu s’est alourdie avec le temps : le spam moderne utilise des archives imbriquées, des encodages étranges et des pièges « document » coûteux à dépaqueter.

Guide de diagnostic rapide

Quand l’inondation frappe, vous n’avez pas le temps de débattre d’architecture. Il faut trouver le goulot en quelques minutes.
Cette séquence est biaisée vers les MTA Linux (Postfix, Exim) avec des piles de filtrage communes, mais la démarche s’applique aussi à Exchange et aux passerelles hébergées.

Première question : rejetons-nous tôt, ou acceptons-nous puis nous noyons-nous ensuite ?

• Vérifiez les taux de sessions SMTP entrantes et les connexions concurrentes.
• Vérifiez si la croissance de la file est entrante, active, différée ou en hold.
• Vérifiez le ratio d’acceptations 2xx vs rejets 4xx/5xx.

Deuxième question : quelle ressource est saturée maintenant ?

• CPU : travailleurs spam/AV à fond, charge en hausse, switching de contexte élevé.
• Disque : répertoire de file sur stockage lent ; iowait en pic ; épuisement d’inodes.
• DNS : latence du résolveur ; beaucoup de DNS sortants ; timeouts qui causent des blocages SMTP.
• Réseau : backlog SYN ; épuisement conntrack ; limites en amont.

Troisième question : quel levier le moins coûteux vous donne du temps sans bloquer de vrais utilisateurs ?

• Augmentez la friction pour les expéditeurs abusifs (limites de connexion, tarpit, postscreen, greylisting).
• Réduisez le coût de traitement (bypasser les scans coûteux pour l’évidence, mettre en cache le DNS, préférer les vérifs RBL).
• Protégez les flux critiques (listes blanches pour partenaires connus ; MX ou port/IP séparés pour le courrier transactionnel).

L’état d’esprit de réponse à l’inondation : stabiliser, puis améliorer. Ne « refactorez pas votre système de mail » en plein incident, à moins d’aimer les tickets de changement qui ressemblent à des scènes de crime.

Douze tâches pratiques : commandes, sorties et la décision que vous prenez

L’objectif ici n’est pas d’exhiber des commandes. C’est de vous rendre rapide : lancez une commande, interprétez le résultat, choisissez l’action suivante.
Les exemples supposent une passerelle mail Linux avec Postfix et des outils communs ; adaptez les chemins selon votre distro.

Task 1: Measure queue size and shape (Postfix)

cr0x@server:~$ mailq | tail -n 5
-- 12437 Kbytes in 1832 Requests.

Ce que ça signifie : Vous avez 1 832 messages en file ; la taille est modérée mais le nombre est la vraie douleur opérationnelle (coût de traitement par message).

Décision : Si le nombre augmente rapidement, priorisez le rejet précoce et le throttling avant d’essayer de « traiter tout ça ».

Task 2: Identify top sending IPs hitting your SMTP service

cr0x@server:~$ sudo ss -tn sport = :25 | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  312 203.0.113.55
  287 198.51.100.22
  190 192.0.2.77

Ce que ça signifie : Quelques IP monopolisent les sessions. Ce peuvent être des bots ou un expéditeur en vrac défaillant.

Décision : Appliquez des limites de connexion par client ou des blocs temporaires pour les pires contrevenants après vérification des partenaires légitimes.

Task 3: Spot whether you’re spending time on DNS lookups

cr0x@server:~$ sudo journalctl -u systemd-resolved --since "10 min ago" | tail -n 6
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49231 for 55.113.0.203.zen.spamhaus.org. IN A timed out
Jan 04 10:11:20 mx1 systemd-resolved[642]: Transaction 49232 for 22.100.51.198.zen.spamhaus.org. IN A timed out

Ce que ça signifie : Les lookups RBL time-outent. Votre MTA va se bloquer, les sessions restent ouvertes, la concurrence augmente, la file grossit.

Décision : Réparez la performance du résolveur maintenant : résolveur cache local, timeouts plus courts, moins de contrôles coûteux en parallèle durant le pic.

Task 4: Check CPU and iowait (is it compute or disk?)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.14    0.00    9.83   34.76    0.00   27.27

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  %util
nvme0n1         12.0   420.0    96.0  8120.0    8.40   98.0

Ce que ça signifie : Iowait élevé et utilisation disque importante. L’E/S de la file est votre facteur limitant.

Décision : Réduisez le churn de la file (rejeter plus tôt, ralentir les acceptations), et envisagez de déplacer la file sur un stockage plus rapide si vous pouvez le faire en sécurité.

Task 5: Verify inode pressure (queue directories can die by inodes)

cr0x@server:~$ df -ih /var/spool/postfix
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        2.0M  1.9M  120K   95% /

Ce que ça signifie : Vous êtes proche de l’épuisement des inodes. Même avec de l’espace libre, vous ne pouvez pas créer de nouveaux fichiers. Les MTAs détestent ça.

Décision : Nettoyage d’urgence : purgez soigneusement le spam évident dans la file, augmentez la capacité d’inodes à plus long terme, et réduisez le taux d’acceptation maintenant.

Task 6: Find which queue state is exploding (Postfix queue IDs)

cr0x@server:~$ sudo qshape deferred | head
T  5 10 20 40 80 160 320 640 1280 2560 5120 10240 20480 40960
5  0  2  3  6 15  44  98 210  380  390  230    54     0     0

Ce que ça signifie : La file deferred grossit : échecs de livraison distants, greylisting ailleurs, ou votre chemin sortant est encombré.

Décision : Séparez la survie de l’inbound de la livraison sortante : envisagez de limiter le taux des retries sortants, et assurez-vous que le rejet inbound se produit avant la mise en file.

Task 7: Check Postfix process pressure

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_connection_count_limit|default_process_limit|smtpd_client_message_rate_limit'
default_process_limit = 200
smtpd_client_connection_count_limit = 20
smtpd_client_message_rate_limit = 100

Ce que ça signifie : Vous autorisez 20 connexions concurrentes par client et 100 msgs/min par client ; la limite globale de processus est 200.

Décision : Pendant une inondation, baissez la concurrence par client (les bots profitent du parallélisme). N’augmentez la limite globale que si CPU/disque le permettent ; sinon vous amplifiez la panne.

Task 8: Quickly quantify rejects vs accepts from logs

cr0x@server:~$ sudo awk '{print $6}' /var/log/mail.log | grep -E 'reject:|status=sent|status=deferred' | head
reject:
status=sent
status=deferred

Ce que ça signifie : Échantillonnage grossier. Vous avez besoin des proportions.

Décision : Si les rejets sont faibles alors que la file augmente, vous êtes trop permissif au moment SMTP. Ajoutez des rejets peu coûteux (RBL, postscreen, HELO strict) et réduisez les scans coûteux.

Task 9: Extract top recipients being targeted (protect them)

cr0x@server:~$ sudo grep -h "to=<" /var/log/mail.log | sed -n 's/.*to=<\([^>]*\)>.*/\1/p' | cut -d, -f1 | sort | uniq -c | sort -nr | head
  842 info@
  731 sales@
  690 support@

Ce que ça signifie : Les boîtes génériques se font pilonner.

Décision : Appliquez des contrôles basés sur le destinataire : filtrage plus strict pour les adresses génériques, MX séparé pour les alias publics, ou exiger un captcha/portail pour certains destinataires (décision métier).

Task 10: Check TLS handshake cost and failures (spam loves expensive handshakes)

cr0x@server:~$ sudo grep -h "TLS" /var/log/mail.log | tail -n 5
Jan 04 10:12:01 mx1 postfix/smtpd[23102]: TLS handshake failed: SSL_accept error from 203.0.113.55: -1
Jan 04 10:12:02 mx1 postfix/smtpd[23108]: Anonymous TLS connection established from 198.51.100.22: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384

Ce que ça signifie : Les échecs de handshake peuvent consommer du CPU ; TLS réussi c’est bien, mais des politiques TLS lourdes peuvent être abusées par des spammeurs qui ont du CPU.

Décision : Gardez TLS activé, mais ajoutez postscreen/contrôles de connexion pour ne pas gaspiller des cycles crypto sur les trafics manifestement indésirables.

Task 11: Validate that your resolver cache is working

cr0x@server:~$ resolvectl statistics | head -n 12
Transactions:           98422
Cache Hits:             61210
Cache Misses:           37212
DNSSEC Verdicts Secure: 0

Ce que ça signifie : Un taux de cache élevé vous donne de la marge. Si les hits sont faibles, vous refaites des lookups coûteux en boucle.

Décision : Assurez-vous d’un cache local, ajustez le respect des TTL, et évitez les vérifications DNS par message que vous pouvez reporter ou mettre en cache dans des services de politique.

Task 12: Check ClamAV or content scanner backlog (example)

cr0x@server:~$ systemctl status clamav-daemon --no-pager | sed -n '1,12p'
● clamav-daemon.service - Clam AntiVirus userspace daemon
     Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled)
     Active: active (running) since Thu 2026-01-04 09:41:22 UTC; 30min ago
     Docs: man:clamd(8)
   Main PID: 1432 (clamd)
      Tasks: 42 (limit: 18956)
     Memory: 1.1G
        CPU: 18min 10.221s

Ce que ça signifie : Le scanner est vivant, consomme du CPU, avec beaucoup de tâches. Ça ne prouve pas le débit.

Décision : Si le scanner devient le goulot, passez temporairement à « refuser par réputation + contrôles basiques » et réservez le scan profond aux sources autorisées ou expéditeurs authentifiés.

Task 13: See if the kernel is dropping connections

cr0x@server:~$ netstat -s | egrep -i 'listen|overflow|drops' | head
    2489 times the listen queue of a socket overflowed
    2489 SYNs to LISTEN sockets dropped

Ce que ça signifie : Vous perdez des sessions avant même que Postfix les voie. Les expéditeurs légitimes retenteront, mais vous ajoutez du chaos.

Décision : Augmentez le backlog et ajustez les limites du noyau, mais seulement après avoir appliqué des throttles côté MTA ; sinon vous acceptez juste plus de douleur.

Task 14: Sample message headers from queued mail (don’t guess)

cr0x@server:~$ sudo postcat -q 3F2A1C2B9E | sed -n '1,25p'
*** ENVELOPE RECORDS active ***
message_size: 28412              452             1               0               28412
sender: spammer@example.net
*** MESSAGE CONTENTS ***
Received: from unknown (HELO user) (203.0.113.55)
Subject: Invoice attached

Ce que ça signifie : Vous pouvez repérer des motifs : HELO incorrect, sujets suspects, sources répétées.

Décision : Transformez ces motifs en règles SMTP peu coûteuses (restrictions HELO, postscreen, RBL), pas en filtrage lourd après acceptation.

Blague n°2 : Le filtre anti-spam le plus rapide est une réponse 554. C’est aussi le seul qui n’a jamais besoin d’une mise à jour de signature.

Contrôler le rayon d’impact : points d’étranglement importants

Dans une inondation, vous ne « luttez pas contre le spam ». Vous contrôlez la consommation de ressources. Votre MTA est fondamentalement une chaîne de production :
accepter connexion → négocier → recevoir le message → exécuter des vérifications → mettre en file → livrer → retenter si nécessaire.
Toute étape lente devient un embouteillage derrière elle.

1) Gestion des connexions : réduire les conversations coûteuses

La défense la plus sous-estimée est de rendre les connexions SMTP entrantes ennuyeuses et peu coûteuses. La plupart des déferlantes de spam reposent sur le fait que vous faites le travail :
handshakes TLS, délais de bannière, lookups de politique, filtres de contenu. Votre rôle est de faire moins par expéditeur indésirable.

• Limites de concurrence par client : les bots aiment les sessions parallèles. Les vrais MTAs se comportent typiquement.
• Limitation du taux de connexion : limitez les nouvelles connexions par fenêtre temporelle par IP/sous-réseau.
• Postscreen (Postfix) : éloignez le démon SMTP des ordures évidentes jusqu’à ce que le client prouve une compétence basique.
• Tarpitting : ajoutez un petit délai pour les clients suspects. Pas trop long — des minutes, c’est s’infliger du mal.

2) Rejet au moment SMTP : n’acceptez jamais ce que vous savez déjà que vous allez rejeter

Si vous acceptez un message puis le rejetez ensuite, vous avez déjà payé le coût : I/O disque, entrées de file, temps de scan,
et souvent une tempête de retries. Rejetez lors du connect/helo/mail-from/rcpt-to quand c’est possible.

• Bloquez les patterns HELO/EHLO invalides : « HELO user » depuis une IP publique est rarement un serveur mail sérieux.
• Exigez un envelope sender sensé lorsque c’est approprié.
• Utilisez les RBL avec précaution : une liste solide vaut mieux que cinq instables qui time-outent.
• Validation des destinataires : rejetez les destinataires inconnus au moment SMTP pour éviter le backscatter et la croissance de la file.

3) Équité pour les vrais utilisateurs : protégez les expéditeurs et destinataires critiques

« Ne bloquez pas les vrais utilisateurs » n’est pas sentimental ; c’est opérationnel. Vos meilleurs clients déclencheront les mêmes contrôles que le spam si vous les réglez brutalement.
La solution est la segmentation et des exceptions explicites.

• Listes blanches partenaires au niveau passerelle (plages IP, sources authentifiées, ou domaines connus avec infrastructure stable).
• MX entrant séparé : un MX public qui absorbe les ordures et un canal protégé pour le trafic transactionnel/partenaire.
• Politiques différentes par destinataire : les cadres et les adresses de réinitialisation de mot de passe méritent faible latence et plus de confiance.

Stratégie de filtrage pendant une inondation : prioriser le flux plutôt que la perfection

L’analyse de contenu est l’endroit où les bonnes intentions atteignent 100 % CPU. En temps normal, vous pouvez dézipper des pièces jointes,
exécuter l’AV, faire du fuzzy hashing et calculer des scores anti-spam élaborés. Pendant une inondation, chaque milliseconde supplémentaire devient un multiplicateur.

Réputation d’abord, contenu ensuite

Commencez par des signaux peu coûteux qui coupent tôt :

• Réputation IP et sanity protocolaire basique : postscreen, RBL, pipelining de commandes invalide, trop d’erreurs.
• Politique d’enveloppe : rejetez les destinataires inexistants ; limitez les destinataires par message ; bloquez les domaines locaux évidents usurpés.
• Vérifications d’authentification : les résultats SPF/DMARC peuvent servir au scoring ou au rejet pour les domaines à haut risque, mais attention à la dépendance DNS.

Quand utiliser le greylisting (et quand c’est un piège)

Le greylisting peut sauver la mise lors d’une inondation soudaine : il transforme votre serveur en machine « réessayez plus tard », et beaucoup de spamware abandonnent.
Mais il retarde aussi les expéditeurs légitimes de première fois, ce qui est pénible si vous intégrez de nouveaux clients ou recevez des tickets sensibles au temps.

Un compromis pratique : greylistez seulement sur signaux suspects (pas de reverse DNS, HELO invalide, IP nouvelle avec mauvais comportement),
et exemptez les expéditeurs connus ou partenaires authentifiés.

DMARC/SPF/DKIM pendant la tempête

Ces contrôles aident, mais ne les laissez pas devenir votre goulot :

• SPF : excellent pour éliminer les usurpations d’enveloppe évidentes, mais coûteux en DNS. Mettez en cache les résultats et fixez des timeouts agressifs.
• DKIM : la vérification coûte généralement raisonnablement, mais les signatures cassées sont courantes ; traitez les échecs comme des signaux, pas toujours comme des rejets.
• DMARC : puissant pour les domaines qui publient des politiques strictes. Pour les autres, c’est surtout scoring et reporting.

Différer vs rejeter : choisissez votre douleur

Un échec 4xx temporaire indique aux vrais MTAs de réessayer plus tard. Les spammeurs réessayent aussi, mais beaucoup le font mal. Un rejet 5xx est plus propre et moins coûteux,
mais augmente le risque de bloquer un message réel à cause d’un faux positif.

Pendant une inondation, utilisez des différations ciblées (sources suspectes, expéditeurs inconnus vers destinataires sensibles) et des rejets confiants
(réputation mauvaise connue, destinataires invalides, violations protocolaires). Évitez les diffusions générales qui remplissent juste votre table de connexions.

Files, disques et la partie que les ingénieurs stockage règlent en silence

Les inondations de spam sont souvent diagnostiquées comme un « problème de mail », puis résolues comme un « problème de stockage ». Les répertoires de file sont un enfer de petits fichiers :
milliers de petites écritures, patterns fsync, lookups de répertoires et churn des métadonnées. Votre NVMe dernier cri aide ; votre filesystem réseau surchargé ne le fait pas.

Bases de l’architecture de la file (pourquoi ça fait mal)

La plupart des MTAs stockent chaque message comme plusieurs fichiers (enveloppe, contenu, état différé). Sous forte charge :

• Les opérations sur les répertoires dominent (create, rename, unlink).
• Le surcoût du journal devient visible.
• Les inodes sont consommés rapidement.
• Agents de backup, antivirus en accès à la volée ou outils d’indexation peuvent transformer les répertoires de file en tragédie en temps ralenti.

Mouvements pratiques sur le stockage qui aident pendant les inondations

• Gardez le spool sur un stockage local rapide : pas NFS, pas « ce volume SAN partagé utilisé par tout le monde ». NVMe ou SSD local est le choix correct et ennuyeux.
• Séparez le spool des logs en vrac : évitez la contention avec la rotation ou l’envoi des logs.
• Surveillez l’utilisation des inodes : les alertes basées sur la taille ratent complètement cette panne.
• Minimisez les écritures synchrones quand c’est sûr : attention aux options de montage ; la fiabilité compte, mais vous pouvez souvent ajuster sans tromper le filesystem.
• Ayez des outils de nettoyage de file prêts : vous ne voulez pas écrire un script in situ sous pression.

La gestion de la file est une réponse à incident, pas du ménage

Une file qui grossit n’est pas automatiquement « mauvaise ». C’est un tampon. L’incident survient quand le tampon grandit plus vite que votre capacité de récupération et commence à tout consommer.
Votre objectif est de façonner la file pour que le courrier important soit livré en priorité et que les ordures soient rejetées tôt.

Trois mini-récits d’entreprise issus du terrain

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

Une entreprise SaaS de taille moyenne exploitait une paire de passerelles mail et un système de ticketing séparé. Ils disposaient d’un filtrage correct et croyaient être protégés parce que « nous avons un cloud provider en front ».
La mauvaise hypothèse était que le provider absorberait toute inondation et ne transmettrait que le « vrai e-mail ».

L’inondation est arrivée en mode slow-boil : des milliers de petits messages par minute, principalement vers support@ et info@.
Le provider les a livrés, parce qu’ils étaient techniquement valides SMTP et pas manifestement malveillants.
Les passerelles on‑prem les ont acceptés puis envoyés au scanning de contenu. Les scanners n’ont pas planté ; ils sont juste devenus plus lents. La file a grossi. L’iowait disque a augmenté.

Les vrais e-mails clients ont commencé à expirer. Les réinitialisations de mot de passe (aussi les réponses entrantes et bounces) ont été retardées.
L’astuce du support a été de demander aux clients « d’utiliser le chat ». Le fournisseur de chat les a limités. C’est ainsi que les incidents mail prennent de l’ampleur.

La correction n’a pas été « acheter plus de filtrage ». Il fallait avancer le rejet : validation des destinataires au moment SMTP, limites strictes par client, et un gating de type postscreen.
Ensuite ils ont créé une voie protégée pour le courrier inbound à haute valeur : partenaires et réponses transactionnelles avaient un MX séparé avec des allowlists strictes.

Le postmortem : un edge cloud n’est pas un moteur de politique sauf si vous l’avez configuré pour l’être. Si votre gateway l’accepte, c’est vous qui en êtes propriétaire.

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

Un commerce de détail a tenté d’accélérer le traitement du mail en augmentant le nombre de workers : plus de processus Postfix, plus d’enfants Amavis, plus de concurrence partout.
Ça a bien marché en environnement staging calme, ce qui est une phrase qui devrait toujours vous rendre soupçonneux.

Pendant une vague de spam, « l’optimisation » est devenue un multiplicateur. Avec plus de parallélisme, ils acceptaient plus de messages par seconde et les déversaient immédiatement sur le disque et les scanners.
Les scanners ont saturé le CPU. Le disque a saturé les IOPS. La latence a augmenté, ce qui a gardé les sessions SMTP ouvertes plus longtemps, ce qui a augmenté encore la concurrence.
Le système n’a pas explosé ; il s’est lentement étouffé.

Ils avaient aussi allongé les timeouts DNS « pour être robustes ». En pratique, cela signifiait attendre plus longtemps les réponses RBL lentes,
maintenant les sessions ouvertes et brûlant des processus pendant que le résolveur peinait.

La reprise a impliqué de faire l’inverse de leurs instincts : réduire la concurrence à un niveau que le disque pouvait soutenir, raccourcir les timeouts DNS,
et rejeter plus au niveau des connexions. Le débit a amélioré parce que le système a cessé de thrash.

La leçon : dans les systèmes en pipeline, « plus de parallélisme » n’est pas toujours plus de débit. Si un stade en aval est saturé, la concurrence n’augmente que la taille du problème.

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

Une organisation de services financiers avait la réputation d’être lente à changer et irritante sur les runbooks. Ils faisaient aussi la rotation des on-call comme un rituel sacré.
Ce n’était pas populaire au happy hour, mais ça rendait leur système mail résilient.

Ils avaient trois choses banales en place : (1) répertoire de file sur SSD local dédié avec monitoring des inodes, (2) résolveur cache local avec métriques,
et (3) un « jeu de politiques incident » pré-approuvé pour Postfix activable en quelques minutes : RBLs plus stricts, baisse de la concurrence par client, postscreen plus agressif,
et diffés temporaires pour les sources suspectes.

Quand une inondation a frappé, l’on-call n’a pas improvisé. Ils ont activé la politique d’incident, vu la croissance de la file se stabiliser, puis assoupli sélectivement les règles pour un partenaire
dont le mail était coincé par un contrôle HELO trop agressif. Ce partenaire a obtenu une entrée allowlist avec ticket d’expiration.

L’impact métier s’est limité à des retards pour des boîtes inbound basse priorité. Les dirigeants ne s’en sont jamais aperçus.
Plus tard, l’équipe a revu les logs, trouvé les ASN principaux du botnet, et mis à jour la politique à plus long terme.

La leçon : « ennuyeux » est une fonctionnalité. Des boutons pré-approuvés et des fondamentaux monitorés battent les héros.

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

Phase 0 : Avant l’inondation (vous ne ferez pas ça pendant l’inondation)

1. Instrumentez la chaîne : taille de la file, distribution d’âge des messages, taux de sessions SMTP, compteurs reject/accept, latence DNS, iowait disque, CPU par filtre.
2. Séparez les rôles : un MX entrant ne devrait pas être la même machine qui exécute des jobs lourds non liés. Le mail veut des ressources prévisibles.
3. Créez un jeu de politiques pour incident : une configuration « mode tempête » pré-testée et connue que vous pouvez activer rapidement.
4. Maintenez des allowlists avec des propriétaires : chaque entrée doit avoir une raison et un plan d’expiration.
5. Connaissez vos flux mail critiques : réinitialisation de mot de passe, facturation, intégrations partenaires, notifications légales. Identifiez destinataires et IP/domaines expéditeurs.

Phase 1 : Premiers 15 minutes (stabiliser)

1. Confirmez que c’est inbound : vérifiez le taux de connexion SMTP et la croissance de la file entrante.
2. Identifiez le goulot : CPU vs disque vs DNS vs pertes noyau.
3. Activez le mode tempête : baissez la concurrence par client, activez postscreen/tarpit/greylisting de façon sélective, renforcez l’usage des RBL.
4. Protégez les expéditeurs critiques : ajoutez des allowlists temporaires pour les fournisseurs transactionnels connus et partenaires clés s’ils se font attraper.
5. Arrêtez d’accepter ce que vous ne pouvez pas traiter : préférez les rejets précoces ; si nécessaire, 4xx temporaires pour les sources suspectes afin de préserver le service.

Phase 2 : L’heure suivante (restaurer le flux)

1. Réduisez l’analyse coûteuse : désactivez la récursion profonde d’archives, limitez la taille des pièces jointes pour les sources non authentifiées/non fiables, et assurez-vous de ne pas échouer en ouvert quand vous ne le souhaitez pas.
2. Corrigez le DNS : résolveur cache local, ajustez les timeouts, et réduisez le nombre de vérifications DNS par message.
3. Gérez la file : priorisez le courrier légitime, et envisagez de mettre en quarantaine le trafic d’inondation évident.
4. Communiquez : informez le support de ce qui est retardé, de ce qui est sûr, et des canaux alternatifs sans promettre des miracles.

Phase 3 : Après stabilisation (nettoyer et durcir)

1. Supprimez les blocs temporaires avec une traçabilité ticketée et des contrôles d’expiration.
2. Quantifiez les faux positifs : échantillonnez les mails mis en quarantaine/rejetés, ajustez les règles.
3. Plan de capacité : mesurez les taux d’acceptation de pointe et le débit des scans ; décidez où investir (CPU, stockage, filtrage en amont).
4. Documentez ce qui a marché, ce qui n’a pas marché, et quelles commandes étaient trop risquées.

Erreurs courantes (symptômes → cause racine → correctif)

1) Symptom: Queue grows, CPU is fine, iowait is high

Cause racine : file sur stockage lent/contendé ; trop d’opérations petits fichiers ; pression d’inodes ; possiblement antivirus scannant le répertoire de file.

Fix : déplacez le spool sur disque local rapide ; excluez le spool du scan à accès ; réduisez le taux d’acceptation avec des rejets SMTP ; monitorisez les inodes.

2) Symptom: Lots of SMTP sessions stuck, few rejects, timeouts in logs

Cause racine : lookups DNS qui time-outent (RBL/SPF/DMARC), provoquant des attentes ; résolveur surchargé ou upstream bloqué.

Fix : résolveur cache local ; réduisez le nombre de contrôles DNS ; raccourcissez les timeouts ; assurez-vous que le DNS sortant n’est pas rate-limité ; envisagez la désactivation temporaire des lookups non essentiels.

3) Symptom: Load average spikes, scanner processes multiply, deliveries slow

Cause racine : le scan de contenu est le goulot (AV/scoring, récursion d’archives, extraction PDF/Office).

Fix : limitez la profondeur de récursion ; sautez les MIME coûteux pour les expéditeurs non fiables ; utilisez une porte d’entrée par réputation avant le scan ; scalez les scans horizontalement si c’est prévu.

4) Symptom: Legit partner mail blocked after tightening rules

Cause racine : usage brutal des RBL, contrôles HELO stricts, ou greylisting agressif sans exemptions.

Fix : ajoutez des allowlists avec propriétaires ; utilisez un scoring multi-signal plutôt qu’un rejet par règle unique ; greylistez seulement les sources suspectes ; testez les changements avec du trafic échantilloné des partenaires.

5) Symptom: Kernel reports SYN drops / listen queue overflow

Cause racine : inondation de connexions ; backlog insuffisant ; MTA n’accepte pas assez vite ; trop de sessions SMTP concurrentes.

Fix : limites de connexion/rate limits côté MTA en premier ; ensuite tunez le backlog noyau ; envisagez le filtrage upstream ou la protection au niveau TCP si disponible.

6) Symptom: Outbound mail delayed while inbound flood happens

Cause racine : ressources partagées (même file/disque/CPU) et tempêtes de retries ; processus de livraison sortante à la traîne.

Fix : séparez les rôles inbound/outbound ou au moins séparez les files ; throttlez les retries sortants ; assurez-vous que le rejet inbound empêche la croissance inutile de la file.

7) Symptom: You see lots of bounces you didn’t intend to send

Cause racine : accepter du spam puis rejeter ensuite ou générer des DSN vers des expéditeurs usurpés (backscatter).

Fix : rejetez au moment SMTP ; validez les destinataires lors de RCPT TO ; évitez de générer des DSN pour les inbound non authentifiés quand c’est possible.

FAQ

1) Should I just block entire countries or ASNs during a flood?

Seulement si votre réalité métier le permet. Le geo-blocking peut gagner du temps, mais c’est un instrument brutal avec des dommages collatéraux prévisibles.
Si vous le faites, que ce soit temporaire, journalisé et revu. Préférez les blocs par ASN basés sur le trafic abusif observé plutôt que des impressions.

2) Is greylisting still useful in 2026?

Oui, de façon sélective. Le greylisting général agace les expéditeurs légitimes de première fois et casse certains mailers SaaS mal conçus.
Greylistez les sources suspectes, exemptez les expéditeurs connus, et surveillez l’impact de délai sur le support et les ventes.

3) Why not crank spam scoring to “very aggressive” and call it done?

Parce que la partie coûteuse est souvent le scoring lui-même. De plus, l’agressivité élevée augmente les faux positifs exactement quand vos utilisateurs sont les plus sensibles.
Pendant les inondations, déplacez les contrôles à gauche : rejetez bon marché et tôt ; scannez profondément seulement le courrier qui passe les garde-fous de confiance.

4) How do I avoid blocking password reset and sign-up emails?

Séparez les flux transactionnels. Idéalement, les gateways entrantes devraient avoir une voie protégée pour les mails de vos propres fournisseurs et partenaires clés,
avec allowlists strictes et authentification quand c’est possible. Évitez aussi de router vos e-mails critiques via le même MX public que le trafic inbound aléatoire.

5) What’s the most common “we didn’t think of that” bottleneck?

Le DNS. Chaque fonctionnalité anti-spam qui paraît « légère » se traduit souvent par des requêtes DNS sous charge.
Si votre résolveur est lent ou que votre upstream vous rate-limite, votre système mail devient une salle d’attente distribuée.

6) Can I delete the queue to recover quickly?

Vous pouvez, mais vous ne devriez probablement pas. D’abord, stabilisez l’acceptation pour que la file cesse de croître.
Puis enlevez chirurgicalement le trafic évident (par plages IP expéditrices, destinataires comme info@ sous attaque, ou signatures de spam connues) avec audit.
Supprimer tout est la façon de transformer un incident mail en incident métier avec conséquences légales.

7) Should I disable antivirus scanning during a spam flood?

Parfois, partiellement. Si la vague est un spam volume élevé et low-sophistication, l’AV peut gaspiller du CPU sur des ordures que vous devriez rejeter plus tôt.
Mais désactiver complètement l’AV peut être risqué si vous recevez aussi des malwares ciblés. Approche plus sûre : gatez le scan : lancez l’AV seulement après les contrôles réputation/protocole.

8) How do I know if I’m rejecting too much legitimate mail?

Mesurez les faux positifs délibérément : échantillonnez les mails rejetés dans les logs, mettez en quarantaine les décisions suspectes plutôt que rejeter à chaud lorsque l’incertitude existe,
et surveillez les signaux métier (tickets support, plaintes partenaires, réinitialisations manquantes). Si vous ne mesurez pas, vous devinez—et deviner coûte cher.

9) Do I need multiple MX records and multiple gateways?

Pour la plupart des organisations soucieuses de disponibilité, oui. La redondance ne concerne pas seulement la panne matérielle ; c’est pour absorber l’abus.
Deux gateways permettent maintenance, isolation des problèmes et politiques différentes pour différents flux mail.

10) Why do my legitimate senders keep getting hit by RBLs?

Parce que « légitime » ne veut pas dire « bien géré ». Hébergement partagé, VPS bon marché et mailers SaaS mal configurés peuvent finir sur des blocklists à cause du comportement du voisin.
La solution est de construire un processus : vérifier l’expéditeur, allowlister avec contraintes, et pousser le partenaire à améliorer son infrastructure d’envoi.

Conclusion : prochaines étapes que vous pouvez faire aujourd’hui

Survivre à une déferlante de spam entrants sans bloquer les vrais utilisateurs est un problème de systèmes. Vous gagnez en étant peu coûteux pour les attaquants et prévisible pour les autres.
Ne chassez pas chaque échantillon de spam. Contrôlez vos goulets, rejetez tôt, et gardez une voie protégée pour le courrier critique.

Faites ceci dans la semaine suivante

• Rédigez et testez une config « mode tempête » : limites de connexion, policy postscreen/greylisting, et pipeline de filtrage à coût réduit.
• Mettez la file sur un stockage local rapide et ajoutez des alertes inode. Les alertes d’espace disque seules sont un mensonge réconfortant.
• Déployez un résolveur cache local avec métriques et timeouts sensés ; mesurez la latence DNS sous charge.
• Définissez les flux inbound critiques (réinitialisations, facturation, mail partenaire) et assurez-vous qu’ils ont des exceptions explicites et du monitoring.
• Exercez-vous au triage de file : échantillonnez les en-têtes, identifiez les sources/destinataires principaux, et répétez une procédure de nettoyage sûre.

Le meilleur moment pour découvrir le débit réel de votre passerelle mail n’est pas pendant une inondation.
Le deuxième meilleur moment est avant la prochaine, qui est programmée pour un moment inopportun que vous n’avez pas encore choisi.