Faux positifs Rspamd : régler le scoring anti-spam sans laisser passer les indésirables

Le modèle mental : actions, symboles et pourquoi surviennent les faux positifs

Rspamd ne « décide » pas qu’un message est du spam. Il additionne des signaux. Chaque signal est un symbole avec un score. Le score total se traduit par une action : rien, ajout d’en-tête, greylist, réécriture du sujet, rejet, ou mise en quarantaine (selon votre politique).

Les faux positifs proviennent généralement de l’un des quatre endroits suivants :

1. Mauvaises hypothèses sur les seuils. Quelqu’un a mis reject = 6 parce que « 6 semble bien », puis a oublié qu’un DKIM cassé plus un coup de réputation peuvent faire exploser un bulletin d’information propre.
2. Un symbole avec un score disproportionné. Une regexp personnalisée censée détecter « facture jointe » frappe maintenant chaque mention de « facture », y compris celles de votre propre équipe de facturation.
3. Authentification mal alignée. SPF passe pour un domaine, DKIM signe pour un autre, DMARC échoue, et le message encaisse un coup de scoring qu’il ne mérite pas — particulièrement pour les transferts et les listes de diffusion.
4. Dérive de l’entraînement et de la réputation. Bayes entraîné sur le mauvais dossier ; fuzzy hashes ayant appris un motif qui correspond à des modèles légitimes ; sources de réputation historiques qui ont changé de comportement.

Voici la discipline : vous ajustez les symboles, pas les impressions. Vous ajustez par classe de trafic, pas pour tout l’Internet. Et vous ne « corrigez les faux positifs » en faisant simplement monter les seuils jusqu’à ce que le spam gagne.

Une vérité sèche des opérations : « On va juste augmenter le seuil de rejet » est l’équivalent email d’éteindre une alarme incendie en retirant les piles. Ça marche jusqu’à ce que ça ne marche plus du tout.

Et une citation à garder près de soi. Werner Vogels a une idée paraphrasée qui est de l’or opérationnel : tout échoue, alors concevez pour l’échec comme une condition normale. Appliquez cela ici : supposez que certaines règles seront fausses, et construisez un processus qui les détecte et les corrige rapidement.

Faits et contexte qui comptent vraiment en production

Six à dix points de contexte rapides, parce que les systèmes en production sont construits sur l’histoire qu’on le veuille ou non :

• Fait 1 : Rspamd a été conçu comme remplacement haute performance pour des filtres monolithiques plus anciens, utilisant un moteur de règles modulaire et de l’E/S asynchrone pour garder la latence prévisible sous charge.
• Fait 2 : Le modèle « symbole » est volontairement transparent comparé à beaucoup de filtres purement ML : vous pouvez expliquer pourquoi un message a obtenu 9,3, ce qui compte quand le service juridique appelle.
• Fait 3 : Le greylisting fut autrefois une victoire quasi gratuite parce que les anciens bots de spam ne retentaient pas correctement ; l’infrastructure de spam moderne retente bien, donc le greylisting est désormais une décision de politique, pas un code de triche.
• Fait 4 : L’adoption de DMARC a changé le paysage du scoring : l’échec d’alignement n’est pas automatiquement malveillant, mais il corrèle fortement avec l’abus — surtout pour les domaines qui imitent d’autres.
• Fait 5 : Les listes de diffusion cassent historiquement DKIM parce qu’elles modifient les en-têtes/corps ; « DKIM fail » peut signifier « liste de diffusion » plus souvent que « spam ».
• Fait 6 : Autolearn (entraînement automatique Bayes) a été une source de douleur auto-infligée dans plusieurs systèmes anti-spam, pas seulement Rspamd, parce que des attaquants peuvent pousser votre modèle avec des contenus limites.
• Fait 7 : Redis est devenu le magasin de backing de facto pour plusieurs modules Rspamd (Bayes, fuzzy, ratelimit, etc.) parce que les recherches à faible latence comptent plus que la persistance complexe.
• Fait 8 : Le parsing MIME et l’extraction d’URL sont des points chauds permanents ; les régressions de performance apparaissent souvent comme des « faux positifs » parce que les timeouts changent quels contrôles s’exécutent.
• Fait 9 : Le « mail en masse légitime » est opérationnellement plus proche du spam que du mail personnel. Traitez-le comme sa propre classe de trafic avec sa propre politique.

Playbook de diagnostic rapide : repérer le goulot en quelques minutes

Quand quelqu’un dit « Rspamd bloque du mail légitime », vous ne commencez pas par éditer des scores. Vous commencez par prouver ce qui se passe.

Première étape : confirmer quelle action a eu lieu et pourquoi

• Extraire le résultat Rspamd du message (depuis les en-têtes, les logs ou le controller).
• Identifier les 3 symboles ayant le plus contribué au score.
• Vérifier si l’action (reject/quarantine/greylist) correspond à la politique pour cette classe de trafic.

Deuxième étape : vérifier si c’est un changement systémique ou un seul expéditeur

• Comparer la fréquence des symboles et les scores moyens d’aujourd’hui vs hier.
• Rechercher une montée soudaine d’un symbole (par ex. un DNSBL ou un symbole d’alignement DMARC).
• Valider la santé du DNS : les timeouts sont des modificateurs silencieux du scoring parce qu’ils changent les contrôles exécutés.

