Rspamd : configuration minimale pour un premier déploiement qui fonctionne réellement

janvier 25, 2026 • février 3, 2026 • Lecture : 33 min • Views: 8

Cet article vous a aidé ?

Certaines solutions anti-spam échouent de façon spectaculaire. Rspamd échoue comme un professionnel : il accepte le courrier, marmonne dans les logs, et vos utilisateurs continuent d’envoyer des captures d’écran de « Bitcoin invoice.pdf.exe ». Pendant ce temps vous regardez une ventilation des scores qui semble correcte, et pourtant rien n’est rejeté, signé ou appris.

Ce guide d’installation initiale s’adresse aux personnes qui exploitent des systèmes en production. Configuration minimale, réflexion maximale. Nous allons vous amener à une base opérationnelle : analyse par Rspamd, signature DKIM, état basé sur Redis, interface sécurisée et intégration MTA qui ne se contourne pas silencieusement.

Ce que « minimal » signifie réellement en production

Minimal ne veut pas dire « le moins de lignes de configuration ». Minimal signifie « le moins d’éléments mobiles qui fournissent des résultats prévisibles ». Pour Rspamd, cette base comprend :

Un démon rspamd en fonctionnement et rspamd_proxy gérant l’analyse.
Redis activé pour l’historique, fuzzy, Bayes et divers caches (vous pouvez vous en passer, mais votre futur vous en voudra).
Une intégration MTA qui ne peut pas être « accidentellement contournée ». Pour Postfix, cela signifie un milter et que le socket est accessible depuis le contexte de processus de Postfix.
Signature DKIM pour le courrier sortant, avec les clés placées à un endroit raisonnable et des sélecteurs que vous pouvez faire pivoter.
Seuils d’action qui correspondent à la réalité (reject pour les cas manifestement malveillants, add-header pour les cas limites), et des logs qui expliquent ce qui s’est passé.

Ce que « minimal » n’est pas :

Activer tous les modules parce que « ça pourrait aider ». C’est comme ça qu’on finit par mettre en greylist ses propres alertes de supervision et l’appeler « sécurité ».
Éditer des fichiers sous /etc/rspamd/ directement alors qu’il faut utiliser local.d et override.d.
Ignorer DKIM parce que vous « n’êtes pas prêt ». Vos destinataires sont prêts ; ils vous noteront comme un spammeur.

Une vérité opérationnelle : si vous ne pouvez pas expliquer comment un message a reçu son action finale (reject/add-header/no action), vous n’avez pas un filtre anti-spam, vous avez une rumeur.

Quelques faits et un peu d’historique qui orientent les choix

Voici le type de petits faits concrets qui vous empêchent de prendre la mauvaise décision architecturale à 2 h du matin.

Rspamd a été conçu dès le départ comme un système multi-composants (types de workers, proxy, controller). Ce n’est pas un monolithe ; si vous le configurez comme tel, vous le diagnostiqueriez mal.
Il s’appuie fortement sur Redis pour des choses au-delà de Bayes : résultats mis en cache, réputation, vérifications fuzzy et historique. Traitez Redis comme une partie du pipeline mail, pas comme un « bonus ».
Le modèle de scoring de Rspamd est basé sur des symboles : il ne dit pas « spam/pas spam », il énonce « voici des raisons avec des poids ». C’est pourquoi le tuning est survivable—à condition de ne pas paniquer et modifier les poids au hasard.
La délivrabilité moderne repose sur l’authentification : DKIM, SPF, DMARC. Le filtrage aide l’entrée ; DKIM aide la sortie à ne pas ressembler à une usurpation.
Les milters sont anciens mais efficaces. Ils sont aussi faciles à mal brancher. La plupart des rapports « Rspamd ne filtre pas » signifient « le MTA ne l’a jamais appelé ».
Rspamd supporte plusieurs schémas d’intégration : milter, proxy LMTP, proxy SMTP. Le « minimal qui marche » dépend de votre MTA, mais les modes de défaillance se ressemblent : contournement, timeouts, mauvais sockets.
La rotation des clés DKIM est peu coûteuse si vous utilisez bien les sélecteurs. Si vous codez en dur un seul sélecteur partout pour toujours, vous finirez par planifier une fenêtre de maintenance angoissante pour une opération sans risque.
Rspamd intègre un contrôleur HTTP pour statistiques et commandes. L’exposer sans authentification est une petite tragédie évitable.

Architecture minimale fonctionnelle (et ce qu’il faut éviter)

Voici l’architecture de base qui a tendance à « juste marcher » sur un hôte mail unique avec Postfix :

Postfix reçoit le courrier et le transmet à un socket milter.
rspamd_proxy accepte les requêtes milter, appelle les workers d’analyse, puis indique à Postfix quoi faire et ajoute des en-têtes.
rspamd utilise Redis localement pour les caches et Bayes, et stocke l’historique pour le débogage.
La signature DKIM s’effectue dans Rspamd pour le courrier sortant (Postfix fait passer le message par le même milter).

Ce qu’il faut éviter au départ :

Clustering de Rspamd sur plusieurs nœuds. Pas parce que c’est mauvais, mais parce que vous confondrez les problèmes réseau avec des problèmes de scoring.
Modules exotiques (plusieurs systèmes OCR, règles Lua personnalisées). Assurez-vous d’abord que le courrier est réellement scanné.
Automatisation de l’entraînement Bayes avant d’avoir une séparation ham/spam correcte et un scoring stable. Automatiser un jeu de données erroné est une manière efficace d’être dans l’erreur.

