Traduction de la page https://workaround.org/ispmail/jessie/spamassassin

Vous avez d'ores et déjà un serveur de mails qui fonctionne parfaitement. Mais chaque fournisseur de courrier électronique sérieux se doit de faire quelque chose face à la folle quantité de spams en circulation. Avec cette nouvelle solution c'est devenu beaucoup plus simple et beaucoup plus fiable.

Nous n'utilisons plus uniquement les listes noires en temps réel

Les précédentes versions de ce guide s'appuyaient beaucoup sur les listes noires en temps réel (real-time blacklists ou RBLs). Une liste noire est simplement une liste d'adresses IP qui peut être interrogées par une requête DNS. Si une adresse IP se trouve dans cette zone DNS spécifique c'est qu'elle a eu des activités suspectes comme l'envoi de grandes quantités de spam ou des attaques lancées depuis cette IP. Il existe une grande quantité de RBLs gratuitement disponibles. Malheureusement beaucoup d'entre elles fonctionnent de manière automatique ce qui veut dire que des adresses IP peuvent accidentellement être mises en liste noire. Si cela arrive à des relais mail de grands fournisseurs d'accès à Internet vous risquez de mécontenter vos utilisateurs car ils vont perdre beaucoup de mails.

Est-ce que cela signifie que nous n'allons plus utiliser de RBLs ? Pas du tout. Nous allons au contraire utiliser maintenant de multiples RBLs. Simplement il ne sera pas suffisant qu'une IP figure dans une seule liste noire. Et nous ne nous contenterons pas de rejeter la connexion mais nous marquerons le mail en tant que spam et nous le distribuerons automatiquement dans un dossier spécial appelé « Junk » (Junk signifiant rebut).

Alerte importante : ceci ne fonctionne pas pour les utilisateurs récupérant leurs mails avec le protocole POP3. POP3 ne peut lire que le dossier « Inbox », mais ne peut pas accéder à d'autres dossiers. Donc ces utilisateurs supposeront que les courriers électroniques se sont accidentellement perdus parce qu'ils ne voient pas le dossier « Junk ». En fait je serais tenté de ne plus proposer du tout le protocole POP3, mais je ne me rends pas compte dans quelle mesure c'est un protocole encore couramment utilisé.

Nous allons contrôler les mails entrants en nous basant sur beaucoup plus de critères que les simples listes noires. Vous allez aimer ça.

Et qu'en est-il de la détection des virus ?

