Rspamd : le réglage anti-spam qui bloque les attaques sans bloquer les personnes

Le modèle mental en production : Rspamd est un moteur de politique, pas une boîte magique

Si vous abordez Rspamd comme un simple « score anti-spam » que vous bricolez jusqu’à ce que le pager se taise, vous serez occupé·e pour toujours. Si vous l’abordez
comme un moteur de politiques — un classificateur opiniâtre avec des modules, de la réputation et des règles d’application — vous obtiendrez des résultats prévisibles.

En production, vous n’optimisez pas pour « attraper le maximum de spam ». Vous optimisez pour : (1) minimiser les faux positifs, (2) usage des ressources borné sous attaque,
et (3) réversibilité rapide quand vos hypothèses explosent.

L’astuce consiste à construire un pipeline de décision en couches :

• Authentifier (SPF/DKIM/DMARC) et décider ce que signifient les échecs pour vos domaines vs le reste du monde.
• Classer le contenu (symboles, règles, Bayes quand pertinent) sans laisser cela devenir un festival CPU incontrôlable.
• Appliquer la politique (ratelimits, greylisting, réputation d’URL, contrôle des pièces jointes) basé sur les schémas d’abus observés.
• Livrer en sécurité (réécrire le sujet, ajouter des en-têtes, mettre en quarantaine) pour que les humains puissent récupérer les messages quand le classificateur se trompe.

Voici la partie que beaucoup d’équipes manquent : le système de messagerie est un environnement adversarial. Les attaquants s’adaptent. Votre réglage doit être résilient, pas parfait.
« Parfait » est ce que vous dites juste avant de déployer quelque chose qui bloque la paie.

Idée paraphrasée de Werner Vogels : Tout échoue ; concevez pour cela, détectez vite, et récupérez sans héros.

Faits et histoire intéressants qui comptent en pratique

Quelques points de contexte qui affectent réellement la façon dont vous opérez Rspamd au quotidien. Pas des banalités — des choses qui changent les décisions.

1. L’authentification du courrier est jeune par rapport au SMTP. SMTP date du début des années 1980 ; SPF, DKIM et DMARC sont arrivés des décennies plus tard, et la plupart du monde est encore en train de s’y mettre.
2. Rspamd a été construit autour d’un système modulaire de symboles. Vous n’obtenez pas « un score » ; vous obtenez un sac de symboles avec des poids, et c’est pourquoi le réglage est gérable.
3. Redis est devenu le backend d’état commun pour le filtrage moderne. Réputation, ratelimits, fuzzy hashes et l’état Bayesien nécessitent une mémoire partagée rapide ; Redis est le choix pragmatique dans de nombreux déploiements.
4. Le greylisting fonctionne parce que les spammeurs optimisent le débit. Les MTAs légitimes réessaient ; les bots spammeurs bon marché souvent pas. C’est moins magique qu’avant, mais toujours utile quand c’est bien réglé.
5. DMARC a changé le contrat social. Il permet aux propriétaires de domaines de publier des intentions « reject/quarantine », ce qui donne enfin aux récepteurs la permission d’être stricts pour certains domaines.
6. Le « spam » a évolué vers le vol d’identifiants. Le ROI est passé de la vente de pilules au vol de logins. Cela change les signaux importants : usurpation de marque, réputation d’URL et astuces sur le nom affiché.
7. Les inondations de mail sont souvent une diversion. Les attaquants bombardent une boîte pendant qu’ils tentent des réinitialisations de mot de passe ou des transactions frauduleuses ailleurs.
8. Le spam moderne utilise des infrastructures légitimes. Comptes SaaS compromis et plateformes marketing envoient des messages qui « passent l’authentification », vous forçant à vous appuyer sur le contenu et le comportement.

Blague n°1 : Le courriel est le seul protocole où « c’est probablement OK » est traditionnellement validé en attendant trois jours et en voyant qui se plaint.

Comment Rspamd prend des décisions (et où se situe le vrai réglage)

Rspamd évalue les messages et produit :

• Symboles : détections nommées comme R_SPF_FAIL ou DKIM_VALID.
• Scores : poids appliqués aux symboles, combinés en un score d’action global.
• Actions : ce qu’il faut faire à des seuils (aucune action, ajouter un en-tête, greylister, réécrire le sujet, rejeter).

Les actions sont la politique. Les scores sont juste le câblage.

La plupart des douleurs en production viennent de la confusion entre « réglage des scores » et « réglage de la politique ». L’approche stable :

• Gardez les actions conservatrices : ne rejetez pas agressivement tant que vous n’avez pas prouvé que les faux positifs sont faibles.
• Utilisez la quarantaine ou la réécriture du sujet comme étapes intermédiaires pendant que vous apprenez votre flux de mails.
• Privilégiez les ratelimits et le greylisting pour les inondations, car ils contrôlent l’usage des ressources même quand la classification est bruyante.

Les modules qui méritent vraiment votre attention

Un « noyau pragmatique » pour de nombreux environnements :