Blague n°1 : Un filtre anti-spam sans logs ressemble à un parachute fait d’opinions—techniquement léger, opérationnellement courageux.

Installer et vérifier que le démon tourne vraiment

Nous supposerons un hôte Debian/Ubuntu avec systemd. Si vous êtes sur autre chose, adaptez le gestionnaire de paquets et les noms de services, pas la logique.

Installer les paquets

cr0x@server:~$ sudo apt-get update
...output...
cr0x@server:~$ sudo apt-get install -y rspamd redis-server
...output...

Décision : si les paquets de votre distribution sont anciens, vous le sentirez par des modules manquants et des bugs que vous ne devriez pas déboguer. Mais « minimal qui marche » fonctionne encore avec les paquets distro—ne prétendez juste pas qu’ils sont à jour.

Vérifier que les services sont actifs

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:12 UTC; 2min ago
...output...
cr0x@server:~$ systemctl status redis-server --no-pager
● redis-server.service - Advanced key-value store
     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2026-01-03 09:01:03 UTC; 2min ago
...output...

Décision : si l’un des services n’est pas active (running), arrêtez-vous. Corrigez cela d’abord. L’analyse du courrier est une chaîne ; un composant mort n’est pas « dégradé », il ne fonctionne pas.

Confirmer que Rspamd écoute

cr0x@server:~$ sudo ss -lntp | egrep '11334|11333|11332'
LISTEN 0      4096         127.0.0.1:11334      0.0.0.0:*    users:(("rspamd",pid=1827,fd=6))
LISTEN 0      4096         127.0.0.1:11333      0.0.0.0:*    users:(("rspamd",pid=1827,fd=7))
LISTEN 0      4096         127.0.0.1:11332      0.0.0.0:*    users:(("rspamd",pid=1827,fd=8))

Ce que cela signifie : les ports par défaut de Rspamd sont actifs (interfaces proxy/controller/workers selon le paquetage).

Décision : si ces ports n’écoutent pas, vous êtes mal configuré ou le paquet utilise des sockets différents (souvent UNIX). Ne connectez pas Postfix à un port que vous n’avez pas prouvé exister.

Organisation des configs : comment ne pas se battre avec Rspamd

La configuration de Rspamd est en couches. Traitez la configuration fournie par le paquet comme lecture seule. Votre travail est de surcharger proprement.

/etc/rspamd/ : configuration de base fournie par le paquet
/etc/rspamd/local.d/ : vos modifications locales (les plus courantes)
/etc/rspamd/override.d/ : surcharges forcées quand il faut écraser des valeurs par défaut

Règle : si vous éditez /etc/rspamd/rspamd.conf directement, vous vous inscrivez à des douleurs lors des mises à jour et à de l’archéologie « pourquoi ceci a changé ».

Valider la configuration avant de redémarrer

cr0x@server:~$ sudo rspamd -t
syntax OK

Ce que cela signifie : le parseur accepte vos fichiers.

Décision : si cela échoue, ne redémarrez pas. Corrigez la syntaxe d’abord ; un filtre anti-spam cassé a tendance à échouer ouvert d’une manière que vous ne remarquerez pas avant que les utilisateurs n’en parlent.

Redis : la dépendance sur laquelle il ne faut pas économiser

Oui, vous pouvez exécuter Rspamd sans Redis. Il analysera quand même. Et vous perdrez la visibilité et l’état qui rendent l’analyse fiable : Bayes, fuzzy, historique et caches. En production, Redis n’est pas optionnel ; c’est votre mémoire.

Configuration minimale de Redis pour Rspamd

Sur un hôte unique, utilisez un socket UNIX local pour la rapidité et la clarté des permissions. Mettez ceci dans /etc/rspamd/local.d/redis.conf :

cr0x@server:~$ sudo tee /etc/rspamd/local.d/redis.conf > /dev/null <<'EOF'
servers = "unix:/run/redis/redis-server.sock";
EOF

Assurez-vous maintenant que Redis expose ce socket et que Rspamd peut le lire. Sur les systèmes de type Debian, c’est généralement le cas. Vérifiez :

cr0x@server:~$ ls -l /run/redis/redis-server.sock
srwxrwx--- 1 redis redis 0 Jan  3 09:01 /run/redis/redis-server.sock

Ce que cela signifie : les permissions de groupe sont importantes. Si rspamd n’appartient pas au groupe redis, il ne peut pas communiquer.

Décision : ajoutez rspamd au groupe redis (ou configurez des ACL) plutôt que de passer Redis en TCP « parce que c’est plus simple ». Simple aujourd’hui, incident demain.

cr0x@server:~$ sudo usermod -aG redis rspamd
cr0x@server:~$ sudo systemctl restart rspamd
...output...

Confirmer que Rspamd peut utiliser Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Décision : si cela pointe encore ailleurs, vous avez mis le fichier au mauvais endroit ou votre paquet utilise un ordre d’inclusion différent. Corrigez cela avant de peaufiner autre chose.

Intégration Postfix (milter) qui filtre réellement le courrier

Le principal mode d’échec est embarrassant simple : Postfix n’appelle jamais Rspamd. Tout le reste—Redis, DKIM, Bayes—devient de l’art de la performance.

Pour une configuration minimale, utilisez un socket milter local fourni par rspamd proxy. Beaucoup de paquets exposent /run/rspamd/milter.sock. Vérifiez d’abord :

cr0x@server:~$ sudo find /run -maxdepth 2 -type s -name '*milter*sock' -o -name 'rspamd*.sock'
/run/rspamd/milter.sock