La mauvaise nouvelle ? Cette configuration ne parcourt plus les mails entrants à la recherche de logiciels malveillants (pour faire vite, les virus). C'est une décision très personnelle qui, je l'espère, ne vous mettra pas trop en colère. Personnellement je ne travaille pas sous Windows, donc je suis difficilement affecté par ces problèmes. Mais bien entendu je suis au courant que quelques uns de mes utilisateurs utiliseront des machines sous Windows. De nombreux virus sont transmis par des logiciels piratés ou par des failles des navigateurs (comme le lecteur Flash d'Adobe). Autant de choses contre lesquelles votre serveur de mail ne peut rien. Si vos utilisateurs sont tellemet mal informés qu'ils continuent à cliquer sur des pièces jointes avec des fichiers .exe ils seront de toute façon confrontés aux virus non détectés par les anti-virus, soit parce que ces virus sont trop récents, soit parce qu'ils ont muté ou qu'ils ont été créés sur mesure pour attaquer cet utilisateur. Pour faire court : je considère les scanners de virus comme de la charlatanerie (en anglais « snake oil »). Mais ça suffit avec les rodomontades. 🙂

Quest-ce que SpamAssassin ?

Notre nouveau super-héros contre le spam est « SpamAssassin » que vous avez déjà installé. Pour citer la page d'accueil du site de SpamAssassin : « Il utilise un cadre d'évaluation robuste et des modules additionnels qui intègrent une vaste gamme de tests d'analyses heuristiques et statistiques avancées sur les en-têtes et le corps des courriers électroniques, incluant l'analyse de texte, le filtrage Bayésien, les listes de blocage DNS et des bases de données de filtrage collaboratives ».

SpamAssassin est essentiellement un script écrit en Perl qui lit les mails, les fait analyser par ses plugins et calcule une note qui vous renseigne sur la probabilité que le mail soit un spam. Votre installation comporte par défaut plus de 60 modules pour aider à déterminer la probabilité qu'un mail soit un spam. Son taux de détection est si incroyablement bon que mon filtre de pourriels intégré à Thunderbird, bien entraîné, a du mal à trouver du spam résiduel.

Voici à quoi ressemble l'analyse d'un spam typique que j'ai reçu aujourd'hui :

Content analysis details:   (32.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.3 RCVD_IN_RP_RNBL        RBL: Relay in RNBL,
                            https://senderscore.org/blacklistlookup/
                            [203.151.98.74 listed in bl.score.senderscore.co
 3.3 RCVD_IN_MSPIKE_L5      RBL: Very bad reputation (-5)
                            [203.151.98.74 listed in bl.mailspike.ne
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
               [Blocked - see <http://www.spamcop.net/bl.shtml?203.151.98.74>]
 0.8 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web server
                            [203.151.98.74 listed in dnsbl.sorbs.ne
 2.7 RCVD_IN_PSBL           RBL: Received via a relay in PSBL
                            [203.151.98.74 listed in psbl.surriel.co
 3.5 BAYES_99               BODY: Bayes spam probability is 99 to 100%
                            [score: 1.0000]
 0.7 ONLINE_PHARMACY        BODY: Online Pharmacy
 1.4 TVD_VISIT_PHARMA       BODY: Body mentions online pharmacy
 0.0 DIET_1                 BODY: Lose Weight Spam
 0.0 TVD_RCVD_IP            Message was received from an IP address
 3.5 HELO_DYNAMIC_SPLIT_IP  Relay HELO'd using suspicious hostname (Split
                            IP)
 2.5 URIBL_DBL_SPAM         Contains a spam URL listed in the DBL blocklist
                            [URIs: 6url.r
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: 6url.r
 0.4 RCVD_IN_XBL            RBL: Received via a relay in Spamhaus XBL
                            [203.151.98.74 listed in zen.spamhaus.org]
 1.6 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: 6url.r
 1.2 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: 6url.r
 1.4 RCVD_IN_BRBL_LASTEXT   RBL: No description available.
                            [203.151.98.74 listed in bb.barracudacentral.org]
 0.8 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 0.2 BAYES_999              BODY: Bayes spam probability is 99.9 to 100%
                            [score: 1.0000]
 0.7 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.0 RCVD_IN_MSPIKE_BL      Mailspike blacklisted
 2.0 DRUGS_ERECTILE         Refers to an erectile drug
 1.0 RDNS_DYNAMIC           Delivered to internal network by host with
                            dynamic-looking rDNS
 0.0 MSGID_FROM_MTA_HEADER  Message-Id was added by a relay
 0.0 T_FROM_12LTRDOM        From a 12-letter domain

La première colonne affiche le score ajouté par chaque module. La deuxième colonne affiche le nom du module d'analyse. Et la troisième colonne donne une brève explication de ce que le module a trouvé. L'addition de tous ces scores conduit au score total de 32. En pratique les mails avec un score supérieur à 5 ou 6 peuvent être sans risque considérés comme des spam. Celui-ci est donc absolument un spam.

Avant de configurer Postfix, commençons par corriger…

Le bug Debian #739738

Malheureusement la version de SpamAssassin fournie par Debian Jessie contient un vilain bug qui remplit votre fichier mail.log de messages d'erreur et probablement empêche une détection efficace des spams. Pour corriger cela il faut éditer le fichier /usr/share/perl5/Mail/SpamAssassin/Util.pm, aller à la ligne 288 et remplacer :

return if !defined $_[0];

par

return undef if !defined $_[0];

Activer la détection des spams avec SpamAssassin

Nous allons faire tourner SpamAssassin comme un processus démon qui attend en permanence des connexions depuis Postfix. La connexion entre Postfix et SpamAssassin se fait via le protocole milter. Lancez cette commande :

postconf smtpd_milters=unix:/spamass/spamass.sock

SpamAssassin attend des variables spéciales (dites « macros ») donc ajoutons-les à Postfix par la commande :

postconf milter_connect_macros="i j {daemon_name} v {if_name} _"

Ensuite éditons le fichier /etc/default/spamassassin et ajoutons-y :

OPTIONS="--create-prefs --max-children 5 --helper-home-dir -x -u vmail"

CRON=1

Les OPTIONS supplémentaires -x -u vmail indiquent à SpamAssassin de consulter sa base de données bayésienne dans le répertoire personnel de l'utilisateur « vmail ». Pour être exacte, il va mettre les choses dans /var/vmail/.spamassassin. La base de données bayésienne enregistre des mots (aussi appelés tokens) à partir de tous les emails qu'elle a pu voir et calcule une probabilité conditionnelle qui détermine la ressemblance du mail avec un spam.

CRON=1 active la tâche cron quotidienne dans /etc/cron.daily/spamassassin qui télécharge un nouvel ensemble de règles de détection de spams chaque nuit.

Pour que le processus spamd soit démarré automatiquement lancez la commande :

systemctl enable spamassassin

Note : Debian Jessie utilise « systemd » pour lancer et arrêter les tâches. Du coup laisser ENABLED=1 n'a plus d'effet. C'est une relique du temps où Debian utilisait sysvinit.

Nous avons besoin de corriger un problème de droits. Le milter SpamAssassin a besoin d'accéder aux mêmes données que spamd. Nous devons donc ajouter l'utilisateur spamass-milter au groupe debian-spamd :

adduser spamass-milter debian-spamd

Redémarrons SpamAssassin :

service spamassassin restart
service spamass-milter restart

Testons la détection du spam

SpamAssassin devrait être correctement installé maintenant. Pour le tester nous pouvons utiliser un exemple de spam qui est distribué avec SpamAssassin. Il est appelé GTUBE (Generic Test for Unsolicited Bulk Email ou en français test générique pour les mails en vrac non sollicités). Il contient un motif artificiel qui est reconnu comme un spam par SpamAssassin. Si vous connaissez EICAR.COM pour tester les anti-virus, c'est la même chose pour les spams.

Donc envoyons cet échantillon de spam à John pour voir ce qui arrive. À la place de « ip-address » utilisez l'adresse de votre interface ethernet. Lancez la commande ip addr dans votre shell pour la connaître. Puis :

swaks --to john@example.org --server ip-address --data /usr/share/doc/spamassassin/examples/sample-spam.txt

(On ne peut pas ici utiliser la simple commande mail pour tester la détection de spam, car elle mettrait le mail directement dans la file d'attente de Postfix en court-circuitant le milter.)

Vérifiez votre fichier /var/log/mail.log. Vous devriez y lire quelque chose de ce genre :

Oct 22 02:02:53 ispmail-jessie postfix/smtpd[1718]: connect from localhost[::1]
Oct 22 02:02:53 ispmail-jessie postfix/smtpd[1718]: 8C356260F00: client=localhost[::1]
Oct 22 02:02:53 ispmail-jessie postfix/cleanup[1725]: 8C356260F00: message-id=<GTUBE1.1010101@example.net>
Oct 22 02:02:53 ispmail-jessie spamd[1607]: spamd: connection from localhost [::1]:48538 to port 783, fd 6
Oct 22 02:02:53 ispmail-jessie spamd[1607]: spamd: processing message <GTUBE1.1010101@example.net> for john:5000
Oct 22 02:02:53 ispmail-jessie spamd[1607]: spamd: identified spam (1001.5/5.0) for john:5000 in 0.1 seconds, 1128 bytes.
Oct 22 02:02:53 ispmail-jessie spamd[1607]: spamd: result: Y 1001 - ALL_TRUSTED,DATE_IN_PAST_96_XX,GTUBE,NO_DNS_FOR_FROM,T_HEADER_FROM_DIFFERENT_DOMAINS scantime=0.1,size=1128,user=john,uid=5000,required_score=5.0,rhost=localhost,raddr=::1,rport=48538,mid=<GTUBE1.1010101@example.net>,autolearn=no autolearn_force=no
Oct 22 02:02:53 ispmail-jessie postfix/qmgr[1715]: 8C356260F00: from=<root@ispmail-jessie.pmd.local>, size=3394, nrcpt=1 (queue active)
Oct 22 02:02:53 ispmail-jessie postfix/smtpd[1718]: disconnect from localhost[::1]
Oct 22 02:02:53 ispmail-jessie spamd[1606]: prefork: child states: II
Oct 22 02:02:53 ispmail-jessie dovecot: lda(john@example.org): msgid=<GTUBE1.1010101@example.net>: saved mail to INBOX
Oct 22 02:02:53 ispmail-jessie postfix/pipe[1728]: 8C356260F00: to=<john@example.org>, relay=dovecot, delay=0.31, delays=0.15/0.03/0/0.13, dsn=2.0.0, status=sent (delivered via dovecot service)
Oct 22 02:02:53 ispmail-jessie postfix/qmgr[1715]: 8C356260F00: removed

Les lignes intéressantes sont celles mises en gras. Elles proviennent de spamd. Apparemment le mail a atteint un score de 1001 points ce qui est vraiment beaucoup. Le minimum est de 5 pour qu'un mail soit marqué comme spam. Si nous jetons un oeil sur les entêtes du mail distribué nous verrons ces lignes ajoutées par SpamAssassin :

X-Spam-Flag: YES
X-Spam-Status: Yes, score=1001.5 required=5.0 tests=ALL_TRUSTED,
	DATE_IN_PAST_96_XX,GTUBE,NO_DNS_FOR_FROM,T_HEADER_FROM_DIFFERENT_DOMAINS
	autolearn=no autolearn_force=no version=3.4.0
X-Spam-Level: **************************************************
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	ispmail-jessie.pmd.local

Jusque là le mail a été simplement marqué comme étant un spam. Il sera tout de même envoyé à John dans sa boîte de réception. Mais nous voudrions faire quelque chose de plus à son propos.

Envoyer le spam dans le dossier « Junk »

Par chance Dovecot offre l'utilisation de filtres Sieve. John pourrait se connecter à Roundcube et configurer un filtre pour son usage personnel qui placerait chaque mail dans lequel la ligne X-Spam-Flag: YES a été trouvée dans son dossier « Junk ». Mais une telle règle serait, en fait, utile pour chacun de vos utilisateurs. Nous allons donc essayer de trouver une solution plus générale. Dovecot permet de définir des filtres de niveau global. Éditez le fichier /etc/dovecot/conf.d/90-sieve.conf. Cherchez les lignes sieve_after. Elles sont décommentées. Donc ajoutez-y une nouvelle ligne :

sieve_after = /etc/dovecot/sieve-after

Les filtres sieve_after sont exécutés après les filtres d'utilisateur. John peut définir ses propres règles de filtrage. Après leur exécution Dovecot exécutera toutes les règles de filtrage qu'il trouvera dans le dossier /etc/dovecot/sieve-after. Créons ce dossier :

mkdir /etc/dovecot/sieve-after

Et créons un nouveau fichier /etc/dovecot/sieve-after/spam-to-folder.sieve avec ce contenu :

require ["fileinto","mailbox"];

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

La ligne require charge la fonctionnalité permettant de déplacer un mail dans un dossier particulier (fileinto) et celle permettant de créer des dossiers si ils n'existent pas encore (mailbox). Dès lors si SpamAssassin marque une entête comme spam, le mail est déplacé dans le dossier INBOX.Junk qui apparaît à l'utilisateur simplement comme un dossier « Junk » sous son dossier inbox.

Dovecot cependant ne sait pas utiliser ce type de fichiers lisibles pour les humains. Nous devons donc le compiler :

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

Cette commande a généré un fichier lisible par Dovecot /etc/dovecot/sieve-after/spam-to-folder.svbin.

Redémarrons Dovecot :

service dovecot restart

Et envoyons de nouveau un mail de test à John :

swaks --to john@example.org --server localhost --data /usr/share/doc/spamassassin/examples/sample-spam.txt

Maintenant quand nous regardons le compte mail de john dans Roundcube nous allons trouver le test de spam dans son dosssier Junk :

Maintenant tous vos utilisateurs vont recevoir les spams dans leur dossier Junk. Pas mal n'est-ce pas ?