• SPF/DKIM/DMARC (signaux d’authentification, politique de domaine)
• ARC (chaînes de redirection ; évite de pénaliser les listes/forward légitimes)
• RBL / SURBL (réputation IP/domaine ; prudence avec les listes agressives)
• Reputation (basée sur l’historique, généralement via Redis)
• Ratelimit (contrôle d’inondation)
• Multimap (votre logique allow/deny personnalisée à grande échelle)
• Fuzzy (similarité par hash ; utile pour les campagnes répétées)
• Bayes (utile mais facile à empoisonner et à mal comprendre)

Où placer la logique personnalisée

Si vous ajoutez sans cesse des scripts Lua parce que « nous avions besoin d’une règle de plus », vous finirez par avoir un filtre de messagerie sur-mesure écrit par trois ex-employés.
Préférez :

• multimap pour la plupart des politiques personnalisées (domaines, expéditeurs, types MIME, motifs de sujet)
• local.d/ pour les overrides au lieu d’éditer la config stock
• petits Lua testables uniquement quand multimap ne peut pas exprimer la logique

Stratégie de scoring : cessez de courir après « le score parfait »

Le système de scoring est une machine pour exprimer des compromis. Votre travail est de rendre ces compromis explicites.

Commencez par les actions, puis peaufinez les poids

Une base commune :

• ajouter un en-tête à un score relativement bas (informer la chaîne aval, permettre des recherches)
• réécrire le sujet un peu plus haut (fait remarquer le message à l’utilisateur)
• greylister avec parcimonie (particulièrement pour l’entrée depuis des expéditeurs inconnus)
• rejeter uniquement quand vous êtes confiant·e (ou quand une attaque vous y force)

Acceptez les « échecs doux » pour les signaux d’authentification

SPF et DKIM sont précieux, mais le monde réel est désordonné : forwarding, DNS cassés, expéditeurs mal configurés.
Utilisez les échecs comme signaux qui se combinent avec d’autres, pas comme des déclencheurs uniques de rejet — sauf pour les domaines avec une politique DMARC stricte.

Construisez des politiques séparées pour « vos domaines » vs « l’internet »

Entrant et sortant sont des sports différents.

• Pour entrant, vous vous souciez du phishing, de l’usurpation et des inondations.
• Pour sortant, vous vous souciez de la compromission de comptes et de la préservation de la réputation.

Vos propres domaines peuvent être tenus à des standards plus stricts : imposer la signature DKIM, imposer l’alignement du From, appliquer des contrôles de débit. Si vos propres systèmes ne peuvent pas se conformer,
ce n’est pas la faute de Rspamd. C’est une question de gouvernance qui porte un déguisement technique.

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

Ce sont des tâches de qualité production « faites ça maintenant ». Chacune comporte : une commande, ce que signifie la sortie, et la décision à prendre.
Hypothèses : Rspamd installé, Linux systemd, Redis disponible, et Postfix ou un autre MTA intégré.

Task 1: Confirm Rspamd is actually healthy (not just running)

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd daemon
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-02-04 08:10:21 UTC; 2h 12min ago
   Main PID: 1423 (rspamd)
      Tasks: 32 (limit: 18958)
     Memory: 410.2M
        CPU: 8min 33.120s
     CGroup: /system.slice/rspamd.service
             ├─1423 rspamd: main process
             ├─1431 rspamd: proxy process (localhost:11332)
             ├─1432 rspamd: controller process (localhost:11334)
             └─1440 rspamd: worker process (normal)

Signification : « Active » est le minimum. Mémoire/CPU vous donnent un indice précoce sur des fuites, des explosions de règles ou des conditions d’inondation.
Plusieurs processus sont normaux ; regardez le nombre de workers et leur croissance.

Décision : Si la mémoire monte sans limite ou si le CPU est saturé, sautez le réglage des poids et passez au playbook de diagnostic rapide.

Task 2: Check Rspamd configuration sanity before you change anything

cr0x@server:~$ rspamadm configtest
syntax OK
modules OK

Signification : Syntax OK signifie que Rspamd peut charger la config. « Modules OK » signifie que les modules s’initialisent sans erreur.

Décision : Si cela échoue, ne rechargez pas en vous disant « voyons ce qui se passe ». Corrigez l’erreur de config d’abord ; les files d’attente de mail font d’excellentes bombes à retardement.

Task 3: Verify controller access and see live symbol distributions

cr0x@server:~$ rspamc stat
Uptime: 7964 seconds
Messages scanned: 184295
Messages learned: 312
Messages with action reject: 3911, 2.12%
Messages with action add header: 22144, 12.01%
Messages with action rewrite subject: 8021, 4.35%
Messages with action no action: 150219, 81.52%
Scanned messages per second: 23.15
Actions histogram:
no action: 150219
add header: 22144
rewrite subject: 8021
reject: 3911

Signification : C’est votre tableau de contrôle. Des pics soudains de « reject » ou « rewrite subject » se corrèlent généralement avec une campagne entrante ou un expéditeur cassé.

