Réseau - Web - GNU/Linux

2018 10 février

Filtrer les spams avec rspamd - Debian 9.0 Stretch

Rédigé par Marc GUILLAUME | 17 commentaires
Article précédent Mail façon FAI - Debian 9.0 Stretch Article suivant

Traduction de la page : https://workaround.org/ispmail/stretch/filtering-out-spam-with-rspamd

Vous avez maintenant un serveur de mail parfaitement fonctionnel. Mais avant de le mettre en production il convient de faire quelque chose concernant la folle quantité de spam que vous allez recevoir. Dans les éditions précédentes de ce guide, j'utilisais et recommandais SpamAssassin. Cependant j'ai découvert un logiciel qui est plus souple, monte mieux en charge et reste facile à intégrer : rspamd. rspamd présente une comparaison (peut-être biaisée) sur leur site web.

rspamd est un processus qui tourne en permanence sur votre serveur (ndt : ce que dans le monde Unix on appelle un démon). Il écoute les connexions depuis Postfix en utilisant le protocole milter (=mail filter ou filtre de mail). Chaque fois qu'un mail entre sur votre système, Postfix va l'envoyer à rspamd pour que celui-ci vérifie son contenu. rspamd effectue toute une série de vérifications sur le mail et à partir de ces vérifications il calcule un score. Plus ce score est haut, plus la probabilité est grande que le mail soit un mail non sollicité.

Faire en sorte que Postfix utilise rspamd

Indiquons à Postfix de transférer tous les mails entrants à rspamd. Lancez ces commandes dans le shell :

postconf smtpd_milters=inet:127.0.0.1:11332
postconf non_smtpd_milters=inet:127.0.0.1:11332
postconf milter_protocol=6
postconf milter_mail_macros="i {mail_addr} {client_addr} {client_name} {auth_authen}"

Postfix va maintenant se connecter à rspamd qui écoute sur le port TCP 11332 sur localhost (127.0.0.1) et lui transmettre le mail via cette connexion. Les préférences smtpd_milters définissent cette connexion pour les mails arrivant sur le système par Internet via le protocole SMTP. L'option non_smtpd_milters est facultative, elle demande que même les mails provenant du système lui-même soient vérifiés. Et finalement l'option milter_mail_macros définit plusieurs variables attendues par rspamd pour une meilleure détection du spam. rspamd effectue ses vérifications et indique à Postfix si le mail doit passer ou être rejeté.

Essayons la détection du spam

Pour faire notre test nous pouvons utiliser un échantillon d'email de spam fourni par SpamAssassin. Il s'appelle GTUBE (Generic Test for Unsolicited Bulk Email, soit « test générique sur courrier électronique non sollicité envoyé en masse »). Il contient un certain nombre de critères qui sont reconnus comme spam par SpamAssassin. Si vous connaissez EICAR.COM pour tester les anti-virus, il s'agit de la même chose pour le spam.

Je vous propose de télécharger le fichier sur votre serveur :

wget http://spamassassin.apache.org/gtube/gtube.txt

…et de l'envoyer à notre utilisateur de test, John…

sendmail john@example.org < gtube.txt

Vérifiez votre fichier de log /var/log/mail.log. Vous trouverez quelque chose dans ce genre :

Jan 13 09:21:01 mail postfix/cleanup[19945]: 95B7A42212: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Gtube pattern; from=<root@mail.example.org> to=<john@example.org>

Jan 13 09:21:01 jen postfix/cleanup[19945]: 95B7A42212: to=<john@example.org>, relay=none, delay=0.18, delays=0.18/0/0/0, dsn=5.7.1, status=bounced (Gtube pattern)

Les parties intéressantes sont celles en gras. « milter_reject » indique que le milter (rspamd) recommande à Postfix de rejeter le mail. Il en donne la raison « 5.7.1 Gtube pattern ». Dans le domaine de la communication par mail, vous trouverez souvent ces trois chiffres de code. Il sont définis ans la RFC 3463. Le premier chiffre est le plus important :

  • 2 = Succès ;
  • 4 = Échec temporaire (problème temporaire, revenez plus tard) ;
  • 5 = Échec définitif (ne réessayez pas de cette façon).

Donc le code 5.7.1 nous indique qu'il s'agit d'un échec définitif de l'acheminement. Si vous avez jeté un oeil à la RFC citée ci-dessus vous savez que le 7 indique un problème concernant les règles de sécurité. Ce n'est donc pas un échec du à un problème technique, mais le rejet du mail par un composant logiciel chargé de la sécurité. C'est ce qu'à fait rspamd. Il nous en donne même la raison : « Gtube pattern ». Cela montre que rspamd reconnaît la structure de Gtube et réagit comme attendu.

En conséquence vous ne verrez pas ce courrier électronique dans la boîte de réception de John. C'est le grand avantage d'utiliser des milters. Imaginez que Postfix reçoive un mail de spam, et confirme sa réception. Que pourrat-il faire quand il découvrira que c'est un email non sollicité ? Selon le protocole SMTP il ne doit pas jeter de mails. Voudriez-vous créer un message de retour disant à l'expéditeur que vous n'acceptez pas son mail ? Ce serait une mauvaise idée, car le prétendu expéditeur du mail n'est vraissemblablement pas le vrai expéditeur. Vous enverriez le mail de retour à une personne innocente créant ce qu'on appelle une rétrodiffusion (backscatter en anglais) empirant encore la situation. La bonne approche est de vérifier le mail tant que le serveur d'expédition est toujours connecté avec votre Postfix. Ceci permet à Postfix de rejeter le mail avec un code d'erreur 5.x.x et laisser l'autre serveur décider de ce qu'il doit faire.

Utilisation du score (optionnel)

rspamd ne va cependant pas rejeter tous les spams. Comme il calcule un score de probabilité de spam vous pouvez dire avec quel score vous voulez accepter les mails, les marquer comme spam ou les rejeter. Jetez un oeil au fichier /etc/rspamd/metrics.conf. Il y a quantité de scores définis pour diverses conditions. Au début du fichier vous trouverez :

 actions {
 reject = 15;
 add_header = 6;
 greylist = 4;
 }