Décision : si vous n’avez pas de socket, il faut soit activer le worker milter, soit votre paquet utilise TCP. Ne devinez pas ; inspectez.

Configurer Postfix pour utiliser le milter Rspamd

Éditez la config principale de Postfix. Utilisez les chemins SMTPd et non-SMTPd si vous tenez aux soumissions locales. Valeurs minimales et fiables :

cr0x@server:~$ sudo postconf -e 'smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'non_smtpd_milters=unix:/run/rspamd/milter.sock'
cr0x@server:~$ sudo postconf -e 'milter_protocol=6'
cr0x@server:~$ sudo postconf -e 'milter_default_action=accept'
cr0x@server:~$ sudo postconf -e 'milter_mail_macros=i {mail_addr} {client_addr} {client_name} {auth_authen}'

Ce que cela signifie :

milter_default_action=accept est conservateur : si Rspamd est tombé, le courrier circule. Cela évite des pannes totales, mais peut être abusé si des attaquants provoquent des timeouts.
milter_protocol=6 est assez moderne pour le support des macros courantes.

Décision : dans certains environnements, « fail open » est acceptable ; dans d’autres, c’est un problème de conformité. Si vous êtes une cible à haute valeur, envisagez tempfail une fois la stabilité acquise.

Recharger Postfix et vérifier qu’il utilise le socket

cr0x@server:~$ sudo systemctl reload postfix
...output...
cr0x@server:~$ sudo postconf | egrep 'smtpd_milters|non_smtpd_milters|milter_default_action'
smtpd_milters = unix:/run/rspamd/milter.sock
non_smtpd_milters = unix:/run/rspamd/milter.sock
milter_default_action = accept

Décision : si Postfix affiche les bonnes valeurs mais que le courrier n’est toujours pas filtré, vous avez probablement un problème de permissions sur le socket ou une question de chroot.

Vérifier que Postfix peut accéder au socket milter

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Ce que cela signifie : si le socket est rspamd:rspamd avec 770, les processus Postfix peuvent ne pas appartenir à ce groupe.

Décision : ajoutez l’utilisateur Postfix au groupe rspamd, ou ajustez les permissions du socket dans la config du worker Rspamd. Ne mettez pas 777 sur une frontière de sécurité et appelez ça « temporaire ». Temporaire devient permanent avec refus.

cr0x@server:~$ sudo usermod -aG rspamd postfix
cr0x@server:~$ sudo systemctl restart postfix
...output...

DKIM : minimal mais correct

DKIM n’est pas un simple théâtre de délivrabilité. C’est un signal fort pour les récepteurs que votre courrier sortant est cohérent, non usurpé et pas passager.

Le minimum DKIM dans Rspamd nécessite :

Une paire de clés stockée sur disque avec des permissions correctes.
Un sélecteur (par exemple s2026) que vous pouvez faire pivoter.
Une correspondance entre votre domaine, le sélecteur et le chemin de la clé.

Générer une clé DKIM

Créez un répertoire pour les clés et verrouillez-le :

cr0x@server:~$ sudo install -d -m 0750 -o rspamd -g rspamd /var/lib/rspamd/dkim

Générez une clé 2048 bits (baseline courante) :

cr0x@server:~$ sudo rspamadm dkim_keygen -b 2048 -s s2026 -d example.com -k /var/lib/rspamd/dkim/s2026.example.com.key > /tmp/s2026.example.com.txt
cr0x@server:~$ sudo chown rspamd:rspamd /var/lib/rspamd/dkim/s2026.example.com.key
cr0x@server:~$ sudo chmod 0640 /var/lib/rspamd/dkim/s2026.example.com.key

Ce que cela signifie : la clé privée est lisible par Rspamd ; pas par tout le monde ; pas par des démons aléatoires.

Décision : si vous êtes tenté de mettre les clés DKIM dans /etc avec des permissions lâches « pour que les sauvegardes les prennent », corrigez plutôt les sauvegardes. Les secrets ne deviennent pas moins secrets parce qu’ils sont gênants à gérer.

Configurer le module de signature DKIM

Créez /etc/rspamd/local.d/dkim_signing.conf :

cr0x@server:~$ sudo tee /etc/rspamd/local.d/dkim_signing.conf > /dev/null <<'EOF'
path = "/var/lib/rspamd/dkim/$selector.$domain.key";
selector_map = "/etc/rspamd/dkim_selectors.map";
key_map = "/etc/rspamd/dkim_keys.map";
signing_table = "/etc/rspamd/dkim_signing.map";
use_esld = false;
allow_username_mismatch = true;
EOF

Créez maintenant les trois petits fichiers de mapping. Restez explicite ; « l’auto-magie » est la façon de signer le mauvais domaine.

cr0x@server:~$ sudo tee /etc/rspamd/dkim_selectors.map > /dev/null <<'EOF'
example.com s2026
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_keys.map > /dev/null <<'EOF'
example.com /var/lib/rspamd/dkim/s2026.example.com.key
EOF
cr0x@server:~$ sudo tee /etc/rspamd/dkim_signing.map > /dev/null <<'EOF'
*@example.com example.com
EOF

Ce que cela signifie : tout courrier depuis @example.com est signé avec la clé du domaine example.com, sélecteur s2026.

Décision : si vous hébergez plusieurs domaines, ne réutilisez pas une clé unique pour tous les domaines. Ça marche techniquement ; c’est mauvais pour la délivrabilité et l’hygiène.

Redémarrer et vérifier que le module DKIM se charge