Décision : Si le taux de reject augmente soudainement, examinez d’abord les symboles et les sources avant d’ajuster les seuils. Ne « corrigez » pas une campagne en abaissant définitivement les standards.

Task 4: Inspect top symbols to find what’s actually driving actions

cr0x@server:~$ rspamc counters
Symbol: R_SPF_FAIL: 12401
Symbol: DKIM_SIGNED: 98234
Symbol: DMARC_POLICY_REJECT: 821
Symbol: RBL_DBL_SPAM: 6402
Symbol: URL_COUNT_5: 4901
Symbol: MIME_HTML_ONLY: 17322
Symbol: BAYES_SPAM: 2501
Symbol: BAYES_HAM: 1811

Signification : Les compteurs montrent la fréquence des symboles. Des symboles fréquents ne sont pas toujours mauvais ; ils décrivent l’environnement.

Décision : Si un seul symbole cause la majorité des rejects, validez-le avec des échantillons réels de courrier. Corrigez la règle ou le poids, pas toute la politique.

Task 5: Pull a specific message scan result (headers or EML)

cr0x@server:~$ rspamc -h localhost:11334 -P 'controllerpass' symbols < /var/spool/mail/samples/suspect.eml
{"is_spam":true,"score":18.50,"required_score":15.00,"action":"reject","symbols":{"R_SPF_FAIL":{"score":2.00},"DMARC_POLICY_REJECT":{"score":4.00},"RBL_DBL_SPAM":{"score":5.00},"MIME_HTML_ONLY":{"score":1.00},"PHISHING":{"score":6.00}}}

Signification : C’est le « pourquoi ». Il ne suffit pas de savoir que le message a été rejeté ; il faut voir quels symboles l’ont fait basculer.

Décision : Si DMARC policy reject se déclenche pour un domaine qui devrait être autorisé (forwarders, listes de diffusion), examinez ARC et la chaîne d’authentification, pas seulement les poids.

Task 6: Validate Redis health and latency (Rspamd depends on it more than you think)

cr0x@server:~$ redis-cli -h 127.0.0.1 -p 6379 INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1240
keyspace_hits:9319921
keyspace_misses:42112

Signification : Ops/sec donne la charge. Hits vs misses donnent l’efficacité du cache. Beaucoup de misses peuvent signifier cache froid ou churn.

Décision : Si ops/sec monte en flèche pendant les inondations de mails, assurez-vous que Redis n’est pas en train de saturer un thread unique, et envisagez de l’isoler ou de dimensionner les workers Rspamd en conséquence.

Task 7: Check Redis memory and eviction policy (to avoid “forgetting” reputations)

cr0x@server:~$ redis-cli INFO memory | egrep 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
used_memory_human:2.13G
maxmemory_human:3.00G
mem_fragmentation_ratio:1.12

Signification : Si vous avez fixé un maxmemory et que Redis commence à évincer, votre état de réputation et de ratelimit devient peu fiable. La fragmentation indique le comportement de l’allocateur.

Décision : Si la mémoire est juste, augmentez maxmemory ou réduisez ce que vous stockez (modules, rétention). « Laisser évincer » est un choix de politique, pas un défaut par défaut.

Task 8: See if Rspamd is CPU-bound (rules too heavy, too many workers, or not enough)

cr0x@server:~$ pidstat -p $(pidof rspamd | tr ' ' ',') 1 3
Linux 6.1.0 (server)  02/04/2026  _x86_64_  (8 CPU)

12:40:11 PM   PID  %usr %system  %CPU  Command
12:40:12 PM  1423  1.00    0.00  1.00  rspamd
12:40:12 PM  1440 92.00    2.00 94.00  rspamd
12:40:12 PM  1441 88.00    1.00 89.00  rspamd

Signification : Des workers proches de 100% sont normaux sous charge, mais une saturation soutenue avec des files d’attente croissantes signifie un goulot d’étranglement.

Décision : Si le CPU est saturé, réduisez les contrôles coûteux (profondeur d’extraction d’URL, regex lourdes, trop de requêtes DNS) ou ajoutez de la capacité. Ne « corrigez » pas le CPU en abaissant les seuils de rejet.

Task 9: Measure DNS resolution health (many modules are DNS-shaped)

cr0x@server:~$ resolvectl statistics
Transactions: 219381
Cache Hits: 171224
Cache Misses: 48157
DNSSEC Verdicts Secure: 0
DNSSEC Verdicts Insecure: 0
DNSSEC Verdicts Bogus: 0

Signification : Beaucoup de misses peuvent signifier un mauvais caching ou des TTL agressifs. En filtrage mail, le DNS est souvent la taxe de latence cachée.

Décision : Si les misses sont élevées et que la latence est visible, installez un résolveur cache local sur le même hôte ou LAN, et assurez-vous que Rspamd l’utilise.

Task 10: Test an RBL/SURBL lookup path (and detect timeouts)

cr0x@server:~$ dig +time=1 +tries=1 2.0.0.127.zen.spamhaus.org A +short
127.0.0.2