Troisième étape : vérifier la plomberie (Rspamd et dépendances)

• Les workers Rspamd sont-ils sains ? Pas de boucles de crash ? Pas d’arriérés ?
• Latence et évictions Redis ? (la perte de données Bayes/fuzzy peut changer le comportement.)
• Performance et exactitude du résolveur DNS.

Quatrième étape : appliquer la plus petite correction possible

• Si un symbole est erroné, ajustez ce symbole ou scindez-le (par domaine, par IP, par expéditeur).
• Si l’alignement d’authentification est bruyant, ajustez ces symboles sans les neutraliser.
• Si vous devez assouplir les actions, faites-le temporairement et associez-le à un contrôle compensatoire (quarantaine au lieu de rejet ; ajout d’en-têtes et surveillance).

Tâches pratiques : commandes, sorties et étapes suivantes

Voici le type de tâches que vous exécutez pendant un incident ou une session de réglage. Chaque tâche inclut une commande, un extrait réaliste de sortie, ce que cela signifie et la décision à prendre ensuite.

Tâche 1 : Confirmer que Rspamd tourne et quelle version vous ajustez

cr0x@server:~$ systemctl status rspamd --no-pager
● rspamd.service - Rspamd rapid spam filtering system
     Loaded: loaded (/lib/systemd/system/rspamd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-03 08:41:12 UTC; 2h 13min ago
   Main PID: 1342 (rspamd)
      Tasks: 18 (limit: 18910)
     Memory: 212.4M
        CPU: 7min 11.402s

Ce que cela signifie : Il est actif. S’il oscille, vous ne réglez pas le scoring — vous réparez la fiabilité.

Décision : Si stable, poursuivre la collecte de preuves. Si instable, arrêter et corriger les crashes/reloads de config d’abord.

Tâche 2 : Inspecter les seuils d’action et confirmer que vous n’avez pas hérité d’un piège

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

Ce que cela signifie : Greylist à 4 est agressif ; add_header à 6 est acceptable ; reject à 15 est conservateur. Si vos faux positifs sont des rejets avec reject=15, quelques symboles sont probablement surpondérés ou un bug est présent.

Décision : Si reject est bas (par ex. 6–8), considérez-le comme un contributeur probable et orientez-vous vers la quarantaine/ajout d’en-tête tout en affinant les symboles.

Tâche 3 : Extraire le résultat d’un message spécifique depuis les logs (par queue ID)

cr0x@server:~$ grep -F "q1bC7R2kQz" /var/log/rspamd/rspamd.log | tail -n 1
2026-01-03 10:55:21 #1342(normal) <9c1f0b>; task; rspamd_task_write_log: id: <q1bC7R2kQz@mail.example>, qid: q1bC7R2kQz, ip: 203.0.113.44, from: <billing@vendor.example>, (default: F (no action): [8.11/15.00] [DMARC_POLICY_REJECT(3.50){vendor.example;reject;},DKIM_REJECT(2.00){fail;},R_SPF_FAIL(1.80){-all;},MANY_INVISIBLE_PARTS(0.80){2;},MIME_HTML_ONLY(0.20){},ARC_NA(0.10){},ASN(0.01){AS64500;}] len: 48712, time: 110.2ms real, 36.7ms virtual, dns req: 18, digest: <d2c7...>, mime_rcpts: <ap@yourco.example>

Ce que cela signifie : Non rejeté, mais score 8.11. Les principaux moteurs sont DMARC policy reject + DKIM fail + SPF fail. Ce n’est pas « aléatoire » ; c’est une défaillance d’alignement/authentification.

Décision : Ne baissez pas globalement les scores DMARC/DKIM/SPF. Vérifiez si l’expéditeur est mal configuré, si le forwarding a cassé SPF, ou si vous recevez via une passerelle qui réécrit le mail.

Tâche 4 : Analyser les pics de fréquence des symboles (vérification de tendance rapide)

cr0x@server:~$ awk -F'[][]' '/rspamd_task_write_log/ {print $4}' /var/log/rspamd/rspamd.log | \
tr ',' '\n' | sed 's/(.*//' | awk '{print $1}' | sort | uniq -c | sort -nr | head
  4821 R_DKIM_ALLOW
  3912 R_SPF_ALLOW
  1104 MIME_HTML_ONLY
   988 DMARC_POLICY_REJECT
   811 R_SPF_FAIL
   620 DKIM_REJECT
   507 MANY_INVISIBLE_PARTS

Ce que cela signifie : DMARC_POLICY_REJECT et DKIM_REJECT sont élevés. Soit vous recevez un ciblage de spoofing (possible), soit quelque chose a changé dans les contrôles d’authentification (également possible).

Décision : Corrélez avec des changements DNS, des modifications du chemin MTA, ou l’intégration d’un fournisseur. Si un seul fournisseur déclenche, appliquez une correction par expéditeur/domaine plutôt que d’émousser les règles globales.

Tâche 5 : Vérifier la santé du résolveur DNS depuis l’hôte Rspamd

cr0x@server:~$ resolvectl statistics
Transactions               Current Transactions  0
Cache                       Cache Size           4632
Cache                       Cache Hits           191022
Cache                       Cache Misses         22114
DNSSEC Verdicts             Secure               0
DNSSEC Verdicts             Insecure             0
DNSSEC Verdicts             Bogus                0

Ce que cela signifie : Si les misses du cache explosent et que la latence augmente, Rspamd peut expirer les contrôles basés sur DNS (SPF, clés DKIM, DNSBL), changeant le comportement de scoring et parfois créant des faux positifs ou des actions incohérentes.

Décision : Si le DNS est malade, corrigez le DNS d’abord. Ajuster les scores dans un environnement dégradé, c’est ancrer la panne dans la politique.

Tâche 6 : Mesurer la latence Redis et la pression mémoire

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO stats | egrep 'instantaneous_ops_per_sec|keyspace_hits|keyspace_misses'
instantaneous_ops_per_sec:1420
keyspace_hits:982211
keyspace_misses:44102

cr0x@server:~$ redis-cli -s /run/redis/redis-server.sock INFO memory | egrep 'used_memory_human|maxmemory_human|evicted_keys'
used_memory_human:1.62G
maxmemory_human:2.00G
evicted_keys:18219

Ce que cela signifie : Les évictions signifient que vous oubliez des choses. Bayes et fuzzy peuvent se dégrader de façon imprévisible si Redis éjecte constamment l’état.

Décision : Arrêtez le réglage tant que Redis n’a pas de marge. Ajoutez de la mémoire, ajustez maxmemory policy, ou déplacez Bayes/fuzzy vers une instance Redis dédiée.

Tâche 7 : Utiliser rspamc pour analyser un message suspect (à partir d’un fichier sauvegardé)

cr0x@server:~$ rspamc -h /run/rspamd/rspamd.sock symbols /tmp/suspect.eml
Results for file: /tmp/suspect.eml (0.221 seconds)
Symbol: DMARC_POLICY_REJECT (score: 3.50)
Symbol: DKIM_REJECT (score: 2.00)
Symbol: R_SPF_FAIL (score: 1.80)
Symbol: MIME_HTML_ONLY (score: 0.20)
Message-ID: <1c9f...@vendor.example>
Action: no action
Spam: false
Score: 7.50 / 15.00

Ce que cela signifie : Vous pouvez reproduire le score en dehors du MTA. C’est essentiel pour un réglage sûr.

Décision : Si reproductible, modifiez la config et retestez sur le même corpus avant déploiement.

Tâche 8 : Dumper le score configuré d’un symbole et son groupe

cr0x@server:~$ rspamadm configdump --path scores | egrep 'DMARC_POLICY_REJECT|DKIM_REJECT|R_SPF_FAIL'
DMARC_POLICY_REJECT = 3.5;
DKIM_REJECT = 2;
R_SPF_FAIL = 1.8;

Ce que cela signifie : Confirme que vous ne poursuivez pas des fantômes ; ce sont des poids réels, pas « dynamiques ».

Décision : Si vous devez réduire la douleur, préférez le cloisonnement (par domaine/expéditeur) plutôt que de réduire ces valeurs globalement.

Tâche 9 : Inspecter les overrides de politique par domaine (source fréquente de surprises)

cr0x@server:~$ rspamadm configdump --path settings
settings {
    yourco.example {
        priority = high;
        apply {
            actions {
                reject = 12;
            }
        }
    }
}

Ce que cela signifie : Quelqu’un a abaissé le seuil de rejet uniquement pour votre domaine principal (ou l’a augmenté, etc.). C’est souvent intentionnel, parfois oublié.

Décision : Validez si cela correspond aux exigences métier. Si l’override existe, documentez-le et assurez-vous que la surveillance correspond à cette politique spéciale.

Tâche 10 : Vérifier les hits multimap allowlist (pour voir si vous utilisez du pansement)

cr0x@server:~$ grep -F "MULTIMAP" /var/log/rspamd/rspamd.log | tail -n 3
2026-01-03 10:52:11 #1342(normal) <7a2e1c>; lua; multimap.lua: MULTIMAP_ALLOWLIST_DOMAIN hit for domain vendor.example
2026-01-03 10:54:40 #1342(normal) <11bd77>; lua; multimap.lua: MULTIMAP_ALLOWLIST_IP hit for ip 198.51.100.9
2026-01-03 10:54:45 #1342(normal) <1f33a9>; lua; multimap.lua: MULTIMAP_ALLOWLIST_FROM hit for from billing@vendor.example

Ce que cela signifie : Vous bypassiez déjà certains contrôles pour certains expéditeurs. Ça peut être acceptable, mais c’est un item du registre des risques, pas une victoire définitive.

Décision : Si l’allowlisting est abondante, réduisez son champ : préférez l’allowlist basée sur DKIM ou restreignez par plages IP que vous contrôlez, et fixez des revues d’expiration.

Tâche 11 : Valider que votre configuration se recharge proprement

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

Ce que cela signifie : Vous n’avez pas cassé le parsing. Cela ne prouve pas que votre politique est bonne. Ça prouve que vous ne ferez pas planter les workers.

Décision : Après configtest OK, lancez le reload. Sinon vous déboguez la prod les yeux bandés.

Tâche 12 : Recharger Rspamd sans redémarrer toute la machine

cr0x@server:~$ systemctl reload rspamd

cr0x@server:~$ journalctl -u rspamd -n 5 --no-pager
Jan 03 11:02:10 server rspamd[1342]: config reloaded successfully
Jan 03 11:02:10 server rspamd[1342]: workers state: normal workers: 4

Ce que cela signifie : Le reload a réussi ; les workers sont restés en place.

Décision : Vérifiez immédiatement le scoring sur un corpus de test et surveillez les taux de rejet/quarantaine pendant l’heure suivante.

Tâche 13 : Confirmer que le MTA reçoit les en-têtes de résultat Rspamd

cr0x@server:~$ postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5    48211 Thu Jan  3 11:03:12  billing@vendor.example
                                         ap@yourco.example

cr0x@server:~$ postcat -q A1B2C3D4E5 | egrep -i 'X-Spam|X-Rspamd|Authentication-Results' | head -n 20
X-Spam-Status: No, score=7.50 required=15.00
X-Spam-Action: no action
X-Spam-Score: 7.50
X-Spam-Level: *******
Authentication-Results: mx.yourco.example; dkim=fail header.d=vendor.example; spf=fail smtp.mailfrom=billing@vendor.example; dmarc=fail header.from=vendor.example

Ce que cela signifie : Les en-têtes confirment la même histoire. Si les en-têtes manquent, vos faux positifs pourraient être un problème de politique MTA, pas de Rspamd.

Décision : Si le MTA agit sur un signal différent de celui attendu (par ex. milters, vérifications d’en-têtes), alignez le pipeline avant de toucher le scoring Rspamd.

Tâche 14 : Suivre les comptes d’actions sur un intervalle court

cr0x@server:~$ grep -oE 'default: [^ ]+ \([^)]*\)' /var/log/rspamd/rspamd.log | tail -n 2000 | sort | uniq -c | sort -nr
  1602 default: F (no action)
   287 default: R (reject)
    91 default: G (greylist)
    20 default: A (add header)

Ce que cela signifie : Les rejets sont relativement élevés. Que ce soit « mauvais » dépend de votre mix de trafic. Pour du mail d’entreprise, 287 rejets sur les 2000 dernières décisions consignées vaut la peine d’être investigué.

Décision : Échantillonnez 20 rejets. S’ils sont majoritairement du spam évident, ok. S’ils incluent des expéditeurs légitimes, trouvez les symboles récurrents et corrigez-les spécifiquement.

Blague 1 : L’email est le seul produit où « délivrabilité » signifie « s’il vous plaît, laissez cette personne être interrompue par mon message. »

Une stratégie de scoring sensée : changer moins, mesurer plus

Quand vous ajustez pour réduire les faux positifs, vous négociez entre deux modes d’échec :

• Type I : spam livré (agaçant, risqué)
• Type II : mail légitime bloqué (rupture d’activité)

La plupart des organisations affirment craindre davantage le spam. En réalité elles redoutent de manquer un vrai email, parce que cela déclenche une dysfonction visible. Votre politique devrait reconnaître cette réalité et la codifier.

Choisir les actions selon le blast radius métier

Actions communes et leur comportement dans le monde réel :

• add_header : le défaut le plus sûr pour le « peut-être spam ». Ça laisse le mail arriver tout en permettant aux utilisateurs et aux SIEMs de voir le score. Inconvénient : les utilisateurs ignoreront les en-têtes jusqu’à ce que vous les formiez (ou que vous routiez selon les en-têtes).
• greylist : acceptable pour les expéditeurs inconnus, mais pénible pour les systèmes automatisés qui ne retentent pas correctement. À utiliser quand vous tolérez des délais et que vos expéditeurs légitimes se comportent comme de vrais MTAs.
• quarantine : l’alternative adulte au rejet pour le spam de confiance moyenne. Réduit le dommage des faux positifs tout en tenant le junk hors des boîtes de réception.
• reject : réservé aux cas de haute confiance. Si vous rejetez du mail de faible confiance, vous avez construit un générateur d’incidents qui se déclenche au hasard.

Changer le scoring comme on change des règles de firewall

Quatre règles pour rester sérieux :

1. Faire un changement à la fois sauf si vous annulez un déploiement connu mauvais.
2. Préférer le cloisonnement aux changements globaux : par domaine, par destinataire, par IP, par utilisateur authentifié.
3. Conserver un corpus de test : au moins 50 messages légitimes et 200 messages malveillants connus (ou ce qui convient à votre environnement). Re-scorez avant/après.
4. Consigner la décision : pourquoi vous avez changé un symbole et quelle métrique vous attendez de voir évoluer.

Où se cachent généralement les faux positifs : les bons mails qui semblent spam

Messages légitimes qui accumulent souvent des signaux spammy :

• Fournisseurs envoyant des factures depuis une nouvelle plateforme (nouvelles IP, auth non alignée)
• Newsletters marketing (beaucoup d’URL, tracking, HTML-only, motifs bulk)
• Alertes de sécurité (texte court + sujet alarmant + liens)
• Invitations calendrier et notifications automatiques (structures MIME étranges)
• Mail transféré (SPF casse ; DMARC échoue sauf si ARC est bien utilisé)

Le but n’est pas de prétendre que ce sont des « mails personnels ». Le but est de les identifier et de les traiter comme une catégorie avec une politique dédiée.

Outils de réglage ciblé : multimap, groupes et politique par domaine

Le réglage ciblé est la manière de réduire les faux positifs sans abaisser la défense contre le spam. Dans Rspamd, vous disposez de trois leviers pratiques :

• Settings (par domaine/utilisateur/IP/destinataire) pour ajuster les actions, appliquer des changements de symboles ou sauter des vérifications.
• Multimap pour les allowlists/blocklists basées sur les en-têtes, l’enveloppe, l’IP ou d’autres sélecteurs.
• Scores de symboles et groupes pour maintenir l’équilibre entre contrôles liés (auth, contenu, réputation).

Préférer « adoucir » plutôt que « désactiver »

Désactiver des contrôles est tentant et généralement une erreur. Si les échecs DMARC causent des faux positifs pour un partenaire spécifique parce qu’il a mal configuré son mail, vous avez des choix :

• Demandez-leur de corriger. (Oui, vous pouvez. Les fournisseurs répondent plus vite quand les factures n’arrivent plus.)
• Réduire temporairement la pénalité pour ce partenaire uniquement.
• Mettre en quarantaine plutôt que rejeter pour cette classe de mail jusqu’à correction de l’auth.

Exemple : settings par domaine pour éviter de rejeter des mails limites

Pour un domaine à fort impact métier (par ex. le vôtre), vous pouvez choisir de quarantaine à un score inférieur au rejet, en réservant les rejets au spam vraiment évident.

Pratique clé : utilisez des overrides pour les actions, pas l’allowlisting total. Laissez le système scorer ; changez seulement ce que vous faites du résultat.

Exemple : multimap allowlist avec garde-fous

Si vous devez allowlister, faites-le en favorisant l’identité vérifiable :

• Allowlistez un domaine signé DKIM stable que vous faites confiance (et vérifiez sa stabilité).
• Allowlistez une plage IP seulement si l’expéditeur la publie et si ce n’est pas une infrastructure partagée.
• Évitez l’allowlisting par champ « From: » affiché sauf si vous aimez vous faire phisher.

Blague 2 : Le moyen le plus rapide d’obtenir un budget pour le filtrage anti-spam est de laisser passer un phishing et d’appeler ça une « initiative de formation des utilisateurs ».

Authentification et alignement : SPF, DKIM, DMARC sans cargo cult

Beaucoup de faux positifs sont en réalité des problèmes de « désaccord d’authentification ». Vous ne pouvez pas régler proprement un écosystème d’expéditeurs cassé en changeant le scoring. Mais vous pouvez comprendre les modes de défaillance et choisir des politiques qui réduisent les dommages collatéraux.

SPF : efficace jusqu’au forwarding

SPF vérifie l’IP de connexion par rapport à la politique du domaine expéditeur. Le forwarding casse SPF parce que l’IP du serveur de transfert n’est pas autorisée par l’expéditeur original. Ce n’est pas Rspamd qui est méchant ; c’est le fonctionnement de SPF.

Décision opérationnelle : si votre environnement transfère beaucoup de mails (alias vers des systèmes externes, outils de ticketing, etc.), ne traitez pas SPF fail comme un signal proche du rejet. Gardez-le signifiant, mais équilibré.

DKIM : survit au forwarding mais casse sur modification

DKIM signe le contenu du message. Les listes de diffusion, les pieds de page et les passerelles qui réécrivent l’HTML peuvent casser DKIM. Vous verrez des pics de DKIM fail quand un serveur de liste change son comportement ou quand un appliance de sécurité commence à « sanitiser » le contenu.

Décision opérationnelle : un DKIM fail doit être un signal fort combiné à du contenu suspect ou des indicateurs de spoofing, pas un marteau isolé.

DMARC : l’alignement est l’essentiel, et c’est pourquoi ça fait mal

DMARC vérifie si SPF et/ou DKIM s’alignent avec le domaine visible dans le « From: ». C’est ainsi que l’on arrête le spoofing évident. Cela punit aussi les flux légitimes mais désordonnés.

Décision opérationnelle : traitez la politique DMARC reject/quarantine comme un signal important de réputation/auth, mais faites attention avant de sur-réagir pour des écosystèmes légitimes connus (listes de diffusion, chaînes de forwarding). Envisagez ARC si votre flux le supporte.

ARC : l’ami compliqué qui a parfois raison

ARC (Authenticated Received Chain) peut préserver les résultats d’authentification à travers des intermédiaires. Quand il est correctement déployé, il réduit les faux positifs sur les mails transférés. Quand il est mal déployé, il ajoute de la confusion.

Décision opérationnelle : si vous voyez beaucoup de mails transférés et qu’ARC est présent, validez que votre build/config Rspamd l’évalue correctement. Si ARC est systématiquement absent, c’est aussi un signal.

Bayes et fuzzy : entraînement sans s’empoisonner

Le filtrage bayésien est puissant et extrêmement facile à foirer. Le fuzzy hashing est excellent pour attraper des campagnes spam quasi identiques, et facile à surappliquer. Le thème : contrôlez vos entrées.

Bayes : utilisez-le, mais ne le laissez pas conduire la voiture

Bayes dans Rspamd peut apprendre des messages que vous classez ham/spam. Le piège des faux positifs survient quand :

• Les utilisateurs marquent des newsletters comme spam parce qu’ils sont agacés, pas parce que c’est vraiment du spam.
• Le spam atterrit dans une boîte partagée puis est déplacé, embrouillant les pipelines d’entraînement.
• Les seuils d’autolearn sont trop agressifs, entraînant sur des messages limites.

Fuzzy : portée étroite, haute confiance

Fuzzy fonctionne mieux quand vous hashez des éléments à fort signal : templates de spam connus, kits de phishing connus, payloads récurrents. Il fonctionne mal quand vous hashez des templates business communs (factures, notifications d’expédition) car vous finirez par vous bloquer vous-même sur une partie d’Internet.

Garde-fous à imposer

• Exiger une revue manuelle pour les jeux d’entraînement utilisés pour modifier Bayes/fuzzy.
• Séparer le mail corporate et le mail bulk si possible. Le bulk légitime partage des traits avec le spam.
• Surveiller la distribution de confiance Bayes, pas seulement le « spam attrapé ». Un modèle Bayes toujours incertain est souvent affamé ou pollué.

Performance et rétropression : quand le filtrage cause les faux positifs

C’est la partie que les gens manquent : les faux positifs peuvent être un artefact de timeouts et de contrôles dégradés.

Rspamd exécute plusieurs vérifications : requêtes DNS, requêtes Redis, extraction d’URL, parsing MIME, requêtes de réputation externes. Quand les dépendances sont lentes, certains contrôles expirent. Selon la config, vous pouvez obtenir :

• Des signaux négatifs manquants (le spam passe).
• Des signaux positifs manquants (le mail légitime perd des points d’« allow » et grimpe en score).
• Un comportement de repli qui est conservateur (par ex. les échecs temporaires traités comme suspect).

Ce qu’il faut surveiller qui corrèle avec les faux positifs

• Latence et taux d’erreur des requêtes DNS
• Latence Redis, évictions, problèmes de persistance
• Temps CPU des workers Rspamd vs temps réel (virtual vs real dans les logs)
• Nombre de requêtes DNS par message (les pics peuvent indiquer une campagne avec explosion d’URL)

Pattern de conception : « quarantaine en cas d’incertitude »

Si votre environnement subit des incidents sur les dépendances, envisagez une politique où les résultats limites vont en quarantaine plutôt qu’au rejet. C’est moins dramatique. Ça vous donne aussi une voie de récupération pour les faux positifs.

Trois mini-récits d’entreprise venant des tranchées

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

Une entreprise de taille moyenne exécutait Rspamd derrière une passerelle Postfix. Ils avaient une politique simple : tout message au-dessus du seuil de rejet était bouncé. Quelqu’un a supposé que « reject signifie plus sûr », alors il a abaissé reject d’une valeur conservatrice vers quelque chose de plus proche du seuil add_header. Le changement est passé un vendredi. Bien sûr.

Lundi matin, la finance s’est plainte que les virements fournisseurs « n’arrivaient pas ». Le mail n’était pas retardé ; il était rejeté. Les bounces sont partis vers une boîte sans surveillance parce que le fournisseur utilisait une adresse no-reply. Le fournisseur n’a rien su, la finance non plus, et la passerelle a fait exactement ce qu’on lui avait demandé.

Quand nous avons extrait un échantillon de messages rejetés, la plupart étaient propres mais avec des problèmes d’alignement DMARC parce que le fournisseur avait migré vers une nouvelle plateforme d’envoi et mal configuré DKIM. Rspamd n’agissait pas par paranoïa ; il était cohérent. L’erreur était de supposer que le seuil de rejet est juste « la ligne spam ». C’est en réalité « la ligne de coupure métier ».

La correction a été ennuyeuse et efficace : restaurer le seuil conservateur de reject, router le mail de confiance moyenne vers la quarantaine, et créer un processus d’onboarding fournisseur qui vérifie SPF/DKIM/DMARC avant la première facture.

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

Une autre organisation voulait réduire la latence mail. Ils ont remarqué un nombre élevé de requêtes DNS par message pendant des campagnes, donc ils ont « optimisé » en changeant de résolveur et en serrant les timeouts. En labo, c’était parfait : réponses plus rapides, moins de délais longs.

En production, le nouveau résolveur parfois limitait le débit ou laissait tomber des requêtes sous forte charge. Les logs Rspamd ont commencé à montrer des temps « real » plus longs et moins de lookups réussis pour SPF et clés DKIM. Le côté drôle est que le spam a commencé à passer et le mail légitime a commencé à scorer plus haut — parce que les symboles d’« allow » n’étaient plus attribués de façon cohérente.

L’incident s’est manifesté comme « Rspamd est incohérent ». Il ne l’était pas ; c’était la dépendance. Après rollback des changements de résolveur, ils ont ajouté un résolveur cache local sur le même réseau hôte, augmenté les timeouts de sanity, et surveillé les erreurs DNS comme une métrique de premier plan. Leur latence s’est améliorée et les faux positifs ont chuté sans toucher le scoring.

La leçon : les optimisations de performance des dépendances sont des changements de politique déguisés. Traitez-les avec le même contrôle de changement que pour les seuils anti-spam.

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

Une entreprise globale avait une habitude bureaucratique : chaque trimestre, ils revoyaient leurs 20 principaux symboles par contribution agrégée au score et leurs 20 principaux domaines expéditeurs rejetés. Pas d’héroïsme. Juste des rapports ennuyeux, une courte réunion et une liste de tickets.

Un trimestre, ils ont remarqué une montée régulière des rejets liés à DMARC provenant d’un fournisseur SaaS légitime utilisé par les RH. Avant que ça n’atteigne un niveau critique, ils ont ouvert un dossier avec le fournisseur, fourni des preuves d’échecs d’authentification, et appliqué temporairement une politique par expéditeur qui mettait en quarantaine plutôt que de rejeter. Les RH n’ont rien remarqué.

Deux semaines plus tard, le fournisseur a corrigé l’alignement DKIM. L’entreprise a retiré l’exception temporaire. Pas de cicatrice d’allowlist permanente. Pas de cadres en colère. Pas de « pourquoi vous ne nous avez pas prévenus ».

C’est la victoire discrète : la revue de routine attrape la dérive tôt, et les exceptions temporaires scoped préviennent les pannes tout en conservant le reste de votre posture intacte.

Erreurs courantes : symptôme → cause racine → correction

Symptôme : Du mail légitime est rejeté avec des scores élevés dominés par des symboles d’authentification.

Cause racine : Expéditeur mal configuré SPF/DKIM/DMARC, ou transferts/listes de diffusion cassant l’alignement.

Correction : Cibler la politique : mettre en quarantaine au lieu de rejeter pour cet expéditeur, et pousser l’expéditeur à corriger l’alignement. Éviter de réduire globalement les scores DMARC/DKIM.

Symptôme : Les faux positifs augmentent en même temps que le compte « DNS req » dans les logs.

Cause racine : Latence/échec du résolveur DNS provoquant des résultats de vérifications incohérents.

Correction : Stabiliser le DNS (cache local, timeouts raisonnables, capacité). Puis réévaluer le scoring.

Symptôme : Bayes étiquette soudainement un template business commun comme spam dans plusieurs départements.

Cause racine : Mauvaise entrée d’entraînement (utilisateurs marquant du bulk légitime comme spam), ou autolearn trop agressif.

Correction : Revoir le pipeline d’entraînement ; réduire l’autolearn ; réentraîner depuis des jeux de données soignés ; séparer le traitement du bulk.

Symptôme : Vous « corrigez » les faux positifs en augmentant le seuil de reject, et le volume de spam augmente en boîte en quelques jours.

Cause racine : Vous avez changé le mauvais contrôle ; le déséquilibre des symboles sous-jacent persiste.

Correction : Revenir sur le changement de seuil ; identifier les symboles principaux des faux positifs ; ajuster/cloisonner ces symboles ; ajouter un palier de quarantaine.

Symptôme : Une application interne envoie constamment des messages signalés, alors que le mail externe est correct.

Cause racine : L’application génère un MIME mal formé, du HTML-only, manque Date/Message-ID, ou utilise une infrastructure sortante partagée avec mauvaise réputation.

Correction : Corriger la génération du mail par l’application (en-têtes appropriés, partie text, DKIM cohérent). Si nécessaire, ajouter une politique par IP avec relaxation minimale pendant la remediation.

Symptôme : Les logs Rspamd montrent un scoring normal, mais le MTA rejette ou reroute toujours le mail.

Cause racine : Un autre filtre/milter/vérification d’en-tête agit, ou le MTA interprète mal les en-têtes.

Correction : Tracer le pipeline ; confirmer que la politique MTA mappe bien l’action Rspamd ; supprimer les contrôles conflictuels ou aligner les décisions.

Symptôme : Changements aléatoires de classification après un redémarrage Redis ou un épisode de pression mémoire.

Cause racine : Redis a évincé Bayes/fuzzy/metadata ; l’état du modèle a changé.

Correction : Fournir de la marge mémoire ; éviter les évictions ; séparer les instances Redis ; confirmer la stratégie de persistence ; surveiller evicted_keys.

Symptôme : L’allowlisting « corrige » le problème mais le phishing commence à passer.

Cause racine : Allowlisting par identifiants faibles (en-tête From, domaine sans DKIM), ou plages IP trop larges.

Correction : Remplacer les allowlists larges par des settings scoped et des contrôles d’identité forts ; utiliser des expirations et des revues périodiques.

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

Étape par étape : réduire les faux positifs en toute sécurité (sans ouvrir les vannes)

1. Collecter des preuves : 20–50 faux positifs avec en-têtes complets et décomposition des symboles Rspamd.
2. Classer par type de trafic : mail personnel, transactionnel fournisseur, bulk/marketing, alertes système, listes de diffusion.
3. Identifier les symboles récurrents dans les faux positifs (top 3 par message ; fréquence agrégée).
4. Confirmer la santé des dépendances : DNS, Redis, saturation CPU, latence des workers.
5. Choisir la mitigation la moins risquée :
   • Override settings par expéditeur ou domaine (quarantaine au lieu de rejet).
   • Ajuster un score de symbole légèrement (petits deltas, ex. -0.5 plutôt que -3.5).
   • Corriger l’auth de l’expéditeur ou la composition du mail interne.
6. Re-scorer un corpus de test en utilisant rspamc avant de déployer les changements.
7. Déployer avec reload, pas restart, et vérifier les logs pour un reload de config réussi.
8. Surveiller les taux d’action (reject/quarantine/greylist/add_header) pendant au moins une journée ouvrée.
9. Prévoir une quarantaine pour la confiance moyenne jusqu’à stabilisation des métriques.
10. Documenter les exceptions avec propriétaires et dates d’expiration pour revue.

Checklist : ce que vous devez avoir en place avant de tuner

• Une quarantaine ou au moins une voie récupérable pour les faux positifs
• Des logs centralisés et un moyen de chercher par Message-ID/queue ID
• Un corpus ham/spam soigné pour les tests de régression
• Des tableaux de bord pour la latence DNS, les évictions Redis, la latence des workers Rspamd
• Un journal de changements pour les modifications de scores/settings (les messages de commit comptent)

Checklist : liste « ne faites pas ceci »

• Ne désactivez pas globalement les contrôles DMARC/DKIM/SPF parce qu’un fournisseur ne sait pas configurer son email.
• Ne permettez pas l’allowlist par seul en-tête From.
• Ne faites pas de tuning pendant une panne (DNS/Redis) et appelez ça une « politique ».
• Ne définissez pas des seuils de reject proches des seuils add_header dans des environnements mail d’entreprise.
• Ne laissez pas l’autolearn être agressif à moins d’être prêt à auditer les entrées d’entraînement.

FAQ

1) Dois-je corriger les faux positifs en augmentant le seuil de reject ?

