Rspamd : antispam moderne haute performance pour serveurs mail

SpamAssassin a été le standard antispam pendant 20 ans. Lent, en Perl, gourmand en ressources, il devient un goulot d'étranglement sur des MX à fort débit. Rspamd, lancé en 2008 par Vsevolod Stakhov, est devenu en 2026 le moteur antispam de référence pour les déploiements mail modernes.

Écrit en C avec Lua pour la logique métier, threadé, indexant ses bases en mémoire, Rspamd traite les messages 10 à 100 fois plus vite que SpamAssassin sur du matériel équivalent. Il est le moteur antispam embarqué dans Mailcow, iRedMail, et beaucoup d'installations Postfix custom.

Ce qui suit n'est pas un guide d'install pas à pas. C'est ce qu'on regarde côté ops pour faire tenir un Rspamd en prod sur un MX qui voit des milliers de messages par jour.

• Pourquoi Rspamd plutôt que SpamAssassin
• Architecture : workers, scanners, modules
• Intégration Postfix via milter
• Modules clés : RBL, bayésien, DKIM, GreyListing
• Scoring et seuils en pratique
• Web UI et observabilité
• Tuning et performance
• Pièges et signaux d'alerte

Là où Rspamd gagne nettement.

Performance. Sur un même MX traitant 100 msg/min, SpamAssassin Perl sature un coeur. Rspamd C+Lua tient 1000 msg/min sur le même hardware sans transpirer. Pour un fournisseur mail multi-domaines, c'est un coût d'infra divisé par 10.

Modules modernes. Rspamd intègre nativement DKIM, ARC, DMARC, MTA-STS, TLS-RPT, BIMI. SpamAssassin demande des plugins externes parfois mal maintenus.

Web UI native. Rspamd embarque une interface web pour visualiser les scans, les scores, les apprentissages bayésiens, les listes blanches/noires. SpamAssassin reste CLI / config files.

Apprentissage par fuzzy hashes. Rspamd compare des hashes "fuzzy" entre messages, détecte des spam similaires même légèrement reformulés. SpamAssassin n'a pas d'équivalent.

SpamAssassin reste valide pour des install historiques avec règles personnalisées massives. Pour tout déploiement neuf en 2026, Rspamd est le défaut.

Rspamd se compose de plusieurs workers :

• rspamd_proxy : reçoit les messages depuis Postfix via le protocole milter ou en SMTP proxy. Distribue aux scanners.
• scanner workers : appliquent les modules sur chaque message, calculent le score.
• controller : gère l'API web et le bayésien d'apprentissage.
• fuzzy : stocke les hashes fuzzy pour détection de variants.

Backend de stockage : Redis pour le bayésien, fuzzy, ratelimits, greylisting. SQLite ou MySQL en option.

Modules organisés en :

• Pre-filter : exécutés avant le scan (greylisting, par exemple).
• Filter : modules de scoring (RBL, DKIM, bayes, fuzzy, regexp, etc.).
• Post-filter : actions sur le résultat (rewrite, milter responses).
• Statistics : bayésien et apprentissage.
• Composites : combinaisons de symboles pour des règles métier.

Fichiers de configuration sous /etc/rspamd/. Modèle "configuration recursive" : local.d/ pour overrides locaux, override.d/ pour overrides totaux.

Pour Postfix, on utilise Rspamd en milter (Sendmail Mail Filter Protocol) :

# /etc/postfix/main.cf
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_default_action = accept
milter_protocol = 6

Côté Rspamd, le worker rspamd_proxy écoute sur 11332 :

# /etc/rspamd/local.d/worker-proxy.inc
bind_socket = "*:11332";
milter = yes;
timeout = 120s;
upstream "local" {
  default = yes;
  self_scan = yes;
}

À chaque message reçu par Postfix, le contenu est passé à Rspamd, qui retourne un verdict (action) que Postfix applique.

Pour Dovecot, intégration via le plugin antispam ou via apprentissage manuel par boutons "Spam"/"Non-spam" dans le webmail (SOGo, Roundcube).

Rspamd active par défaut une cinquantaine de modules. Les essentiels :

RBL (Real-time Block Lists) : interroge des listes publiques (Spamhaus, SURBL, Barracuda, UCEPROTECT) sur l'IP source et les URLs du message. Score additionné selon les listes touchées. Spamhaus ZEN reste la liste de référence.

DKIM. Vérifie la signature DKIM des messages entrants, signe les messages sortants. Configuration des clés DKIM par domaine émetteur.

DMARC. Applique la politique DMARC publiée par le domaine émetteur (none, quarantine, reject). Génère les rapports rua à envoyer au domaine.

ARC. Authenticated Received Chain, complète DKIM/DMARC quand un message est forwardé.

GreyListing. Refuse temporairement (4xx) un message d'un (IP, sender, recipient) inconnu. Si le serveur émetteur retente (comportement RFC), accepte. Bloque énormément de spam de bots qui ne retentent pas. Tradeoff : retard de quelques minutes sur les premiers messages.