Signification : Une réponse rapide signifie que votre chemin DNS fonctionne et que la liste est joignable. Les timeouts ici deviennent des retards par message.

Décision : Si les requêtes expirent, corrigez la sortie DNS, changez de résolveur ou désactivez la liste. Les timeouts sous charge sont la façon dont vous vous auto-DDoS votre passerelle mail.

Task 11: Confirm Postfix is actually handing mail to Rspamd (integration sanity)

cr0x@server:~$ postconf -n | egrep 'smtpd_milters|non_smtpd_milters|milter_protocol|milter_default_action'
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
milter_protocol = 6
milter_default_action = accept

Signification : Si les milters ne sont pas configurés, vous réglez un filtre qui ne voit jamais le trafic. milter_default_action « accept » est un choix de sécurité pendant les pannes.

Décision : Gardez milter_default_action=accept à moins que vous aimiez expliquer pourquoi le système de messagerie s’est fermé au pire moment possible.

Task 12: Watch live throughput and queue pressure (the “is this an attack?” check)

cr0x@server:~$ mailq | tail -n +1 | head -n 12
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2480 Tue Feb  4 12:38:02  sender@example.net
                                         recipient@yourdomain.com

F6G7H8I9J0     3121 Tue Feb  4 12:38:02  sender2@random.tld
                                         recipient@yourdomain.com

-- 2814 Kbytes in 742 Requests.

Signification : Une file d’attente qui grossit indique une lenteur aval : Rspamd, DNS, contrôles de contenu, ou problèmes de livraison.

Décision : Si la file augmente pendant une vague de spam, activez ou resserrez les ratelimits/greylisting au lieu d’ajuster uniquement les scores de contenu.

Task 13: Inspect Rspamd logs for timeouts and module pain

cr0x@server:~$ journalctl -u rspamd --since "30 min ago" | egrep -i 'timeout|slow|error|redis' | tail -n 12
Feb 04 12:22:11 server rspamd[1440]: <0c1d3a>; lua; lua_rsa.lua:142: slow hash computation: 215ms
Feb 04 12:22:18 server rspamd[1441]: ; rbl; rbl.c:512: timeout while resolving zen.spamhaus.org for 203.0.113.44
Feb 04 12:23:04 server rspamd[1440]: ; redis; redis_pool.c:98: cannot connect to redis: Connection refused

Signification : Ces messages point vers les modules exacts causant latence ou échec. Timeouts RBL = DNS ou sortie réseau. Problèmes de connexion Redis = modules d’état qui échouent en open/closed.

Décision : Corrigez la dépendance (DNS/Redis) avant de régler les règles. Sinon vous réglez sur des capteurs cassés.

Task 14: Safely reload Rspamd after config changes

cr0x@server:~$ rspamadm configtest && systemctl reload rspamd && systemctl is-active rspamd
syntax OK
modules OK
active

Signification : Le reload conserve le temps d’activité des processus tout en appliquant les changements de config ; « active » confirme qu’il n’est pas entré en crash-loop.

Décision : Toujours faire configtest avant reload. Vous ne voulez pas apprendre les règles de syntaxe via une panne de mail.

Playbook de diagnostic rapide

Quand la livraison des mails devient lente, les rejects augmentent, ou les utilisateurs commencent à envoyer des captures d’écran avec des cercles rouges : faites ceci dans l’ordre.
L’objectif est de trouver le goulot en quelques minutes, pas de réaliser une anthropologie complète de votre culture spam.

Première étape : s’agit-il de débit, latence ou politique ?

• Problème de débit : files d’attente croissantes, taux de scan en baisse, CPU saturé.
• Problème de latence : retards par message, timeouts dans les logs, blocages DNS.
• Problème de politique : faux positifs/négatifs soudains, changements dans la distribution des actions.

Deuxième étape : vérifiez les trois suspects habituels

1. DNS :
   • Cherchez des timeouts RBL/SURBL dans les logs.
   • Vérifiez les statistiques du résolveur cache.
   • Testez des recherches représentatives avec dig en timeout court.
2. Redis :
   • Redis est-il up ? Échange-t-il ? Évince-t-il des clés ?
   • Vérifiez les pics de latence et les erreurs de connexion.
3. Pression CPU/mémoire :
   • Les workers Rspamd sont-ils saturés ? Passent-ils du temps dans un module lourd ?
   • La machine thrash‑t‑elle à cause de la mémoire ou I/O disque (surtout si Redis persiste) ?

Troisième étape : regardez l’histogramme d’actions et les symboles principaux

Si « reject » ou « rewrite subject » explose, n’éditez pas immédiatement les poids.
Récupérez 10 échantillons (mélange de messages rejetés et limites) et comparez les ensembles de symboles. Vous cherchez l’un de ces cas :

• Une source de réputation unique défaillante (RBL retournant des faux positifs, empoisonnement DNS, listes trop agressives)
• Changements dans la chaîne d’authentification (forwarders, nouvelle plateforme marketing, rotation de clé DKIM cassée)
• Un nouveau pattern de campagne (nouvelles URLs, nouveau type de pièce jointe, nouvelles astuces de sujet)