Comme me l'on fait remarquer les lecteurs le fichier metrics.conf n'est plus utilisé pour définir les scores de spam. Et comme l'a fait remarquer letouane :

# DEPRECATION WARNING!!
# This file is deprecated since 1.7		 
# Please use actions.conf and groups.conf files instead	 

Les scores sont donc paramétrables dans /etc/rspamd/actions.conf et le fichier /etc/rspamd/groups.conf permet lui de voir et affiner les règles par thèmes (en-têtes / sujet / rbl etc.)

C'est la configuration par défaut. Si rspamd calcule un core d'au moins 15, alors le mail sera rejeté comme la forme Gtube dans le test précédent. Tout score au dessus de 6 ajoutera une ligne d'entête « X-Spam: Yes » ainsi votre logiciel de mail peut le détecter et peut-être placer le mail dans un répertoire différent. Tout score au dessus de 4 déclenchera une procédure de greylisting (liste grise) qui est un méchanisme qui rejette temporairement le mail avec un code d'erreur 4.x.x et attend que l'expéditeur essaye un nouvel envoi. Après un délai de quelques minutes le greylisting acceptera le mail. L'idée est de rejeter les mails provenant de systèmes qui n'ont pas de file d'attente. Les logiciels malveillants qui infectent les ordinateurs sous Wind*ws on l'habitude de n'essayer l'envoi d'un mail qu'une fois, ce qui déclenche le greylisting et permet de rejeter efficacement le spammer. Mais même les programmeurs de logiciels malveillants se sont perfectionnés et peuvent retenter l'envoi après quelques minutes, contournant ainsi le greylisting. A vous de voir ce qui vous convient.

Si vous désirez changer ces valeurs par défaut, créez un nouveau fichier dans /etc/rspamd/override.d/metrics.conf (utiliser maintenant le fichier actions.conf au lieu de metrics.conf) contenant :

actions {
 reject = 150;
 add_header = 2;
 greylist = 5;
}

Avec ces valeurs vous ne rejeteriez pratiquement aucun mail. Et il marquerait comme spam tous les mails ayant au moins 2 en score de spam. Le greylisting se produirait pour un score supérieur à 5. Ce ne sont pas forcémment de bonnes valeurs, elles sont juste là à titre d'exemple.

S'il vous plaît prenez un moment pour comprendre comment modifier les valeurs par défaut de rspamd. Vous pouvez soit créer des fichiers dans /etc/rspamd/local.d/… qui remplaceront des sections entières ou créez des fichiers dans /etc/rspamd/override.d/… qui ne changeront que de petites parties de la configuration. Il existe une page utile dans la documentation de rspamd contenant des exemples. Quoi que vous fassiez ne modifiez jamais les fichiers /etc/rspamd/* directement car chaque mise à jour tenterait de les remplacer.

Bien entendu redémarrez rspamd après chaque modification de sa configuration :

service rspamd reload

Pour contrôler si rspamd a pris en compte votre configuration utilisez la commande suivante pour voir la configuration :

rspamadm configdump

Vous pouvez tester votre configuration en utilisant :

rspamadm configtest

Également vous pouvez vérifier si tous les processus rspamd nécessaires sont lancés…

pgrep -a rspam

22510 rspamd: main process 
22511 rspamd: rspamd_proxy process 
22512 rspamd: controller process 
22513 rspamd: normal process 
22514 rspamd: normal process 
22515 rspamd: hs_helper process

Ajouter des en-têtes

Comme vous le savez peut-être un email est composé d'en-têtes et du corps du mail proprement dit. Vos utilisateurs vont simplement voir certaines informations d'en-tête, comme le sujet, l'expéditeur, le destinataire et la date et l'heure à laquelle le mail a été envoyé. Mais il existe beaucoup d'autres en-têtes comme les routeurs que le mail a traversé ou les en-têtes étendus ajoutés par différents serveurs de mail sur le chemin suivi par le mail vers sa destination. Ce type d'en-tête commence avec « X- ». rspamd peut ajouter ce type d'en-tête pour vous aider à filtrer le spam. Pour cela créez un nouveau fichier de configuration de surcharge (override) /etc/rspamd/override.d/milter_headers.conf contenant ceci :

extended_spam_headers = true;

Comme l'indique la documentation, il va ajouter ces en-têtes :

X-Rspamd-Server: mail
Authentication-Results: dmarc=fail reason="No valid SPF, No valid DKIM" …
X-Rspamd-Queue-Id: C22E55A005B3
X-Spamd-Result: default: False [11.55 / 15.00]
 R_PARTS_DIFFER(0.27)[63.4%]
 FROM_NO_DN(0.00)[]
 RCVD_COUNT_ZERO(0.00)[0]
 R_DKIM_NA(0.00)[]
 FUZZY_DENIED(12.00)[1:19305c7fdd:1.00:bin,1:35699594fd:0.91:txt]
 RBL_SENDERSCORE(2.00)[55.181.23.94.bl.score.senderscore.com]
 ARC_NA(0.00)[]
 RCPT_COUNT_ONE(0.00)[1]
 RCVD_TLS_ALL(0.00)[]
 FROM_EQ_ENVFROM(0.00)[]
 R_SPF_SOFTFAIL(0.00)[~all]
 BAYES_HAM(-2.71)[98.75%]
 TO_MATCH_ENVRCPT_ALL(0.00)[]
 MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain]
 MID_RHS_MATCH_FROM(0.00)[]
 ASN(0.00)[asn:16276, ipnet:94.23.0.0/16, country:FR]
 TO_DN_NONE(0.00)[]
 DMARC_POLICY_SOFTFAIL(0.10)[Chronopost.fr : No valid SPF, No valid DKIM,none]
 SUBJECT_ENDS_EXCLAIM(0.00)[]
X-Spam: Yes