Bayésien. Filtre statistique entraîné sur les messages spam et ham. Apprentissage automatique au passage par boutons UI Spam/Ham, ou en push via API.

Fuzzy hashes. Compare le message à une base de hashes connus pour détecter des variants de campagnes.

SPF. Vérifie que l'IP source est autorisée par le record SPF du domaine émetteur.

Ratelimits. Limite le nombre de messages par sender, par recipient, par IP, sur une fenêtre temporelle. Bloque les comptes compromis qui essaient de spammer en masse.

Chaque module génère des "symboles" avec des scores. Le total est comparé aux seuils :

• score inférieur ou égal à 4 : accepté (greenlight).
• score 4 à 9 : add_header (marquer Spam dans le sujet ou les headers).
• score 9 à 15 : rewrite_subject (modifier le sujet).
• score supérieur ou égal à 15 : reject (refuser au SMTP).

Ces seuils par défaut sont ajustables par domaine ou par recipient. Pour des MX très conservateurs, monter le seuil reject à 20 et faire transiter par quarantine à 12. Pour des MX agressifs, baisser à 8.

Les scores sont visibles dans les headers X-Rspamd-Score: -2.3 / 9.0 et X-Spamd-Result: default: False [-2.31 / 9.00]; ....

Pour un Mailcow Dockerized, ces seuils sont configurables depuis l'UI Rspamd accessible via le frontend admin.

Rspamd expose une UI web sur le port 11334 (à exposer derrière un reverse proxy avec auth). On y voit :

• Stats de scan en temps réel.
• Top symboles déclencheurs.
• Historique des scans avec scores détaillés.
• Apprentissage bayésien et fuzzy.
• Throughput par seconde / minute / heure.

Métriques Prometheus exposées : à intégrer dans un stack Grafana classique pour suivre le taux de spam, les rebonds, les scores.

Les logs Rspamd sont structurés JSON, ingérables vers Loki ou Elastic. Pour le SIEM, rsyslog en relais est l'usage standard.

Workers. Adapter le nombre de workers scanner à nproc * 2. Sur 8 coeurs, 16 workers tiennent confortablement plusieurs centaines de msg/sec.

Redis. Backend critique. Lui donner du SSD, suffisamment de RAM pour le bayésien et le fuzzy. Pour des MX > 50k msg/jour, Redis dédié, pas en local.

Cache modules. La plupart des résultats RBL et DKIM sont cachés. TTL configurable, par défaut 1h.

Logging. Verbosité par défaut OK. En cas d'investigation, monter à level = "debug" temporairement.

Bayésien training. Le bayésien est efficace après 200-1000 messages d'apprentissage. Le maintenir à jour demande un workflow utilisateur (boutons Spam/Ham) ou des feeds externes.

Fuzzy storage. Les hashes fuzzy peuvent grossir. Configurer expiration (par défaut 90 jours).

Faux positifs sur les newsletters légitimes. Une newsletter envoyée à 100k destinataires depuis une IP "marketing" peut déclencher RBL même si le contenu est légitime. Whitelist explicite par domaine émetteur, ou par From.

DMARC strict trop tôt. Activer p=reject dès le départ casse les forwards et certaines listes de diffusion. Toujours commencer par p=none pour collecter les rapports rua, puis quarantine, puis reject après vérification 6 mois.

Greylist sur emails urgents. Un client attend un email de validation, message retardé 5 minutes par greylist, support IT panique. Documenter le comportement greylist côté help desk.

Auth bayésien. Si plusieurs utilisateurs apprennent dans la même base bayésienne, les apprentissages contradictoires se neutralisent. Préférer un bayésien par utilisateur ou par classe d'utilisateurs.

Scaling fuzzy. À très grande échelle, fuzzy storage devient lourd. Évaluer si les modules fuzzy_check (auto-learning) sont actifs ou non.

Ratelimits sur les mailings. Si un client envoie une campagne légitime, les ratelimits par-sender bloquent. Whitelist explicite ou augmentation du seuil pour ce sender.

RBL down. Une RBL en panne (Spamhaus a déjà eu des incidents) cause faux négatifs. Configurer plusieurs RBL en parallèle, ne pas dépendre d'une seule.

Sur un déploiement Rspamd moderne (Mailcow, Postfix custom), la performance et la maintenabilité sont sans commune mesure avec SpamAssassin. Les seuls cas où SpamAssassin reste défendable : héritage de règles personnalisées massives qu'on ne veut pas réécrire. Pour tout MX neuf ou en migration, Rspamd est le choix. Bayésien, RBL et seuils ratelimit ne se règlent jamais une fois pour toutes ; quand ce réglage continu pèse, son maintien se délègue.

• Rspamd documentation officielle : référence modules, config, tuning.
• GitHub rspamd/rspamd : code source, releases.
• Postfix milter documentation : intégration milter avec Postfix.
• DMARC.org guides : référence du protocole et bonnes pratiques.
• Spamhaus Project : fournisseur des RBL les plus utilisées.
• M3AAWG sender best practices : pratiques deliverability et antispam validées par l'industrie.