Quatrième étape : choisissez le bon levier

• Inondation/attaque : ratelimit + greylisting + contrôles de connexion.
• Phishing ciblé : multimap/règles URL + traitement DMARC strict pour les marques protégées + heuristiques sujet/nom affiché.
• Faux positifs : quarantaine + allowlists étroites + corriger le poids du module spécifique.
• Effondrement de performance : réduire les modules DNS lents, ajouter du cache, isoler Redis, scaler les workers.

Trois mini-histoires du terrain en entreprise

1) L’incident causé par une mauvaise hypothèse : « DKIM valid signifie sûr »

Une entreprise moyenne a centralisé sa passerelle entrante avec Rspamd. Elle venait de finir un long projet de « deliverability »,
donc l’authentification était la star : SPF aligné, DKIM signé, DMARC appliqué sur leurs propres domaines.
Ils ont supposé que le courrier entrant avec DKIM_VALID était majoritairement légitime parce que « les spammeurs ne peuvent pas faire DKIM ».

Puis vint la vague de phishing. Ce n’était pas de l’usurpation. Cela provenait de comptes compromis sur une plateforme SaaS légitime qui signe correctement en sortie.
Le message passait SPF et DKIM, et DMARC était aligné parce que l’attaquant utilisait un domaine ressemblant avec une authentification valide.
Le contenu était minimal, l’URL fraîchement enregistrée, et la charge était cachée derrière une chaîne de redirections qui n’apparaissait pas dans les contrôles basiques.

La première réaction de l’équipe fut d’augmenter les poids sur les symboles de contenu. Cela a un peu aidé et beaucoup pénalisé : soudain des réponses courtes et des notifications RH
ont eu le sujet réécrit, parce que beaucoup d’e-mails minimaux paraissent suspects isolément.

La correction fut moins spectaculaire et plus efficace : ils ont cessé de traiter DKIM comme un signal de confiance et ont commencé à le considérer comme un signal d’identité.
Ils ont construit des règles multimap pour les marques protégées et les workflows internes, ajouté des vérifications de réputation d’URL qui résolvent les redirections en sécurité,
et introduit un flux de quarantaine pour les messages « qui passent l’auth mais paraissent suspects ». DKIM importait toujours, mais il ne votait plus deux fois.

Après cela, le système a attrapé la vague suivante sans casser le mail normal. L’équipe a aussi retenu une leçon utile :
l’authentification qui passe devient de plus en plus courante pour le mauvais courrier, car les acteurs malveillants empruntent des infrastructures légitimes.

2) L’optimisation qui a échoué : « On va juste activer tous les RBL »

Une autre organisation avait un problème de spam et un problème d’achat. Ils ne voulaient rien payer de nouveau, et l’équipe
a trouvé une longue liste de blocklists DNS. Quelqu’un proposa : « On les active toutes. Plus de listes, plus de protection. »
Cela semble raisonnable jusqu’à ce que vous vous rappeliez comment le DNS fonctionne sous charge.

Ils ont activé un empilement de fournisseurs RBL/SURBL avec des timeouts agressifs et très peu de cache. Le premier jour, tout avait l’air génial.
Les rejects augmentaient, les plaintes de spam diminuaient, et l’équipe goûta à ce rare sentiment d’avoir raison.

Le deuxième jour, une inondation survint. Les requêtes DNS explosèrent, les timeouts commencèrent, et les workers Rspamd passèrent leur temps à attendre des réponses qui ne venaient pas.
Les files Postfix grossirent. Les mails légitimes furent retardés de minutes. Puis quelqu’un « répara » le problème en augmentant le nombre de workers Rspamd, ce qui ne fit qu’amplifier la pression sur le DNS.
Le système ne filtrait plus le spam ; il menait une attaque DDoS contre son propre résolveur.

La récupération fut simple mais pas glamour : ils réduisirent le nombre de RBL à un petit ensemble de listes à fort signal,
mirent un résolveur cache local en amont, et fixèrent des timeouts par module pour que les échecs se dégradent élégamment.
Ils gardèrent aussi des métriques sur la latence DNS. Il est difficile de discuter avec un graphe qui hurle.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « Quarantaine et revue, toujours »

Une entreprise régulée gérait des mails juridiques, financiers et le genre de courriels RH qui deviennent des preuves s’ils sont mal traités.
Ils voulaient un rejet agressif du spam. L’équipe messagerie a refusé. Ils mirent en place une politique de quarantaine à la place :
la plupart des « spam haute confiance » étaient rejetés, mais tout ce qui était dans une zone grise était mis en quarantaine pour une période de rétention définie.

La quarantaine n’était pas un dossier « indésirables » dans une boîte utilisateur. C’était un contrôle opérationnel :
consultable, auditable, avec accès basé sur les rôles et un workflow d’incident. Chaque faux positif avait une voie de récupération.
Chaque événement de modification enregistrait qui l’a fait et pourquoi.