cr0x@server:~$ sudo rspamd -t
syntax OK
cr0x@server:~$ sudo systemctl restart rspamd
...output...
cr0x@server:~$ sudo journalctl -u rspamd -n 50 --no-pager
...output...

Décision : dans les logs, vous voulez l’absence d’erreurs DKIM. Si vous voyez « cannot load key », c’est généralement un chemin incorrect ou des permissions.

Actions et seuils : reject, add header, greylist

Rspamd peut effectuer de nombreuses actions. La configuration minimale : ajouter des en-têtes toujours, rejeter uniquement les spams à haute confiance, et traiter raisonnablement le courrier borderline.

Placez ceci dans /etc/rspamd/local.d/actions.conf :

cr0x@server:~$ sudo tee /etc/rspamd/local.d/actions.conf > /dev/null <<'EOF'
actions {
  add_header = 6.0;
  rewrite_subject = 8.0;
  reject = 15.0;
  greylist = 4.0;
}
EOF

Ce que cela signifie : en dessous de 4 c’est propre ; 4–6 greylist ; 6–8 ajoute en-tête ; 8–15 réécrit le sujet ; 15+ reject. Vos valeurs varieront. Cet ensemble tend à être tolérable pour un premier déploiement.

Décision : si votre organisation refuse toute latence pour le courrier, augmentez le seuil de greylist ou désactivez-le initialement. Le greylisting n’est pas une « précision gratuite » ; c’est un échange latence contre signal.

Blague n°2 : Le greylisting, c’est comme les achats en entreprise—tout finit par être approuvé, juste pas pendant que vous êtes encore en réunion.

Interface web : la sécuriser ou la désactiver

Le contrôleur UI est utile. C’est aussi une arme opérationnelle si vous l’exposez à l’Internet, car il peut modifier la configuration et déclencher des apprentissages selon les permissions.

Lier le contrôleur à localhost (défaut minimal sûr)

Dans beaucoup de paquets c’est déjà le cas. Vérifiez et imposez dans /etc/rspamd/local.d/worker-controller.inc :

cr0x@server:~$ sudo tee /etc/rspamd/local.d/worker-controller.inc > /dev/null <<'EOF'
bind_socket = "127.0.0.1:11334";
password = "$2$5$z0JwF4Tj9p7vVh2q3l8y8u3n7q9rHk0rHk0rHk0rHk0rHk0rHk0";
enable_password = "false";
EOF

Ce que cela signifie : le controller n’est accessible que localement. Le hash de mot de passe affiché est un exemple ; générez le vôtre avec rspamadm pw.

Générez un hash de mot de passe pour le contrôleur :

cr0x@server:~$ rspamadm pw -p 'ChangeThisNow'
$2$5$V1m0JwA3WcEoTg6hS2mY3uWJ5FzqKXHcGJ7x1VZy9uVw9d9QmGq2

Décision : si vous avez besoin d’accès distant, mettez-le derrière un tunnel SSH ou un VPN. Si vous insistez pour le lier à une interface publique, ajoutez des règles de pare-feu et une authentification forte. « Ce n’est qu’une UI » est la façon dont des inconnus modifient votre politique mail.

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

Cette section est le cœur : tâches concrètes que vous exécuterez le premier jour. Chacune inclut la signification de la sortie et la décision opérationnelle à prendre.

Tâche 1 : Confirmer quels workers Rspamd tournent

cr0x@server:~$ sudo rspamadm control stat
Uptime: 0 days, 00:03:21
Messages scanned: 122
Messages learned: 0
Connections: 18

Ce que cela signifie : l’analyse a lieu quelque part ; un « Messages scanned » non nul est bon signe.

Décision : si scanned est à zéro alors que le courrier circule, Rspamd est contourné. Allez directement vérifier le câblage milter de Postfix et les logs.

Tâche 2 : Vérifier que Postfix appelle bien le milter

cr0x@server:~$ sudo journalctl -u postfix -n 80 --no-pager | egrep -i 'milter|rspamd'
... postfix/smtpd[2140]: milter-connect: connect to unix:/run/rspamd/milter.sock: No such file or directory

Ce que cela signifie : Postfix a essayé et n’a pas pu se connecter. Le filtre est contourné (parce que nous avons réglé default_action=accept).

Décision : corrigez le chemin du socket ou assurez-vous que le worker/proxy rspamd est configuré pour le créer. Ne « résolvez » pas cela en passant à TCP sans comprendre pourquoi le socket manque.

Tâche 3 : Inspecter l’existence et la propriété du socket milter

cr0x@server:~$ sudo ls -l /run/rspamd/milter.sock
srwxrwx--- 1 rspamd rspamd 0 Jan  3 09:01 /run/rspamd/milter.sock

Ce que cela signifie : seuls le propriétaire et le groupe peuvent se connecter.

Décision : assurez-vous que Postfix a l’accès de groupe (ajout au groupe ou changement du mode via la config du worker). Ne mettez pas de 777 sur un système partagé.

Tâche 4 : Confirmer que Rspamd peut parler à Redis

cr0x@server:~$ sudo rspamadm configdump redis
servers = "unix:/run/redis/redis-server.sock";

Ce que cela signifie : Rspamd croit que Redis est sur ce socket.

Décision : si Redis est en TCP ou sur un autre socket, alignez-les. « Deux configs Redis » est une cause classique d’incident auto-infligé lors des redémarrages.

Tâche 5 : Vérifier rapidement la santé et la latence de Redis

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock ping
PONG
cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock --latency -i 1
min: 0, max: 1, avg: 0.22 (55 samples)