Chaque symbole en capitales comme FROM_HAS_DN indique qu'une certaine routine de détection de rspamd a été déclenchée. Cela n'indique pas forcément un mauvais point pour la mail. Par exemple R_SPF_ALLOW a un score négatif, qui baisse le score total, car c'est un bon point pour le mail. Il y plusieurs de ces symboles qui ont un score de 0.00. Ils ne modifient pas le résultat mais vous indiquent ce rspamd a trouvé. Mais si vous considérez certains de ces critères comme bons ou mauvais, vous pouvez définir vos propres scores pour chacun.

Ici la dernière ligne est particulièrement intéressante, car notre point suivant est…

Envoyer les spam dans le dossier des indésirables

Vos utilisateurs ne vont pas réaliser que leurs mails de spam on un en-tête supplémentaire « X-Spam: Yes ». Dans leur boîte aux lettres ces mails sembleront normaux. Donc aidons les en déplaçant automatiquement le spam dans un dossier particulier, le dossier Junk (souvent appelé dans les applications francisées « indésirables », ou « pourriels »), au lieu de leur boîte au lettres normale (inbox). Dovecot sait utiliser les filtres sieve (l'article en anglais de Wikipedia est beaucoup plus complet) qui sont simplement des scripts lancés automatiquement à l'arrivée d'un mail.

John pourrait se connecter sur Roundcube et configurer un nouveau filtre Sieve pour son usage personnel qui indiquerait de placer tout mail ayant un en-tête « X-Spam: Yes » dans son dossier des « indésirables ». Mais comme cette règle serait utile à tous vos utilisateurs essayons de trouver une solution générique.

Note : SpamAssassin utilisait dans les précédentes versions de ce guide un en-tête légèrement différent « X-Spam-Flag: YES ». Assurez-vous de changer vos filtres Sieve en conséquence.

Dovecot sait utiliser des filtres Sieve généraux s'appliquant à tous les utilisateurs. Éditez le fichier /etc/dovecot/conf.d/90-sieve.conf. Cherchez les lignes sieve_after. Elles sont mises en commentaire. Ajoutez à cet endroit une nouvelle ligne :

sieve_after = /etc/dovecot/sieve-after

Les filtres « sieve after » sont exécutés après les filtres des utilisateurs. John peut définir ses propres règles de filtrage. Après cela Dovecot va exécuter toutes les règles qu'il va trouver dans le répertoire /etc/dovecot/sieve-after. Créez ce répertoire :

mkdir /etc/dovecot/sieve-after

Et crééz-y un nouveau fichier /etc/dovecot/sieve-after/spam-to-folder.sieve contenant :

require ["fileinto","mailbox"];

if header :contains "X-Spam" "Yes" {
 fileinto :create "INBOX.Junk";
 stop;
}

Les lignes « require » indiquent les fonctions nécessaires pour déplacer des mails dans un dossier particulier (fileinto) et pour créer des répertoires si ceux-ci n'existent pas (mailbox). Dès lors si rspamd a marqué un mail en tant que spam, celui-ci sera déplacé dans le dossier INBOX.Junk qui apparaîtra simplement comme un sous répertoire « Junk » de son dossier « inbox ».

Cependant Dovecot ne sait pas utiliser les fichiers sous cette forme lisible par un être humain. Il nous faut le compiler :

sievec /etc/dovecot/sieve-after/spam-to-folder.sieve

Cela génère un fichier binaire lisible par la machine /etc/dovecot/sieve-after/spam-to-folder.svbin.

Redémarrez Dovecot :

service dovecot restart

Maintenant tous les utilisateurs verront tous leurs mails de spam automatiquement placés dans leur dossier des indésirables. Pratique n'est-ce pas ?

Apprentissage à partir de spam existant

Si vous avez suivi les précédentes versions de mail façon FAI (ISPmail) alors vous utilisez SpamAssassin depuis pas mal de temps. Vous l'avez peut-être entraîné avec quantité de ham et de spam pour alimenter sa base de données bayésienne pour améliorer la fiabilité de ses détections. La mauvaise nouvelle est que vous ne pouvez pas utiliser ces données d'entraînement dans rspamd car il utilise un algorithme différent. Il existe trois façons de démarrer avec rspamd

(a) Pas d'entraînement bayésien

Ce n'est pas aussi horrible que cela pourrait sembler. rspamd a quantité d'autres façons de décider si un email est acceptable ou est un spam. Je vous recommande d'activer l'auto-apprentissage. Créez simplement un nouveau fichier /etc/rspamd/override.d/classifier-bayes.conf qui contiendra :

autolearn = true;

Cependant c'est une approche très prudente. Il apprendra qu'un mail est un spam si il est si mauvais que son score entraînera son rejet. Et il considérera qu'un mail est un ham si il a un score négatif (c'est-à-dire excellent). La documentation de rspamd présente des exemples montrant comment peaufiner l'auto-apprentissage.

(b) Utiliser des statistiques pré-construites

rspamd fournit une base de données d'échantillons avec plus de 3000 mails analysés. Ils sont de 2015 et ne sont pas forcément un bon point de départ à cause de la nature des spams qui change en permanence.

Arrêtez rspamd :

service rspamd stop

Téléchargez leurs statistiques pré-construites et placez les fichiers *sqlite dans votre répertoire /var/lib/rspamd. Attribuez ces fichiers au bon utilisateur avec la commande…