Un après-midi, un partenaire majeur a roté ses clés DKIM incorrectement et commença à échouer l’alignement. Leur courrier ressemblait à de l’usurpation, et une partie atterrit en quarantaine.
L’impact business fut réel mais contenu : les messages furent retardés, pas détruits.

Parce que l’équipe avait la pratique ennuyeuse en place, l’incident fut un exercice opérationnel de 30 minutes, pas une tempête de blâme de plusieurs jours.
Ils ajustèrent une exception temporaire à portée limitée, informèrent le partenaire de la panne, et retirèrent l’exception une fois le DNS corrigé.
Rien de « brillant » ne s’est produit. C’est pour ça que ça a fonctionné.

Réglages pour les attaques modernes : vagues, phishing et « business email cosplay »

Vagues de spam et mail-bombs : gagnez en bornant l’usage des ressources

Pendant une inondation, la classification de contenu devient moins fiable car les attaquants pulvérisent des variations. La meilleure action est de contrôler le rayon d’explosion :
limitez les débits par IP/par expéditeur, ralentissez les inconnus, et protégez votre MTA aval et les boîtes.

Utilisez le module ratelimit de Rspamd et envisagez un greylisting sélectif :

• Ratelimit basé sur des patterns IP ou ASN quand une campagne se concentre.
• Ratelimit basé sur le destinataire lors de mail-bombs (une boîte submergée).
• Greylistez les expéditeurs inconnus qui échouent aux contrôles d’hygiène de base (pas de rDNS valide, pas d’auth, HELO suspect), mais évitez de greylister les grands fournisseurs qui ont déjà une bonne réputation.

Phishing de credential : traitez les URLs comme la charge utile

La plupart des e-mails de phishing sont des systèmes de distribution d’URL, pas des livraisons de pièces jointes. Vos réglages doivent le refléter :

• Extraire les URLs de manière fiable (sans transformer l’extraction en enfer CPU).
• Vérifier la réputation des URLs et les domaines nouvellement enregistrés.
• Détecter les domaines ressemblants et l’appâtage de marque dans les noms affichés.
• Prendre garde aux chaînes de redirections ; les attaquants se cachent derrière des domaines de tracking « légitimes ».

Usurpation et attaques de type BEC : l’authentification ne suffit pas

Les attaques de type Business Email Compromise utilisent souvent :

• Usurpation du nom affiché (« Nom du CEO » depuis un domaine aléatoire)
• Manipulation du Reply-To (From semble correct ; Reply-To va ailleurs)
• Détournement de fil (réutilisation de sujets comme « Invoice » et « Re: Payment »)

Rspamd peut aider avec des règles personnalisées (multimap/Lua), mais le vrai contrôle est la politique :
routez les motifs d’impersonation suspects vers la quarantaine ou ajoutez un en-tête voyant pour les clients qui affichent des bannières.

Blague n°2 : La seule chose plus persistante que le spam est l’invitation de réunion « Quick Sync » qui refait surface comme une entrée de calendrier hantée.

Maintenir les humains débloqués : contrôler les faux positifs comme un adulte

Les faux positifs ne sont pas seulement « agaçants ». Ce sont des dettes opérationnelles. Les gens contournent un e-mail cassé en utilisant des comptes personnels et des apps de chat,
et soudain votre histoire de gouvernance des données devient une danse interprétative.

Concevez la « voie de récupération » avant de durcir la politique

• Quarantaine pour le courrier limite, avec un workflow de revue défini.
• Réécrire le sujet pour le spam de confiance moyenne, afin que les utilisateurs puissent auto-filtrer sans perdre le mail.
• Ajouter des en-têtes pour la faible confiance. Laissez les systèmes aval décider (SIEM, règles de boîte, clients utilisateurs).

Préférez des allowlists étroites plutôt que larges

« Mettre en allowlist le domaine de l’expéditeur » est généralement trop large. Préférez :

• Allowlister une combinaison spécifique envelope sender + domaine DKIM
• Allowlister une plage d’IP spécifique que vous contrôlez
• Allowlister le domaine d’envoi dédié d’un fournisseur connu (pas leur domaine corporate entier)

Soyez strict là où c’est sûr : vos propres domaines et les marques à haut risque

Pour les mails prétendant provenir de vos propres domaines, la rigueur est non négociable :
un From non aligné doit être sanctionné. C’est ainsi que vous arrêtez l’usurpation et les tentatives d’impersonation internes.

Pour les « marques protégées » (banques, fournisseurs de paie, fournisseurs d’identité), la sévérité est aussi justifiée :
ce sont les domaines que les attaquants exploitent parce que les utilisateurs leur font confiance.

Bayes : utilisez-le, mais ne laissez pas conduire le bus

Le filtrage bayésien peut aider, surtout dans des environnements de courrier stables. Il peut aussi :

• Être empoisonné par des campagnes ciblées
• Sur-ajuster au jargon interne
• Créer un couplage invisible entre « comportement d’entraînement » et résultats de messagerie