Ce que cela signifie : Redis répond ; la latence est basse. Si vous voyez des pics à dizaines/centaines de ms, Rspamd le percevra comme un ralentissement.

Décision : si la latence est élevée, vérifiez le IO disque, le swap et si Redis persiste de façon agressive. Corrigez la santé de l’hôte avant d’optimiser les règles anti-spam.

Tâche 6 : Tester l’analyse d’un message d’exemple localement

cr0x@server:~$ printf 'From: a@example.net\nTo: b@example.com\nSubject: test\n\nHello\n' | rspamc
Results for file: stdin (0.012 seconds)
[Metric: default]
Action: no action
Spam: false
Score: 0.30 / 15.00
Symbol: MIME_GOOD (-0.10)
Symbol: R_SPF_ALLOW (-0.20)
Symbol: R_DKIM_NA (0.60)

Ce que cela signifie : l’analyse fonctionne ; des symboles sont produits. DKIM est « NA » car il s’agit d’un inbound non signé.

Décision : si rspamc peut analyser mais que les en-têtes n’apparaissent pas dans le flux de courrier, votre intégration MTA est incorrecte, pas Rspamd.

Tâche 7 : Confirmer que des en-têtes sont ajoutés sur du courrier réel

cr0x@server:~$ sudo postqueue -p
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C1B23D4A1      1244 Sat Jan  3 09:10:05  alerts@example.com
                                         user@example.com
-- 1 Kbytes in 1 Request.

Ce que cela signifie : du courrier est en file d’attente ; ce n’est pas une preuve de filtrage.

Décision : récupérez un message livré et inspectez la présence d’en-têtes X-Spam- ou Authentication-Results. Si absent, Postfix n’a pas fait passer le message par le milter.

Tâche 8 : Vérifier que la signature DKIM a lieu sur le courrier sortant

cr0x@server:~$ sudo journalctl -u rspamd -n 120 --no-pager | egrep -i 'dkim|sign'
... rspamd[1827]: dkim_signing: sign example.com with selector s2026

Ce que cela signifie : Rspamd a tenté de signer ; bon signe.

Décision : si vous ne voyez jamais de logs de signature DKIM, confirmez que le courrier sortant traverse bien le milter (non_smtpd_milters importe pour les soumissions locales).

Tâche 9 : Générer l’enregistrement DNS à partir de la clé publique

cr0x@server:~$ sudo head -n 5 /tmp/s2026.example.com.txt
s2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." ) ;

Ce que cela signifie : c’est ce que vous publiez en DNS. Le sélecteur fait partie du label DNS.

Décision : tant que le DNS n’est pas publié et propagé, les récepteurs ne valideront pas DKIM. Ce n’est pas la faute de Rspamd ; c’est votre gestion du changement.

Tâche 10 : Vérifier le débit Rspamd et le temps par message

cr0x@server:~$ sudo rspamadm control stat | egrep 'Messages scanned|Uptime'
Uptime: 0 days, 00:08:44
Messages scanned: 486

Ce que cela signifie : des messages sont traités. Comparez le taux d’analyse à votre débit entrant.

Décision : si l’analyse prend du retard sur le volume entrant, vérifiez CPU, DNS et latence Redis avant d’ajuster le nombre de workers.

Tâche 11 : Identifier les règles lentes via les logs (approche symptôme)

cr0x@server:~$ sudo journalctl -u rspamd -n 200 --no-pager | egrep -i 'slow|timeout|lua'
... rspamd[1827]: rspamd_task_timeout: processing of task exceeded 8.0 seconds

Ce que cela signifie : Rspamd a atteint un timeout, souvent causé par DNS, vérifications HTTP, ou des ressources saturées.

Décision : si des timeouts surviennent en charge, vous échouez en pratique en mode « fail open ». Corrigez les dépendances (DNS/Redis/CPU) avant de durcir la politique milter.

Tâche 12 : Vérifier la vitesse de résolution DNS depuis l’hôte mail

cr0x@server:~$ time dig +tries=1 +timeout=1 mx gmail.com @127.0.0.53 | egrep 'status|Query time'
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59504
;; Query time: 18 msec
real	0m0.040s
user	0m0.010s
sys	0m0.004s

Ce que cela signifie : le DNS est rapide. Si le temps de requête est élevé ou s’il y a des timeouts, Rspamd ralentira et vous verrez des delays milter.

Décision : si le DNS est lent, corrigez le cache résolveur local ou la fiabilité des upstream. Le filtrage anti-spam génère beaucoup de requêtes DNS.

Tâche 13 : Vérifier que vos changements viennent bien de local.d (et ne sont pas ignorés)

cr0x@server:~$ sudo rspamadm configdump actions | head
actions {
    add_header = 6;
    greylist = 4;
    reject = 15;
    rewrite_subject = 8;
}

Ce que cela signifie : votre actions.conf est chargé.

Décision : si vous voyez d’autres valeurs, vous avez édité le mauvais fichier ou une autre override l’emporte. Corrigez l’empilement des configs avant de chasser un comportement fantôme.

Tâche 14 : Confirmer la version Rspamd et les options de compilation

cr0x@server:~$ rspamd --version
Rspamd 3.4

Ce que cela signifie : votre version en cours d’exécution. Cela compte parce que les defaults de modules et la syntaxe évoluent.

Décision : si vous êtes sur une version très ancienne, évitez les réglages poussés avant d’avoir planifié une montée de version. Vous ne voulez pas tuner autour de bugs.

Playbook de diagnostic rapide