chown _rspamd._rspamd /var/lib/rspamd/*sqlite

Et pour finir redémarrez rspamd

service rspamd start

Vérifiez que la base de données est maintenant remplie avec la commande…

rspamc stat

A la fin des données qui vont s'afficher vous allez voir quelque chose comme…

Statfile: BAYES_SPAM type: sqlite3; length: 41.78M; free blocks: 0; total blocks: 596k; free: 0.00%; learned: 1880; users: 1; languages: 3
Statfile: BAYES_HAM type: sqlite3; length: 51.12M; free blocks: 0; total blocks: 684k; free: 0.00%; learned: 1578; users: 1; languages: 3
Total learns: 3458

(c) Ré-apprenez vos spams et mails acceptables existants

Vous utilisez votre serveur depuis déjà pas mal de temps ? Et vous avez une bonne quantité de ham et de spam ? Alors utilisons les pour entraîner rspamd. Il est important de l'entraîner à la fois avec des spams et des hams. La commande rspamc vous permettra de l'alimenter avec des répertoires entiers de mails pour le processus d'apprentissage. Par chance nous utilisons le format Maildir pour conserver nos emails, et rspamd sait l'utiliser. Un exemple pour entraîner au spam :

rspamc learn_spam /var/vmail/example.org/john/Maildir/.INBOX.Junk/cur

Et ceci serait un exemple pour l'entraînement au ham :

rspamc learn_ham /var/vmail/example.org/john/Maildir/cur".

Bien sûr la qualité de la détection du spam dépendra de la qualité des sources de données fournies. N'utilisez pas les données d'utilisateurs qui mettent au hasard des mails dans leur dossier Junk même s'ils ne sont pas réellement du spam.

Vérifiez le nombre de mails appris avec la commande…

rspamc stat

Le filtre bayésien ne fonctionnera pas avant qu'il ait appris au moins 200 spam et ham. Essayer d'apprendre la reconnaissance des mails à rspamd avec moins de mails ou juste des spams ne fonctionnera pas. Ceci est défini par la variable min_learns définie dans /etc/rspamd/statistic.conf.

Dans les données affichées vous trouverez des lignes commençant par « Statfile » comme celles-ci…

Statfile: BAYES_SPAM type: sqlite3; length: 41.78M; free blocks: 0; total blocks: 0; free: 0.00%; learned: 0; users: 1; languages: 1
Statfile: BAYES_HAM type: sqlite3; length: 51.12M; free blocks: 0; total blocks: 0; free: 0.00%; learned: 0; users: 1; languages: 1
Total learns: 0

C'est ainsi que vous démarrerez en général. Plus vous fournirez de mails pour alimenter le processus d'entraînement meilleur sera votre taux de détection. Certains mails cependant peuvent ne pas être assez longs ou trop semblables à des mails déjà fournis. Donc ne vous inquiétez pas si vous fournissez 1000 mails d'entraînement mais que seulement 500 soient pris en compte.

Apprendre à partir des actions des utilisateurs

Nous arrivons maintenant à quelque chose de vraiment plaisant. Il s'agit de dire à Dovecot que déplacer un mail dans le répertoire Junk indique automatiquement à rspamd que le mail est un spam. Et réciproquement qu'un mail est un « ham » si il est sorti du dossier Junk. Nous allons utiliser des déclencheurs (triggers en anglais), en fait des scripts Sieve, liés à l'action de déplacer des mails via IMAP.

Il existait classiquement un beau plugin Dovecot du nom d'Antispam, il est hélas tombé en désuétude. La technique maintenant recommandée est d'utiliser le plugin IMAPSieve à la place. Il n'y a rien à installer, il fait partie du paquet Dovecot. Il suffit juste de le configurer.

Un mot d'avertissement cependant : pour l'instant la base de données d'apprentissage est commune à tous les utilisateurs. Si l'un d'eux l'entraîne délibérément avec n'importe quoi alors il va complètement dégrader votre taux de détection. Cette approche n'est donc souhaitable que pour les utilisateurs qui trient le spam et le ham et qui sont dignes de confiance. Il est également possible avec rspamd d'entraîner la détection de spam pour chaque utiliateur indépendemment, mais c'est actuellement hors de l'objectif de ce guide et peut même être problématique du fait que la plupart des utilisateurs ne disposent pas d'assez de spams et hams pour faire en sorte que la détection fonctionne correctement. Si vous êtes intéressé par la détection individuelle par utilisateur vous pouvez regarder la documentation correspondante de rspamd.

La première partie du travail consiste à activer le plugin IMAPSieve pour le protocole/service IMAP dans Dovecot. Éditez le fichier /etc/dovecot/conf.d/20-imap.conf et cherchez la ligne comportant mail_plugins. Modifiez-là comme suit :

mail_plugins = $mail_plugins imap_sieve

Nous avons également besoin d'éditer la configuration Sieve de Dovecot pour activer deux plugins dont nous aurons besoin. Sieve est un langage de script qui permet d'automatiser les traitements liés aux emails et aux dossiers où ils sont conservés. Éditez le fichier /etc/dovecot/conf.d/90-sieve.conf. La configuration des plugins se trouve dans la section entre accolades (cette section contient beaucoup de commentaires ) :

plugin {
...
}

Commencez par modifier la ligne contenant sieve_plugins de la façon suivante :

 sieve_plugins = sieve_imapsieve sieve_extprograms

Et n'importe où dans cette section placée entre accolades (plugin { … }) ajoutez ces lignes :

# From elsewhere to Junk folder (de n'importe où vers le dossier Junk)
imapsieve_mailbox1_name = Junk
imapsieve_mailbox1_causes = COPY
imapsieve_mailbox1_before = file:/etc/dovecot/sieve/learn-spam.sieve

# From Junk folder to elsewhere (du dossier Junk vers n'importe quel autre dossier)
imapsieve_mailbox2_name = *
imapsieve_mailbox2_from = Junk
imapsieve_mailbox2_causes = COPY
imapsieve_mailbox2_before = file:/etc/dovecot/sieve/learn-ham.sieve

sieve_pipe_bin_dir = /etc/dovecot/sieve
sieve_global_extensions = +vnd.dovecot.pipe

La première règle indique à Dovecot d'exécuter les règles Sieve définies dans le fichier /etc/dovecot/sieve/learn-spam.sieve chaque fois qu'un mail est déplacé dans un dossier « Junk » d'utilisateur. Nous allons créer ce script Sieve dans une minute.

La seconde règle s'occupe du mouvement inverse. Chaque fois qu'un mail est déplacé d'un dossier « Junk » vers n'importe quel autre dossier, le script Sieve /etc/dovecot/sieve/learn-ham.sieve est appelé.

Le réglage sieve_pipe_bin_dir définit où les scipts exécutables doivent être placés. Nous mettrons à cet endroit notre script d'apprentissage tout simple. Et pour finir le réglage sieve_global_extensions active le plugin de transfert (pipe) qui autorise l'envoi des mails à une commande externe.

Une petite précision : si vous migrez d'une version précédente de ce guide, votre répertoire de mail utilise toujours des points (« . ») au lieu de slashes (« / ») dans la composition de la structure de fichiers. La meilleure façon de le voir est que vous allez trouver des répertoires INBOX.Junk au lieu de simples dossiers Junk dans les sous-répertoires de /var/mail. Si c'est le cas pour vous, remplacez le mot Junk dans les sections ci-dessus par INBOX.Junk.

Maintenant créons le script Sieve qu'utilisera Dovecot. Créez un nouveau répertoire /etc/dovecot/sieve pour y placer nos fichiers :

mkdir /etc/dovecot/sieve

Maintenant créez le fichier /etc/dovecot/sieve/learn-spam.sieve avec le contenu suivant :

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-spam.sh";

Faisons de même pour le fichier /etc/dovecot/sieve/learn-ham.sieve :

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-ham.sh";

Ces deux fichiers doivent être compilés, ce qui les transforme en code compréhensible par la machine :

sievec /etc/dovecot/sieve/learn-spam.sieve
sievec /etc/dovecot/sieve/learn-ham.sieve

Pour ceux ayant eu l'erreur :

# sievec /etc/dovecot/sieve/learn-spam.sieve
learn-spam: line 1: error: require command: unknown Sieve capability `vnd.dovecot.pipe'.
learn-spam: line 1: error: require command: unknown Sieve capability `imapsieve'.
learn-spam: line 2: error: unknown command 'pipe' (only reported once at first occurrence).
learn-spam: error: validation failed.
sievec(root): Error: failed to compile sieve script '/etc/dovecot/sieve/learn-spam.sieve'

Il ne faut pas oublier, après avoir fait les modifications dans /etc/dovecot/conf.d/90-sieve.conf de redémarrer le service dovecot avant de lancer les commandes sievec !

service dovecot restart

Ceci va créer deux nouveaux fichiers learn-ham.svbin et learn-spam.svbin dont le contenu semble du charabia, mais qui sont maintenant dans un format que le plugin SIeve de Dovecot peut comprendre.

Pendant qu'on y est donnons les permissions adéquates à ces fichiers :

chmod u=rw,go= /etc/dovecot/sieve/learn-{spam,ham}.sieve
chown vmail.vmail /etc/dovecot/sieve/learn-{spam,ham}.sieve

Et la dernière étape consiste à créer les simples scripts shell qui réalisent en pratique l'entrainement spam/ham. Le premier fichier est /etc/dovecot/sieve/rspamd-learn-spam.sh contenant :

#!/bin/sh
exec /usr/bin/rspamc learn_spam

Ça semble simple n'est-ce pas ? En fait il n'y a besoin de rien de plus. Le spam est envoyé à ce script et rspamd apprend que c'est un mail de spam et ajuste ses critères de détection dans sa base de données en conséquence.

Le second script concerne le ham et s'appelle /etc/dovecot/sieve/rspamd-learn-ham.sh. Donnons lui le contenu suivant :

#!/bin/sh
exec /usr/bin/rspamc learn_ham

Il faut rendre ces scripts exécutables, réglons ce problème :

chmod u=rwx,go= /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh
chown vmail.vmail /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh

J'espère que vous n'y avez pas perdu votre latin. Il s'agit simplement d'un enchaînement d'actions. Rappelons comment fonctionne ce processus :

  1. Un utilisateur déplace un mail dans son dossier « Junk » ;
  2. Dovecot se rend compte que cela déclenche la règle Sieve imapsieve_mailbox1 et du coup il appelle le script Sieve /etc/dovecot/sieve/learn-spam.sieve (en réalité la version *.svbin du script) ;
  3. Sieve va prendre en charge le mail et l'envoyer (par le tube, pipe en anglais) au script shell exécutable rspamd-learn-spam.sh ;
  4. ce script à son tour traite le mail via la commande /usr/bin/rspamc learn_spam.

Ceci fonctionne bien sûr de la même façon dans l'autre sens pour l'apprentissage d'un ham.

Je suis certain que vous êtes impatient de l'essayer. C'est en effet le moment. Cependant, pour vous assurer qu'il fonctionne vraiment je vous suggère d'éditer le fichier /etc/dovecot/conf.d/10-logging.conf et de le le modifier en mettant mail_debug=yes. Ceci va rajouter beaucoup d'informations au fichier /var/log/mail.log mais sur un serveur très actif peut également conduire à quelques mots de tête. 🙂

Redémarrez Dovecot…

service dovecot restart

…et observez le fichier /var/log/mail.log file

tail -f /var/log/mail.log

Maintenant ouvrez votre client IMAP (Thunderbird, Evolution, Roundcube, mutt ou n'importe lequel ayant votre préférence) et placez un mail dans votre dossier d'indésirables (Junk). Le fichier de log devrait afficher quelques lignes dans ce genre…

imap(john@example.org): Debug: imapsieve: mailbox INBOX.Junk: MOVE event
imap(john@example.org): Debug: imapsieve: Matched static mailbox rule [1]
imap(john@example.org): Debug: sieve: file storage: Using Sieve script path: /etc/dovecot/sieve/learn-spam.sieve
imap(john@example.org): Debug: sieve: file script: Opened script `learn-spam’ from `/etc/dovecot/sieve/learn-spam.sieve’
imap(john@example.org): Debug: sieve: Opening script 1 of 1 from `/etc/dovecot/sieve/learn-spam.sieve’
imap(john@example.org): Debug: sieve: Loading script /etc/dovecot/sieve/learn-spam.sieve
imap(john@example.org): Debug: sieve: Script binary /etc/dovecot/sieve/learn-spam.svbin successfully loaded
imap(john@example.org): Debug: sieve: binary save: not saving binary /etc/dovecot/sieve/learn-spam.svbin, because it is already stored
imap(john@example.org): Debug: sieve: Executing script from `/etc/dovecot/sieve/learn-spam.svbin’
imap(john@example.org): Debug: sieve: action pipe: running program: rspamd-learn-spam.sh
imap(john@example.org): Debug: Mailbox INBOX.Junk: Opened mail UID=3978 because: mail stream
imap(john@example.org): Debug: waiting for program `/etc/dovecot/sieve/rspamd-learn-spam.sh’ to finish after 0 msecs
imap(john@example.org): sieve: pipe action: piped message to program `rspamd-learn-spam.sh’

Recherchez les erreurs et les alertes. Si à la fin vous voyez que Dovecot a appelé le script rspamd-learn-spam.sh tout devrait fonctionner.

Et pour finir, si vous sortez un mail du dossier des indésirables, vous devriez voir que la règle [2] (mailbox rule [2]) est appellée et que le mail est appris comme étant du ham :

imap(john@example.org): Debug: imapsieve: mailbox INBOX: MOVE event
imap(john@example.org): Debug: imapsieve: Matched static mailbox rule [2]
imap(john@example.org): Debug: sieve: file storage: Using Sieve script path: /etc/dovecot/sieve/learn-ham.sieve
imap(john@example.org): Debug: sieve: file script: Opened script `learn-ham’ from `/etc/dovecot/sieve/learn-ham.sieve’
imap(john@example.org): Debug: sieve: Opening script 1 of 1 from `/etc/dovecot/sieve/learn-ham.sieve’
imap(john@example.org): Debug: sieve: Loading script /etc/dovecot/sieve/learn-ham.sieve
imap(john@example.org): Debug: sieve: Script binary /etc/dovecot/sieve/learn-ham.svbin successfully loaded
imap(john@example.org): Debug: sieve: binary save: not saving binary /etc/dovecot/sieve/learn-ham.svbin, because it is already stored
imap(john@example.org): Debug: sieve: Executing script from `/etc/dovecot/sieve/learn-ham.svbin’
imap(john@example.org): Debug: sieve: action pipe: running program: rspamd-learn-ham.sh
imap(john@example.org): Debug: Mailbox INBOX: Opened mail UID=28412 because: mail stream
imap(john@example.org): Debug: waiting for program `/etc/dovecot/sieve/rspamd-learn-ham.sh’ to finish after 0 msecs
imap(john@example.org): sieve: pipe action: piped message to program `rspamd-learn-ham.sh’

C'est tout. C'est chouette non ?

Ndt : Une fois que tout fonctionne, je vous conseille de remettre mail_debug=no dans le fichier /etc/dovecot/conf.d/10-logging.conf afin de ne pas surcharger inutilement les logs.

Purge automatique

Andi Olsen m'a fait remarquer que Dovecot a introduit une nouvelle fonctionnalité pour effacer automatiquement les mails dans un dossier lorsqu'ils ont atteint un certain âge. C'est particulièrement utile pour les dossiers Trash (corbeille) et Junk (indésirable). Pour activer cette fonctionnalité éditez simplement le fichier /etc/dovecot/conf.d/15-mailboxes.conf et ajoutez le paramètre autoexpunge là où vous le voulez. Par exemple :

mailbox Junk {
  special_use = \Junk
  auto = subscribe
  autoexpunge = 30d
}
mailbox Trash {
  special_use = \Trash
  auto = subscribe
  autoexpunge = 30d
}

Redémarrez Dovecot après chaque changement de configuration.

Les logs

rspamd conserve des logs détaillés de ses actions dans /var/log/rspamd/rspamd.log. Si un utilisateur se plaint qu'un mail ait été bloqué ou au moins marqué comme spam jetez un oeil dans ce fichier de log. Vous pouvez également le comparer avec le fichier /var/log/mail.log en utilisant l'identifiant de queue de Postfix (Postfix queue ID). Il s'agit d'un nombre de 12 chiffres hexadécimaux comme « 95CE05A00547 ». Cet identifiant se retrouve également dans les logs de rspamd :

2018-01-14 06:39:45 #10424(normal) <40985d>; task; rspamd_task_write_log: id: <undef>, qid: <95CE05A00547>, ip: 12.13.51.194, from: <…>, (default: F (no action): [3.40/15.00] [MISSING_MID(2.50){},MISSING_DATE(1.00){},MIME_GOOD(-0.10){text/plain;},ARC_NA(0.00){},ASN(0.00){asn:8220, ipnet:212.123.192.0/18, country:GB;},FROM_EQ_ENVFROM(0.00){},FROM_NO_DN(0.00){},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_ZERO(0.00){0;},RCVD_TLS_ALL(0.00){},TO_DN_NONE(0.00){},TO_DOM_EQ_FROM_DOM(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 181, time: 16.000ms real, 6.385ms virtual, dns req: 0, digest: <69b289a82827c11f759837c033cd800a>, rcpts: <…>, mime_rcpt: <…>

L'interface web

Interface web de rspamd
Interface web de rspamd

rspamd est livré avec une fonctionnalité bonus spécifique : une interface web. Elle vous permet de contrôler les emails marqués comme spam, d'avoir des statistiques et de personnaliser finement les scores de spam. Elle est déja installée et attend les requêtes HTTP sur le port 11334 sur l'interface localhost. Je vous suggère d'ajouter une simple configuration de proxy à votre webmail fonctionnant déjà en https pour y avoir accès.

La première chose à faire est d'activer le module Apache permettant la configuration des proxy :

a2enmod proxy_http

Vous pouvez soit créer une nouvellle configuration d'hôte virtuel ou simplement éditer le fichier /etc/apache2/sites-available/webmail.example.org-https.conf. N'importe où entre les balises VirtualHost ajoutez :

 ProxyPass "/rspamd" "http://localhost:11334"
 ProxyPassReverse "/rspamd" "http://localhost:11334"

Ce petit bout de configuration va transférer les requêtes https://webmail.example.org/rspamd vers localhost:11334 et vous donner accès à l'interface web de rspamd.

Note du traducteur : Pour ma part j'ai préféré utiliser la configuration fournie sur le site de rspamd qui repose sur la réécriture d'url et est la suivante :

<Location /rspamd>
	Order allow,deny
	Allow from all
</Location>
RewriteEngine on
RewriteRule ^/rspamd$ /rspamd/ [R,L]
RewriteRule ^/rspamd/(.*) http://localhost:11334/$1 [P,L]
	

Ou bien en utilisant également un proxypass au lieu d'une règle de réécriture, comme le propose le touane :

RewriteEngine on
RewriteRule ^/rspamd$ /rspamd/ [R]
ProxyPass "/rspamd" "http://localhost:11334
ProxyPassReverse "/rspamd" "http://localhost:11334

Si jamais le mode de réécriure d'url n'est pas activé sur votre serveur :

   a2enmod rewrite
	

Et bien entendu vous pouvez utiliser n'importe quel nom de dossier à la place de /rspamd si vous voulez mieux dissimuler votre interface rspamd.

L'accès à cette interface web est protégé par un mot de passe. Générons un nouveau mot de passe :

pwgen 15 1

Ceci vous donnera un mot de passe du genre « eiLi1lueTh9mia4 ». Vous pouvez mettre ce mot de passe dans le fichier de configuration de rspamd. Mais les mots de passe en clair dans les fichiers de configuration ce n'est pas très élégant. Créons un hachage de ce mot de passe :

rspamadm pw
Enter passphrase: …
$2$icoahes75e7g9wxapnrbmqnpuzjoq7z…

Fournissez le mot de passe généré avec pwgen et vous obtiendrez un long hachage du mot de passe. Cette procédure est également documentée dans les pages de rspamd.

Créez un nouveau fichier de configuration /etc/rspamd/local.d/worker-controller.inc et placez-y le hachage de votre mot de passe :

password = "$2$icoahes75e7g9wxapnrbmqnpuzjoq7z…"

Voilà pour la configuration. Pour finir relancez à la fois rspamd et Apache pour prendre en compte votre changement de configuration :

service rspamd reload
service apache2 restart

Si tout a fonctionné comme prévu, vous devriez être capable d'accéder à l'interface web de rspamd à l'adresse : https://webmail.example.org/rspamd

Aller plus loin ?

Si vous envisagez d'utiliser rspamd dans un environnement complexe prenez le temps de lire l'abondante documentation qu'il propose. rspamd s'adapte très bien à la montée en charge, mais requiert des configurations supplémentaires comme l'utilisation de Redis pour une analyse plus rapide du spam pour de multiples serveurs de mail.

17 commentaires

#1  - Grubshka a dit :

Bonjour,

Merci beaucoup pour ce tutoriel détaillé et documenté !

Une autre solution pour entraîner quotidiennement rspamd, est d'utiliser une liste de spams fournie par le site artinvoice.hu au format mbox : voir https://words.bombast.net/rspamd-with-postfix-dovecot-debian-stretch/#09
Étant plus parano que ce site, je n'ai pas lancé la commande en root pour tester, et j'ai vérifier le script python qu'ils proposent pour transformer au format maildir, c'est correct.

J'ai aussi regardé quelques exemples de spams qu'ils proposent, il y en a beaucoup en hongrois, donc que nous sommes peu enclins à recevoir, et quelques-un en anglais que j'ai pu voir sur mes serveurs français, c'est toujours utile.
En revanche ça n'entraînera pas rspamd à tagger comme spam l'ex-femme du cousin du roi du Gabon qui veut vous transférer quelques millions.

À quand un système P2P international de partage de statistiques de spams ?

Répondre
#2  - Grubshka a dit :

Il peut être aussi intéressant d'entraîner rspamd en utilisant les mails copiés par les utilisateur dans et depuis la boîte de spam : https://words.bombast.net/rspamd-with-postfix-dovecot-debian-stretch/#04

Répondre
#3  - Marc GUILLAUME a dit :

Bonjour, merci de vos commentaires. Je suis désolé pour la réponse tardive, mais quelques problèmes de santé m'ont tenu éloigné d'Internet pendant plus d'un mois. Entre temps Christophe Haass a pris en compte votre commentaire et a intégré l'apprentissage par entrée ou sortie de la boîte Junk. Et donc j'ai rajouté cet élément à ma traduction de son guide.

Répondre
#4  - Letouane a dit :

Bonjour Marc,

Dans la partie "Utilisation du score (optionnel)", le fichier metrics.conf n'est plus celui qui inclus les scores.
est indiqué dans ce fichier :
# DEPRECATION WARNING!!
# This file is deprecated since 1.7
# Please use actions.conf and groups.conf files instead

Les scores sont donc paramétrables dans /etc/rspamd/actions.conf
Le fichier /etc/rspamd/groups.conf permet lui de voir et affiner les règles par thèmes (en-têtes / sujet / rbl ...).

Je poursuis ma lecture au risque de commenter plusieurs fois ;-)

Répondre
#5  - Letouane a dit :

Dans la section "Apprendre à partir des actions des utilisateurs" est écrit "Et dans la section placée entre accolades { … } ajoutez ces lignes :".
C'est un peu trompeur pour moi (seulement si j'ai bien compris) car la ligne #sieve_plugins est déjà dans la section entre accolades.
Bref, si je comprends bien, on pourrait simplement ajouter les règles à la ligne juste après "sieve_plugin" ou même juste avant la dernière ligne (fermeture d'accolade) ?

Répondre
#6  - Marc GUILLAUME a dit :

Voilà j'ai modifié un peu la rédaction, est-ce que c'est plus clair ?

Répondre
#7  - Letouane a dit :

C'est parfait Marc ! Merci.

Répondre
#8  - Letouane a dit :

Lorsque j'ouvre http(s)://webmail.example.org/rspamd mon navigateur 404 sur le JS et les CSS. Ce vilain ne rajoute pas le slash fermant, ce qui donne un lien vers le CSS un truc dans le genre :
https://webmail.example.org/css/bootstrap.min.css

Du coup voici ce que j'ajoute dans /etc/apache2/sites-available/webmail.example.org-https.conf :
RewriteEngine on
RewriteRule ^/rspamd$ /rspamd/ [R]
ProxyPass "/rspamd" "http://localhost:11334
ProxyPassReverse "/rspamd" "http://localhost:11334

J'espère que je ne fais pas une ânerie, ça te parait cohérent ?

Répondre
#9  - Aimsai a dit :

Je confirme que le fichier "metrics.conf" n'est plus utilisé, et qu'à la place c'est "actions.conf"
Pour poursuivre l'exemple, c'est /etc/rspamd/override.d/actions.conf qu'il faut créer pour modifier la configuration en y écrivant :
reject = 150;
add_header = 2;
greylist = 5;

Autre petite précision, la commande "rspamadm configdump" ne m'a pas permis de vérifier la configuration tellement elle est longue. J'ai plutot utilisé "rspamadm configdump > dump.txt" suivi de "nano dump.txt" qui permet de faire une recherche avec CTRL+W et je confirme que le contenu de "/etc/rspamd/override.d/actions.conf" ne nécessite pas d'y inscrire toute la section avec les accolades, mais uniquement ce que j'ai inscrit au dessus.

Dans la section "Apprendre à partir des actions des utilisateurs" je pense qu'il faudrait ajouter de passer la commande "service dovecot restart" après avoir ajouté les lignes dans plugin { }, sinon la compilation de learn-spam/ham.sieve provoque une erreur.

Je confirme également le commentaire de Letouane, il est indispensable pour l'interface de rspamd d'ajouter la "RewriteRule", sinon, pas de mise en forme CSS, pas d'images, et pas de JS !

Répondre
#10  - Arnaud a dit :

Bonjour et merci pour ce tuto,

J'ai l'impression qu'il y a une erreur dans ton script /etc/dovecot/sieve/learn-ham.sieve
En le testant je n'ai pas remarqué l'incrémentation du compteur "Learned" du dashboard rspamd.

En remplacant
pipe :copy "rspamd-learn-spam.sh";
par
pipe :copy "rspamd-learn-spam.sh" [ "${email}" ];
cela semble fonctionner mieux

Répondre
#11  - Arnaud a dit :

Un autre problème potentiel dans "90-sieve.conf" :
Lorsqu'on supprime un email celui ci est souvent déplacé dans la corbeille (Trash) par les clients mail
Donc lorsque qu'on va supprimer un email du dossier Junk on va déclencher learn-ham sur celui-ci.
=> le spam va être réappris comme non-spam, pas cool :(

La solution est sans doute de remplacer
imapsieve_mailbox2_name = *
par
imapsieve_mailbox2_name = INBOX ou imapsieve_mailbox2_name = ^Trash (à voir si ça marche)

Répondre
#12  - lemur a dit :

Je ne pense pas que la syntaxe imapsieve_mailbox2_name = ^Trash fonctionne.

D'après https://wiki2.dovecot.org/Pigeonhole/Sieve/Plugins/IMAPSieve, "This setting supports wildcards with a syntax compatible with the IMAP LIST command".

La RFC 6154 (https://tools.ietf.org/html/rfc6154) qui définit la syntaxe de IMAP LIST ne semble pas fournir de moyen de spécifier de négation ("tout SAUF le dossier Trash"). Dommage.

Répondre
#13  - Fre a dit :

Bonjour,
Merci pour ces infos !
Chez moi le lancement de : ''sievec /etc/dovecot/sieve/learn-ham.sieve''
génère les erreurs suivantes :
<code>learn-ham: line 1: error: require command: unknown Sieve capability `vnd.dovecot.pipe'.
learn-ham: line 1: error: require command: unknown Sieve capability `imapsieve'.
learn-ham: line 2: error: unknown command 'pipe' (only reported once at first occurrence).
learn-ham: error: validation failed.
</code>
Quelque chose m'échappe ?
Merci
Fred

Répondre
#14  - cigale a dit :

Comment avez-vous détourné le problème ?
Car ce serait bête de voir que rspam "apprend" qu'un message arrivé dans le dossier "junk" comme spam,
mais le déplacement du même message dans la corbeille va activer le script "learn-ham".
Ce qui revient à ne rien faire, non ?

Répondre
#15  - steph a dit :

Bonjour, j'ai le même problème que Fred:
learn-spam: line 1: error: require command: unknown Sieve capability `vnd.dovecot.pipe'.
learn-spam: line 1: error: require command: unknown Sieve capability `imapsieve'.
learn-spam: line 2: error: unknown command 'pipe' (only reported once at first occurrence).
learn-spam: error: validation failed.
sievec(root): Error: failed to compile sieve script '/etc/dovecot/sieve/learn-spam.sieve'
et pour l'autre fichier aussi:
learn-ham: line 1: error: require command: unknown Sieve capability `vnd.dovecot.pipe'.
learn-ham: line 1: error: require command: unknown Sieve capability `imapsieve'.
learn-ham: line 2: error: unknown command 'pipe' (only reported once at first occurrence).
learn-ham: error: validation failed.
sievec(root): Error: failed to compile sieve script '/etc/dovecot/sieve/learn-ham.sieve'
Et encore merci pour le tuto.

Répondre
#16  - steph a dit :

Re bonjour,
Pour l'utilisation de l'interface rspamd, le proxy fonctionne, mais tous les liens relatifs sont en 404 et il ne me demande pas de mot de passe

Répondre
#17  - Marc GUILLAUME a dit :

Merci de vos retours, en effet tout ne fonctionne pas toujours parfaitement dans cette affaire. J'espère d'ici quelques semaines pouvoir dégager le temps nécessaire pour éclaircir tout cela et remettre les choses en ordre, n'ayant plus actuellement le temps libre dont j'aurais besoin pour vraiment me pencher sur ces problèmes. Je vous demanderai donc, hélas, un peu de patience...

Répondre

Écrire un commentaire

Quelle est la première lettre du mot qlcad ?

Fil RSS des commentaires de cet article

À propos

Yakati.com - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.056s  - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.com
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml