Filtrer les spams avec rspamd - Debian 9.0 Stretch
Rédigé par Marc GUILLAUME | 18 commentairesTraduction 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 insteadLes scores sont donc paramétrables dans
/etc/rspamd/actions.confet le fichier/etc/rspamd/groups.confpermet 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.confde 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 :
- Un utilisateur déplace un mail dans son dossier « Junk » ;
- 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) ; - 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 ;
- 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.confafin 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
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:11334Si jamais le mode de réécriure d'url n'est pas activé sur votre serveur :
a2enmod rewriteEt 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.