Vous êtes d’astreinte. Le courrier est lent ou le spam passe. Vous avez dix minutes avant que quelqu’un ne propose de « simplement le désactiver ». Voici l’ordre qui trouve les goulots d’étranglement rapidement.

1) Le courrier est-il réellement scanné ?

Vérifiez les stats Rspamd : sudo rspamadm control stat. Si scanned reste plat alors que du courrier circule, le MTA bypass.
Consultez les logs Postfix pour les connexions/erreurs milter.

Interprétation : si c’est bypassé, ajuster les scores ne sert à rien. Réparez le câblage.

2) Le chemin milter est-il joignable depuis Postfix ?

Le socket existe ? ls -l /run/rspamd/milter.sock
Les permissions permettent à Postfix de se connecter ? Appartenance au groupe et mode.
Le chroot est-il en cause ? Si Postfix exécute smtpd en chroot, le socket doit exister à l’intérieur de ce chroot ou il faut désactiver le chroot pour ce service.

Interprétation : « connection refused » ou « no such file » est presque toujours un problème local de permissions/chemin, pas réseau.

3) Rspamd est-il lent parce qu’une dépendance est lente ?

Latence Redis : redis-cli --latency
Temps DNS : dig avec un timeout court et vérifiez le temps de requête
CPU et charge : top ou systemd-cgtop
Pression disque : si la persistance Redis bloque, vous verrez des pics de latence

Interprétation : les timeouts dans les logs Rspamd pointent en général vers DNS/vérifications HTTP ou des ressources saturées. Réparez la plateforme d’abord.

4) Rspamd agit, mais votre politique est-elle trop douce ?

Inspectez les symboles d’un échantillon spam : rspamc -h 127.0.0.1:11333 (ou défaut)
Vérifiez les seuils d’action via rspamadm configdump actions
Confirmez que Postfix ne supprime pas les en-têtes en aval (certains filtres le font)

Interprétation : si vous ajoutez toujours un en-tête mais ne rejetez jamais, les utilisateurs diront « le spam passe ». Ils ont raison ; vous n’avez simplement pas donné d’instruction forte à Postfix.

5) Ensuite seulement : ajuster les scores ou activer des modules supplémentaires

Une fois que vous faites confiance au pipeline et aux performances, ajustez les seuils et considérez des modules comme greylisting avancé, multimap, fuzzy et la cadence d’entraînement Bayes.

« L’espoir n’est pas une stratégie. » — Général James N. Mattis

Erreurs courantes : symptôme → cause → correction

1) « Rspamd tourne, mais aucun en-tête n’apparaît dans le courrier livré »

Symptôme : L’UI montre de l’activité, mais les messages en boîte ne comportent pas d’en-têtes X-Spam ; le spam passe inchangé.
Cause racine : Postfix n’utilise pas le milter pour ce chemin mail (souvent absence de non_smtpd_milters), ou le socket est inaccessible à cause des permissions/chroot.
Correction : Définissez à la fois smtpd_milters et non_smtpd_milters. Validez l’accessibilité du socket et les paramètres chroot de Postfix. Redémarrez Postfix et confirmez que les logs montrent des connexions milter réussies.

2) « Les logs Postfix montrent des timeouts milter ; le courrier est lent »

Symptôme : Les sessions SMTP stagnent ; le log Postfix mentionne un timeout milter ; les logs Rspamd montrent des timeouts de tâches.
Cause racine : lenteur du résolveur DNS, latence Redis, CPU surchargé, ou vérifications externes longues (modules type RBL basés sur HTTP).
Correction : Mesurez le temps de requête DNS, la latence Redis et la charge CPU. Corrigez le cache résolveur, la contention des ressources, ou réduisez les modules coûteux avant de modifier les timeouts.

3) « La signature DKIM ne se produit pas du tout »

Symptôme : Pas d’en-tête DKIM-Signature en sortie ; logs silencieux.
Cause racine : le courrier sortant ne traverse pas le milter (chemin de soumission contourné), ou les tables de signature ne correspondent pas au domaine de l’expéditeur.
Correction : Assurez-vous que non_smtpd_milters est défini. Vérifiez que les patterns de signing table correspondent aux adresses envoyées. Surveillez les logs pour les décisions de signature.

4) « Erreurs de signature DKIM : cannot load key »

Symptôme : Les logs Rspamd montrent des échecs de chargement de clé ; la signature est ignorée.
Cause racine : mauvais chemin de fichier dans les maps, combinaison sélecteur/domaine incorrecte, ou permissions trop restrictives (ou ownership erroné).
Correction : Confirmez que le chemin de la clé existe, que le propriétaire est rspamd, que le mode permet la lecture et que les maps pointent au bon endroit. Relancez rspamd -t.

5) « Tout est marqué spam après activation du greylisting »

Symptôme : Le courrier légitime est retardé ou tempfailed à répétition ; les plaintes commencent immédiatement.
Cause racine : seuils de greylist trop bas, ou vous greylistez des relais internes et des expéditeurs SaaS qui ne retentent pas selon le pattern attendu.
Correction : Augmentez le seuil de greylist, mettez en liste blanche les expéditeurs connus, ou désactivez le greylisting jusqu’à ce que vous puissiez modéliser correctement le comportement des expéditeurs.

6) « Rspamd fonctionne pour l’entrée, mais la sortie est rejetée par les destinataires »