Si vous utilisez Bayes, traitez l’entraînement comme un processus opérationnel, pas comme un passe-temps. Limitez qui peut entraîner, journalisez les événements d’entraînement, et évaluez périodiquement la précision.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: sudden spike in rejected legitimate mail

Cause racine : Une source de réputation est devenue « chaude » (faux positifs RBL/SURBL) ou le DNS a commencé à expirer et à échouer de façon biaisée.

Correction : Identifiez le symbole qui provoque les rejects via rspamc symbols sur des échantillons. Réduisez le poids ou désactivez cette liste, ajoutez du cache DNS, fixez des timeouts, et vérifiez avec des tests en direct.

2) Symptom: queues growing, Rspamd CPU pegged, scan rate drops

Cause racine : Trop de contrôles coûteux (RBLs, extraction d’URL, regex) + cache insuffisant ; ou une inondation poussant le système au pire cas.

Correction : Resserrez les ratelimits/greylisting, réduisez les modules lents, assurez un résolveur cache local, et scalez horizontalement si nécessaire. Mesurez avant/après.

3) Symptom: “Spam passes” even with high scores configured

Cause racine : Rspamd n’est pas réellement dans le chemin mail (milter mal configuré) ou il échoue ouvert à cause de dépendances (Redis down, timeouts).

Correction : Vérifiez les milters du MTA, vérifiez les logs Rspamd, validez la connectivité Redis. N’ajustez pas les scores tant que vous n’avez pas confirmé que les messages sont scannés.

4) Symptom: forwarded mail gets rejected due to DMARC

Cause racine : Le forwarding casse SPF et peut casser DKIM ; l’alignement DMARC échoue et vous appliquez la politique trop strictement sans gérer ARC.

Correction : Activez et validez le traitement ARC, créez des exceptions ciblées pour les forwarders connus, et mettez en quarantaine au lieu de rejeter pour les flux forward ambigus.

5) Symptom: legitimate bulk mail (invoices, notifications) lands as spam

Cause racine : Mauvaise configuration du fournisseur : absence d’en-têtes List-Unsubscribe, mauvais alignement DKIM, réputation IP partagée, ou contenu type « template marketing » qui déclenche.

Correction : Construisez des règles allow étroites (domaines/IP d’envoi spécifiques), exigez l’alignement DKIM des vendeurs, et ajustez les poids uniquement pour les motifs de symboles observés.

6) Symptom: intermittent failures, “cannot connect to redis”

Cause racine : Redis sur le même hôte concurrence pour mémoire/CPU, atteint maxclients, ou est redémarré par l’OOM killer.

Correction : Allouez correctement les ressources, fixez maxmemory Redis avec une politique d’éviction délibérée, surveillez, et envisagez d’isoler Redis sur une infrastructure dédiée.

7) Symptom: “Everything is greylisted,” users complain about delays

Cause racine : Greylisting appliqué trop largement (y compris aux grands fournisseurs), ou liste blanche non configurée pour les expéditeurs de confiance.

Correction : Restreignez le greylisting aux sources inconnues/faible réputation, whitelist les grands MTAs quand approprié, et utilisez le ratelimit pour les inondations au lieu d’un greylist généralisé.

8) Symptom: false positives tied to one internal department

Cause racine : Systèmes internes envoyant du mail machine-generated en HTML-only ou structures MIME bizarres qui paraissent spammy.

Correction : Corrigez l’expéditeur pour produire un MIME sensé, ajoutez un DKIM correct, et seulement ensuite ajoutez une règle allow étroite si nécessaire.

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

Étape par étape : durcir Rspamd sans faire exploser la confiance des utilisateurs

1. Observabilité de base : histogramme d’actions, taux de scan, profondeur des files, latence DNS, santé Redis.
2. Définir des actions conservatrices : ajouter un en-tête > réécrire le sujet > quarantaine/greylist > rejet.
3. Valider la chaîne d’auth : résultats SPF/DKIM/DMARC/ARC sur un trafic représentatif (pas seulement un expéditeur heureux).
4. Contrôler les inondations : activer les ratelimits ; décider d’un plan de protection des destinataires pour les mail-bombs.
5. Choisir les sources de réputation intentionnellement : peu de listes de haute qualité, avec timeouts stricts et cache.
6. Construire la politique multimap : marques protégées, fournisseurs connus, systèmes internes, et chemins « ne jamais rejeter » routés vers la quarantaine.
7. Définir le workflow d’exception : qui peut allowlister, durée des exceptions, audit et suppression.
8. Faire un drill faux-positif : simuler une défaillance DKIM partenaire ; confirmer que vous pouvez récupérer le courrier depuis la quarantaine rapidement.
9. Test de charge : rejouer des inondations d’exemple ; vérifier taux de scan et comportement des files sous charge.
10. Itérer chaque semaine : changements modestes, impact mesuré, capacité de revenir en arrière.

Checklist : avant d’augmenter l’agressivité des rejets

• La quarantaine existe et est consultable avec un SLA défini pour la revue.
• Les symboles principaux de rejet sont compris avec des exemples réels.
• Le caching DNS est en place et les timeouts RBL sont contrôlés.
• Redis a de la marge et pas de surprises d’éviction.
• Les chemins de forwarding sont évalués (ARC si nécessaire).
• Un runbook on-call existe pour « le partenaire a cassé DKIM » et « attaque mail-bomb ».

Checklist : pendant une attaque active

• Confirmez qu’il s’agit d’une attaque : croissance des files + changements dans l’histogramme d’actions + concentration des sources.
• Activez/serrez les ratelimits pour les sources ou destinataires attaquants.
• Envisagez un greylisting temporaire pour les sources inconnues.
• Réduisez les contrôles lents qui amplifient la latence (RBLs supplémentaires, extraction d’URL lourde) jusqu’à stabilisation.
• Mettez en quarantaine le courrier auth-passing mais suspect plutôt que de le rejeter si incertain.
• Post-incident : annulez les contrôles larges temporaires, et convertissez ce que vous avez appris en règles ciblées.

FAQ

1) Dois‑je rejeter le spam au moment SMTP ou le mettre en quarantaine ?

Rejetez au moment SMTP pour les cas de haute confiance (malware/phish clair, échecs DMARC reject alignés pour domaines protégés, IP connues mauvaises).
Mettez en quarantaine pour les cas ambigus. Si vous ne pouvez pas récupérer le courrier de façon fiable, vous n’êtes pas prêt·e à rejeter agressivement.

2) Quelle est la façon la plus rapide de réduire les faux positifs ?

Ne « baissez pas tous les scores ». Identifiez le(s) symbole(s) principal(aux) provoquant les faux positifs en scannant des échantillons et en regardant les compteurs. Corrigez ce module ou ce poids,
et ajoutez une exception étroite pour le comportement d’expéditeur spécifique si nécessaire.

3) Le greylisting est‑il encore utile ?

Oui, mais seulement de façon sélective. Le greylisting global pénalise les fournisseurs de bulk légitimes et crée des délais visibles par les utilisateurs.
Utilisez‑le comme soupape de pression pour les sources inconnues ou pendant les inondations, pas comme filtre principal.

4) Combien de listes RBL/SURBL devrais‑je activer ?

Moins que vous ne le pensez. Choisissez un petit nombre de listes à fort signal, appliquez des timeouts serrés, et assurez un cache DNS solide.
Plus de listes peuvent réduire le spam — jusqu’à ce qu’elles réduisent davantage votre débit.

5) Pourquoi le spam passe‑t‑il SPF/DKIM/DMARC aujourd’hui ?

Parce que les attaquants utilisent des comptes compromis et des expéditeurs légitimes, ou enregistrent des domaines ressemblants et configurent l’authentification correctement.
L’authentification prouve l’identité du domaine expéditeur, pas l’intention du message.

6) Où dois‑je garder les personnalisations locales ?

Dans local.d/ et les définitions multimap. Évitez d’éditer les configs stock directement ; cela complique les mises à jour et rend la dérive invisible.

7) Comment régler Rspamd sous forte charge sans empirer la situation ?

Traitez la latence des dépendances comme l’ennemi : DNS et Redis d’abord. Utilisez ratelimit/greylisting pour borner le travail.
Désactivez ou relâchez temporairement les contrôles lents. N’ajoutez pas de workers sans comprendre le goulot partagé.

8) Ai‑je besoin du filtrage bayésien ?

Pas toujours. Dans des environnements entrants diversifiés, Bayes peut être bruyant et coûteux opérationnellement.
Si vous l’utilisez, verrouillez l’entraînement, surveillez la précision, et assurez‑vous qu’il ne domine pas les autres signaux.

9) Comment gérer le courrier forwardé et les listes sans se faire phisher ?

Activez l’évaluation ARC quand c’est approprié, mettez en quarantaine les échecs ambigus, et écrivez une politique explicite pour les forwarders et les listes connus.
Ne « ignorez » pas massivement DMARC. C’est ainsi que l’usurpation revient.

Conclusion : prochaines étapes à faire cette semaine

Rspamd vous permettra volontiers de construire une cathédrale compliquée de scoring. Ne le faites pas. Construisez une machine de politiques qui se dégrade gracieusement,
est observable, et dispose d’une voie de récupération pour les humains.

1. Exécutez rspamc stat et rspamc counters ; capturez en image les taux d’action de base et les symboles principaux.
2. Validez les dépendances DNS et Redis ; corrigez les timeouts et le cache avant de toucher les poids.
3. Implémentez (ou resserrez) les ratelimits pour les mail-bombs ciblant des destinataires et les sources évidentes d’inondation.
4. Mettez en place une quarantaine pour les cas limites ; définissez qui la révise et à quelle vitesse.
5. Créez une politique multimap pour les marques protégées et les workflows internes critiques.
6. Faites un seul changement de réglage contrôlé, mesurez l’impact pendant une semaine, et ayez un plan de retour arrière.

Si vous faites ces six choses, vous bloquerez plus d’attaques et bloquerez moins de personnes — ce qui est la seule métrique qui compte quand l’activité business est réveillée.