Seulement comme mesure de confinement temporaire, et seulement si vous la couplez à une quarantaine ou à une surveillance via add_header. À long terme, corrigez les symboles provoquant les pics ou cloisonnez la politique au trafic affecté.

2) Quelle configuration d’action est la plus sûre pour le mail d’entreprise ?

Généralement : add_header pour suspicion faible, quarantine pour suspicion moyenne, reject pour suspicion élevée. Le greylisting peut fonctionner, mais il crée des délais et un comportement fragile pour les expéditeurs automatisés.

3) Un fournisseur échoue constamment DKIM et DMARC. Dois-je l’allowlister ?

Préférez une politique ciblée : mettre en quarantaine au lieu de rejeter pour ce domaine expéditeur et conserver le scoring intact. Si vous devez allowlister, faites-le le plus étroitement possible (identité DKIM stable ou plage IP serrée) et fixez une date de revue.

4) Pourquoi les listes de diffusion provoquent-elles des faux positifs ?

Elles modifient souvent les messages (pieds de page, tags de sujet, changements d’en-têtes), ce qui peut casser DKIM. Elles changent aussi le chemin de livraison, cassant SPF. DMARC voit alors le désalignement et le score en tient compte.

5) Comment savoir quel symbole est « faux » ?

Vous ne devinez pas. Agrégez vos faux positifs et trouvez les contributeurs récurrents. Si un symbole apparaît dans la plupart des cas et n’est pas fortement corrélé au spam réel dans votre environnement, il peut être candidat au réglage ou au cloisonnement.

6) Bayes peut-il causer des faux positifs même si tout le reste va bien ?

Oui. Un modèle Bayes pollué peut étiqueter à tort des templates communs. Renforcez les entrées d’entraînement, réduisez l’agressivité de l’autolearn, et réentraînez à partir de jeux de données curatés si nécessaire.

7) Pourquoi les faux positifs s’aggravent-ils lorsque Redis est sous pression mémoire ?

Les évictions suppriment l’état appris et les caches. Ça change les probabilités Bayes et le comportement fuzzy/reputation. Le système devient moins cohérent, ce qui donne l’impression de changements « aléatoires » de classification.

8) Le greylisting est-il encore utile ?

Parfois. Il est utile contre des expéditeurs de faible qualité et certains spams opportunistes, mais il retarde le premier contact légitime et beaucoup de spammeurs modernes retentent correctement. Utilisez-le intentionnellement, pas par nostalgie.

9) Comment régler sans laisser plus de spam passer ?

Cloisonnez les changements (par expéditeur/domaine), préférez la quarantaine pour l’incertitude, et conservez un corpus de régression. N’affaiblissez pas les symboles d’auth globaux sans contrôles compensatoires forts.

10) Quel signe indique que le problème n’est pas le scoring mais l’infrastructure ?

Lorsque les motifs de symboles changent avec des timeouts, des erreurs DNS ou des évictions Redis, et quand le « real time » dans les logs augmente tandis que le « virtual time » reste bas. Corrigez d’abord les dépendances.

Conclusion : prochaines étapes réalisables cette semaine

Si vous ne faites que quelques actions, faites celles-ci :

1. Construire un petit corpus de faux positifs avec en-têtes complets et décomposition des symboles Rspamd. Arrêtez de tuner à partir d’anecdotes.
2. Mettre en place la quarantaine pour la confiance moyenne afin de pouvoir récupérer les erreurs sans impact métier.
3. Auditer la santé de vos dépendances : DNS et Redis se font passer pour des problèmes de scoring.
4. Régler par cloisonnement : les settings par domaine/expéditeur l’emportent presque toujours sur les réductions globales de scores.
5. Mettre en place une revue trimestrielle et ennuyeuse des principaux symboles et des principaux domaines rejetés. C’est le travail de fiabilité le moins cher que vous ferez.

Les faux positifs ne sont pas un mystère. Ils sont le signal qu’un de vos environnements a changé, qu’une hypothèse était fausse, ou que vos dépendances vacillent. Traitez-les comme un problème opérationnel, pas comme un problème superstitieux, et Rspamd se comportera.