Symptôme : Les rebonds des destinataires citent DMARC/DKIM failures ; votre courrier semble non authentifié.
Cause racine : DKIM ne signe pas, enregistrement selector DNS manquant, ou le domaine From n’est pas celui que vous signez.
Correction : Publiez l’enregistrement DKIM en DNS, validez la signature pour le bon domaine, et assurez-vous que SPF/DMARC ne sont pas brisés par une réécriture du champ From en aval.

7) « L’UI controller accessible depuis Internet »

Symptôme : Un scan de sécurité signale le port 11334 ouvert ; vous observez des changements de config ou des événements d’apprentissage étranges.
Cause racine : le controller est lié à 0.0.0.0 sans pare-feu ni authentification.
Correction : Liez le controller à localhost ; exigez un mot de passe ; utilisez un tunnel SSH/VPN pour l’accès. Traitez-le comme une interface d’administration, car c’en est une.

Checklists / plan étape par étape

Checklist : configuration minimale initiale (hôte unique)

Installer rspamd et redis-server.
Confirmer que les deux services tournent sous systemd.
Configurer Redis via /etc/rspamd/local.d/redis.conf pour utiliser un socket local.
Veiller à ce que l’utilisateur rspamd puisse accéder au socket Redis (appartenance au groupe).
Trouver ou activer le socket milter Rspamd.
Configurer Postfix smtpd_milters et non_smtpd_milters pour utiliser ce socket.
S’assurer que Postfix peut accéder au socket milter (permissions, chroot).
Définir des seuils d’action minimaux dans local.d/actions.conf.
Générer les clés DKIM et configurer dkim_signing.conf ainsi que les maps.
Redémarrer Rspamd ; valider la config avec rspamd -t.
Recharger Postfix ; confirmer que les connexions milter réussissent dans les logs.
Scanner un message d’exemple avec rspamc et inspecter un message réellement livré pour les en-têtes.

Checklist : durcissement production « ship it » (après que ça marche)

Décider fail-open vs tempfail pour les pannes milter (milter_default_action).
Lier le controller à localhost et définir des hashes de mot de passe forts.
Configurer la rétention des logs et une alerte simple sur les pannes/timeouts milter répétés.
Documenter la politique de rotation des sélecteurs DKIM (même « rotation annuelle » suffit).
Définir un workflow d’entraînement ham/spam et désigner les responsables.
Enregistrer les latences de référence : temps de tâche Rspamd, latence Redis, temps de requête DNS.

Trois mini-histoires du monde de l’entreprise

Incident causé par une mauvaise hypothèse : « C’est configuré, donc ça doit filtrer »

L’entreprise était en pleine migration : ancien mail on-prem vers une nouvelle pile VM. Ils ont installé Rspamd, activé Redis, généré des clés DKIM et même joint une belle capture d’écran du dashboard dans le ticket de changement. Tout le monde a poursuivi son travail.

Deux semaines plus tard, l’équipe sécurité a escaladé : le volume de phishing augmentait et les rapports utilisateurs étaient étrangement cohérents. Les admins mail ont juré que le nouveau filtre était en place. Après tout, le service tournait et rspamc fonctionnait.

La mauvaise hypothèse était subtile : ils pensaient que « Rspamd tourne » impliquait « le courrier est scanné ». Postfix était configuré avec smtpd_milters mais pas non_smtpd_milters. La plupart des mails sortants et une partie du trafic interne étaient injectés localement par une application via sendmail et n’ont jamais transité par le démon smtpd.

Pire, ils avaient milter_default_action=accept. Donc même quand le chemin socket était incorrect sur un hôte, le courrier continuait de circuler. C’était une dégradation graduelle en contournement complet.

La correction fut ennuyeuse : appliquer le milter aux deux chemins, vérifier les connexions milter réussies dans les logs Postfix, et ajouter une vérification quotidienne « messages scanned » qui augmente avec le trafic. Ils ont aussi ajouté un canari basé sur en-tête : un petit message interne qui doit toujours recevoir un certain en-tête Rspamd, et une alerte si ce n’est pas le cas.

Une optimisation qui s’est retournée contre eux : « Déplaçons Redis hors hôte pour économiser un saut »

Une autre organisation, avec une équipe plateforme forte, a centralisé l’état. Ils ont déplacé Redis de chaque hôte mail vers un « cluster cache » partagé parce que « c’est plus efficace ». Le réseau était rapide. La latence semblait correcte en tests synthétiques.

Puis est venu le lundi. Des pics de trafic plus quelques clients Redis non liés ont provoqué des pics de latence intermittents. Pas assez pour déclencher des alarmes Redis—juste assez pour que des tâches Rspamd dépassent leur budget temps. Les sessions Postfix ont commencé à s’accumuler. Les clients SMTP ont retenté. Le volume a augmenté. Le système est entré dans la spirale familière : retentatives créent de la charge, la charge crée des timeouts, les timeouts créent des retentatives.

L’équipe mail a augmenté les timeouts Rspamd pour « stabiliser ». Cela a réduit les blocages SMTP mais augmenté les files et la pression mémoire. La délivrabilité a souffert car le courrier arrivait en retard. Les utilisateurs ont blâmé le filtre. Techniquement, ils n’avaient pas tort ; opérationnellement, c’était la chaîne de dépendances.

La résolution a été de remettre Redis localement pour l’état d’analyse mail (ou au moins utiliser des réplicas locaux). Centraliser l’état était acceptable pour certaines apps ; pour la chaîne mail, une latence faible et prévisible valait plus que l’efficacité théorique. L’optimisation a sauvé un serveur et acheté un mois de douleur intermittente.

La pratique ennuyeuse mais correcte qui a sauvé la journée : « empilement de config et source unique de vérité »

Une société du secteur financier avait la gouvernance que l’on moque—jusqu’à ce qu’elle paye. Règle stricte : pas d’édition des configs du fournisseur. Tous les changements allaient dans local.d, et chaque fichier était géré via un système de déploiement avec revue.

Pendant une mise à jour OS de routine, le paquet Rspamd a mis à jour des valeurs par défaut. Dans beaucoup d’équipes, c’est là que commence le « pourquoi le scoring a changé ? ». Ici, la mise à jour s’est déroulée, Rspamd a redémarré et le courrier a continué de circuler. Quelques symboles ont changé de comportement, mais les actions principales et la signature DKIM sont restées stables parce que les overrides locaux étaient intacts.

Puis un incident réel est survenu : le courrier sortant échouait DKIM pour un domaine. Parce que la configuration était en couches et suivie, ils ont pu rapidement faire un diff des maps DKIM et ont trouvé un domaine récemment ajouté avec une faute de frappe dans la signing table. Correction, redémarrage, terminé.

Ce qui les a sauvés n’était pas une règle Lua sophistiquée. C’était la discipline peu glamour de garder la politique locale séparée des defaults packagés, plus la capacité de raisonner sur les changements. Dans les systèmes mail, l’ennuyeux est une fonctionnalité.

FAQ

1) Ai-je besoin de Redis pour une configuration « minimale » ?

Si vous voulez une démonstration de scanner, non. Si vous voulez un système opérationnel que vous pouvez déboguer et améliorer, oui. Redis stocke l’état utile de Rspamd.

2) Dois-je utiliser des sockets UNIX ou TCP pour le milter ?

Sur un hôte unique : sockets UNIX. Moins de questions de pare-feu, moins de latence, permissions plus claires. Utilisez TCP quand vous avez réellement besoin d’une séparation réseau, et alors traitez-le comme un projet d’intégration, pas comme un raccourci.

3) Pourquoi je vois « Rspamd is running » mais le compteur scanned reste à zéro ?

Parce que rien ne l’appelle. Vérifiez que les milters Postfix sont définis, que le socket existe et que Postfix peut se connecter. Utilisez les logs ; ne comptez pas sur des impressions.

4) Quelle est la valeur la plus sûre pour `milter_default_action` ?

accept est la plus sûre pour la disponibilité ; tempfail est plus sûre pour la posture de sécurité. Choisissez en connaissance de cause. Si vous optez pour accept, ajoutez une surveillance qui alerte fortement quand le milter est tombé.

5) Ai-je besoin d’entraînement Bayes dès le premier jour ?

Non. Assurez-vous d’abord que l’analyse, les actions et DKIM sont corrects. Bayes aide une fois que vous avez une classification stable et un workflow pour fournir des exemples bons/mauvais.

6) Pourquoi la signature DKIM est configurée mais les récepteurs montrent toujours « DKIM=fail » ?

Le plus souvent : enregistrement DNS non publié, mauvais sélecteur en DNS, signature du mauvais domaine, ou modification du message après signature (certains filtres réécrivent les en-têtes). Vérifiez l’ordre dans votre pipeline.

7) Puis-je exposer l’UI controller sur une interface publique si je mets un mot de passe ?

Vous pouvez, comme on peut garder des sauvegardes sur une clé USB étiquetée « NE PAS PERDRE ». Liez à localhost et accédez via tunnel SSH/VPN. Faites en sorte que le chemin sûr soit aussi le plus simple.

8) Quel est l’ensemble minimal de seuils avec lequel commencer ?

Commencez avec un seuil de reject conservateur (élevé), add-header à un niveau modéré, et considérez les tactiques de délai (greylist) seulement après avoir mesuré l’impact métier. L’exemple dans actions.conf est un bon point de départ.

9) Comment savoir quelle règle a causé un rejet ?

Inspectez les symboles et le score depuis les en-têtes du message ou en scannant avec rspamc. L’intérêt du modèle Rspamd est l’explicabilité—utilisez-la.

10) Dois-je déployer Rspamd en proxy SMTP plutôt qu’en milter ?

Pas pour un « premier déploiement minimal ». Ça peut être excellent, mais ajoute de la complexité de routage et un plus grand rayon d’impact si mal configuré. Stabilisez d’abord la chaîne milter.

Prochaines étapes à faire réellement

Vous avez maintenant une configuration minimale qui fonctionne, selon la seule définition qui importe : le courrier est scanné, des actions sont appliquées, DKIM signe la sortie et vous pouvez déboguer rapidement les pannes.

Prouvez le pipeline quotidiennement : créez un canari mail simple et alertez si les en-têtes Rspamd attendus n’apparaissent pas.
Décidez de votre stance en cas de panne : gardez accept ou passez à tempfail une fois les performances et dépendances stables.
Publiez les enregistrements DNS DKIM et vérifiez-les depuis l’extérieur (côté récepteur) avant de déclarer victoire.
Mesurez la latence en charge : latence Redis, temps de requête DNS et temps de tâche Rspamd. Quand le courrier est lent, ces trois indicateurs montrent où chercher.
Ensuite seulement : ajustez le scoring : modifiez les seuils en vous basant sur de vrais faux positifs/négatifs, pas sur les anecdotes de la boite mail d’un dirigeant.

Si vous voulez que le système reste opérationnel, traitez-le comme une partie du transport mail, pas comme un accessoire. Les filtres ne tombent pas bruyamment ; ils échouent silencieusement. Votre travail est de rendre le silence impossible.