Contents
Opérations routinières
Apprentissage Bayesien
Pour que Spamassassin fonctionne bien avec le filtre Bayesien, il faut lui faire apprendre comment distinguer les emails mauvais ("Spam") des bons emails ("Ham").
Spamassassin requiert un certain volume d'apprentissage avant que le filtre Bayesien soit utilisé, même s'il est configuré pour l'utiliser. La raison pour ça c'est qu'un filtre avec trop peu de valeurs d'apprentissage pourrait se tromper de façon horrible et complètement fausser les résultats de Spamassassin. Un filtre Bayesien qui vient tout juste d'être initialisé, ou vidé, doit obtenir 200 message classifiés "Ham" et aussi 200 messages classifiés "Spam" avant que le filtre ne soit utilisé par Spamassassin.
Pour cette raison, c'est important de faire apprendre au filtre Bayesien ce qu'est du "ham" dans des cas normaux sans attendre de voir passer des messages faussement classifiés comme spam -- donc pour ça, on peut par exemple faire apprendre le "Ham" au filtre à chaque soir dans l'Inbox des comptes mails.
Une bonne pratique pour pouvoir repartir le filtre plus rapidement, c'est de conserver un répertoire plein de spam auquel on ajoute le spam qu'on voit au fur et à mesure (pour avoir des exemples plus actuels), et aussi d'avoir un répertoire plein de emails qu'on sait qu'ils sont légitimes.
Aussi pour s'assurer de populer le filtre avec assez de signatures de messages de "Spam", on peut faire apprendre au filtre que ce qui se trouve dans le répertoire "Junk" des comptes emails est du spam.
A noter: une fois qu'un message a été classifié comme "Spam" ou "Ham", il est possible de le reclassifier en le donnant à la classification inverse pour l'apprentissage. Donc si on applique les exemples d'apprentissage dans Inbox et Junk, si un message de spam passe à travers le filtrage et aboutit dans l'Inbox, on peut le déplacer dans le répertoire Junk et il sera alors reclassifié. Le scénario inverse s'applique aussi pour déplacer un message faussement classifié comme junk du répertoire Junk à Inbox.
Combien de spam/ham est-ce que le filtre bayesien connait?
A cause de la limite minimum mentionnée plus haut pour que le filtre fonctionne, on aimerait des fois savoir si on a atteint le seuil minimum.
# sa-learn --dump magic 0.000 0 3 0 non-token data: bayes db version 0.000 0 131 0 non-token data: nspam 0.000 0 113 0 non-token data: nham 0.000 0 26489 0 non-token data: ntokens 0.000 0 1483640671 0 non-token data: oldest atime 0.000 0 1556204446 0 non-token data: newest atime 0.000 0 0 0 non-token data: last journal sync atime 0.000 0 0 0 non-token data: last expiry atime 0.000 0 0 0 non-token data: last expire atime delta 0.000 0 0 0 non-token data: last expire reduction count
ici, avec nspam et nham on peut voir qu'on n'a pas encore atteint la limite, et donc que le filtre ne sera pas encore utilisé.
Spam
Pour apprendre à spamassassin qu'un message est en fait du spam on utilise la commande suivante sur un message:
sa-learn --spam ./ficher_de_message_junk.eml
Ou encore sur un répertoire (par exemple un maildir qui peut correspondre à un répertoire dans un compte):
sa-learn --spam /var/mail/[...]/.Junk/
Ham (pas du spam!)
On peut aussi faire apprendre à spamassassin qu'un message n'est pas du spam (dans le jargon, c'est appelé "Ham"). Comme pour le spam, on peut faire ça pour un fichier:
sa-learn --ham ./fichier_de_message_correct.eml
Ou encore sur un répertoire (qui peut être un sous-répertoire d'un compte de mail):
sa-learn --ham /var/mail/[...]/.Inbox/
On n'est pas obligés d'attendre qu'un message soit marqué comme spam pour le faire apprendre en tant que "ham". Voir plus haut pour la raison de faire ça.
Reset du filtre
Il peut arriver des fois que le filtre devienne "empoisonné" (e.g. que des messages aient été marqués comme spam ou ham alors qu'ils n'auraient pas du l'être). Le filtre risque alors de donner de faux résultats, soit en laissant passer du spam, soit en bloquant des emails légitimes.
Si on a encore accès aux messages qui ont été marqués de la mauvaise manière on peut revenir en arrière en utilisant sa-learn avec soit --spam ou --ham pour corriger la classification des messages dans le filtre.
Si jamais on n'a pas accès aux messages, on doit p-e réinitialiser le filtre:
sa-learn --backup > ~/bayes_backup_2019-03-01 sa-learn --clear sa-learn --spam $repertoire_plein_de_spam sa-learn --ham $repertoire_avec_mails_legitimes
Troubleshooting
Spam assassin met tout à -1.9
La base s'est polluée. Il y a un autolearn sur le filtre bayesien, et il en bas de zéro, il pense que c'est du ham, donc il peut se mettre à s'auto détruire. Il faut donc remettre en place le filtrage de zéro. Il y a d'autres filtres sur spamassassin, dans /usr/local/spamassassin/var/spamassassin/3.003002/updates_spamassassin_org/20_phrases.cf , alors ca va continuer de mettre des trucs comme du spam.
Il faut donc rajouter à la config: bayes_auto_learn_threshold_nonspam -3.0 pour que le spam qui rentre rentre pas dans les règles bayesiennes. Il faut repartir dspam.
Ensuite il faut réinitialiser le filtre. Voir #Reset_du_filtre
Plusieurs messages sont taggés avec URIBL_BLOCKED
Le serveur a atteint la limite de volume de requêtes permises sur la liste URIBL. Il faut désactiver les requêtes temporairement pour calmer la situation, et configurer le serveur pour limiter le volume de requêtes.
Pour désactiver, ajouter ça dans local.cf:
score URIBL_BLACK 0 score URIBL_RED 0 score URIBL_GREY 0 score URIBL_BLOCKED 0
Pour diminuer le volume, on peut éviter de faire des requêtes pour certains domaines connus qui ont un gros volume:
uridnsbl_skip_domain googleapis.com goo.gl googlegroups.com docs.google.com uridnsbl_skip_domain youtu.be linkedin.com fbcdn.net licdn.com twimg.com redbox.com uridnsbl_skip_domain amazon.ca amazonses.com amazonaws.com ssl-images-amazon.com images-amazon.com media-amazon.com uridnsbl_skip_domain instagram.com pinterest.com pinimg.com facebookmail.com yahoodns.net tumblr.com uridnsbl_skip_domain groupon.com grouponcdn.com office365.com booking.com
Références:
voir les logs...
# tail -f /var/log/syslog | grep spamd
répertoire .Junk n'existe pas!
Dans le /var/log/mail.log
... failed to store into mailbox 'Junk': Mailbox doesn't exist: Junk
résultat du cronjob quotidien
Y semble nous manquer des trucs.
Subject: Cron <root@gerard> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin> X-Cron-Env: <HOME=/root> X-Cron-Env: <LOGNAME=root> Message-Id: <20171010100625.A7D9A2D4F26@gerard.koumbit.net> Date: Tue, 10 Oct 2017 07:06:25 -0300 (-03) /etc/cron.daily/spamassassin: oct 10 07:06:23.454 [32719] warn: config: failed to parse line, skipping, in "/etc/spamassassin/sql.cf": auto_whitelist_factory Mail::SpamAssassin::SQLBasedAddrList oct 10 07:06:23.454 [32719] warn: config: failed to parse line, skipping, in "/etc/spamassassin/sql.cf": user_awl_dsn DBI:mysql:spamassassin:localhost oct 10 07:06:23.454 [32719] warn: config: failed to parse line, skipping, in "/etc/spamassassin/sql.cf": user_awl_sql_username spamassassin oct 10 07:06:23.455 [32719] warn: config: failed to parse line, skipping, in "/etc/spamassassin/sql.cf": user_awl_sql_password xxxxxxxxxxxxxxxxxxx oct 10 07:06:23.455 [32719] warn: config: failed to parse line, skipping, in "/etc/spamassassin/sql.cf": user_awl_sql_table awl oct 10 07:06:24.106 [32719] warn: lint: 5 issues detected, please rerun with debug enabled for more information oct 10 07:06:24.351 [32721] dbg: logger: adding facilities: all oct 10 07:06:24.351 [32721] dbg: logger: logging level is DBG oct 10 07:06:24.351 [32721] dbg: generic: SpamAssassin version 3.4.0 oct 10 07:06:24.351 [32721] dbg: generic: Perl 5.020002, PREFIX=/usr, DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin oct 10 07:06:24.351 [32721] dbg: config: timing enabled oct 10 07:06:24.351 [32721] dbg: config: score set 0 chosen. oct 10 07:06:24.352 [32721] dbg: util: running in taint mode? yes oct 10 07:06:24.352 [32721] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH oct 10 07:06:24.352 [32721] dbg: util: PATH included '/usr/local/sbin', keeping oct 10 07:06:24.352 [32721] dbg: util: PATH included '/usr/local/bin', keeping oct 10 07:06:24.353 [32721] dbg: util: PATH included '/sbin', keeping oct 10 07:06:24.353 [32721] dbg: util: PATH included '/bin', keeping oct 10 07:06:24.353 [32721] dbg: util: PATH included '/usr/sbin', keeping oct 10 07:06:24.353 [32721] dbg: util: PATH included '/usr/bin', keeping oct 10 07:06:24.353 [32721] dbg: util: final PATH set to: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin oct 10 07:06:24.543 [32721] dbg: diag: perl platform: 5.020002 linux oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Digest::SHA, version 5.88 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: HTML::Parser, version 3.71 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Net::DNS, version 0.81 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: NetAddr::IP, version 4.075 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Time::HiRes, version 1.9726 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Archive::Tar, version 1.96 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: IO::Zlib, version 1.10 oct 10 07:06:24.543 [32721] dbg: diag: [...] module not installed: Digest::SHA1 ('require' failed) oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: MIME::Base64, version 3.14 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: DB_File, version 1.831 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Net::SMTP, version 2.33 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Mail::SPF, version v2.009 oct 10 07:06:24.543 [32721] dbg: diag: [...] module not installed: Geo::IP ('require' failed) oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Razor2::Client::Agent, version 2.84 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: IO::Socket::IP, version 0.29 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: IO::Socket::INET6, version 2.72 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: IO::Socket::SSL, version 2.002 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Compress::Zlib, version 2.064 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Mail::DKIM, version 0.4 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: DBI, version 1.631 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: Getopt::Long, version 2.42 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: LWP::UserAgent, version 6.06 oct 10 07:06:24.543 [32721] dbg: diag: [...] module installed: HTTP::Date, version 6.02 oct 10 07:06:24.543 [32721] dbg: diag: [...] module not installed: Encode::Detect ('require' failed) oct 10 07:06:24.543 [32721] dbg: diag: [...] module not installed: Net::Patricia ('require' failed) ..... oct 10 07:06:25.635 [32721] warn: lint: 5 issues detected, please rerun with debug enabled for more information run-parts: /etc/cron.daily/spamassassin exited with return code 1
Installons ça pour commencer à résoudre les problèmes de modules manquants.
# apt install libnet-patricia-perl libencode-detect-perl libgeo-ip-perl libdigest-sha-perl
cron trop verbeux
Si on a des emails de cron, voir 13303, workaround:
diff --git a/cron.daily/spamassassin b/cron.daily/spamassassin index 941c3f7..800fe5c 100755 --- a/cron.daily/spamassassin +++ b/cron.daily/spamassassin @@ -59,7 +59,7 @@ sleep $number # Update umask 022 -su debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys" +su debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys > /dev/null" case $? in 0)
Voir aussi:
Identifier quelles règles sont plus utilisées et prennent le plus de temps de CPU
TODO: à compléter / à tester