- Fuori c'è l'uomo della spazzatura. - Digli che non ne vogliamo. [Groucho Marx]

Integrare il sistema di posta con SpamAssassin

Presto o tardi ogni casella di posta è destinata ad essere raggiunta dal fuoco incrociato degli spammer.

Quando ciò accade, non è facile sopportare a lungo il fatto che un'elevata percentuale dei messaggi che riceviamo provenga da sconosciuti che tentano di propinarci pubblicità indesiderata o, peggio, di infettare il nostro computer.

Pertanto, diviene naturale che il bersagliato cerchi di difendersi, mettendo in atto un fuoco di sbarramento.

Utilizzando Mutt, sappiamo che non possiamo chiedergli di fare un altro mestiere; quindi, volendo filtrare lo spam, dobbiamo integrare il nostro sistema di gestione della posta con un software anti-spam, che ci aiuti a catalogare i messaggi distinguendoli tra:

ham (posta valida);
spam (posta non richiesta e indesiderata).

La mia scelta è caduta su SpamAssassin, pluripremiato progetto open source.

Questo capitolo del Nirvana è dedicato all'illustrazione dell'utilizzo di SpamAssassin, in abbinamento con Procmail e con Mutt.

Tratteremo dell'abbinamento con Procmail perchè sarà lui a richiedere l'esecuzione di SpamAssassin, per poi gestire lo smistamento su apposita casella dei messaggi catalogati come spam da SpamAssassin.

Vedremo inoltre la configurazione di Mutt perchè imposteremo delle macro per informare SpamAssassin di eventuali sue errate catalogazioni.

Le errate catalogazioni possono essere distinte in:

falsi positivi, ovvero messaggi catalogati come spam, ma in realtà ham;
falsi negativi, ovvero messaggi spam non riconosciuti come tali.

Infine, illustreremo come far eseguire periodicamente, tramite un cron job, l'addestramento manuale di SpamAssassin sui nostri messaggi, sia ham sia spam.

Nel dettaglio, impareremo:

Cos'è SpamAssassin.
I principi di funzionamento di SpamAssassin.
La configurazione per integrare SpamAssassin in Procmail.
Come visualizzare in Mutt gli header aggiunti da SpamAssassin.
Come addestrare SpamAssassin su messaggi mal catalogati.
Come addestrare SpamAssassin con un cron job.
La configurazione di SpamAssassin.
Come verificare la corretta configurazione di SpamAssassin.
Come utilizzare il plugin SPF Query.
Come aggiornare le regole euristiche di SpamAssassin.
Come velocizzare SpamAssassin tramite sa-compile.
Come velocizzare SpamAssassin eseguendolo come demone.
Come addestrare SpamAssassin con un db di spam già pronto.

Le generalità di SpamAssassin

SpamAssassin nasce approcciando la valutazione dei messaggi mediante utilizzo di algoritmi di filtraggio euristico che non richiedono addestramento, in quanto predefiniti e tenuti aggiornati dai programmatori del software. Si tratta, in pratica, di test applicati a varie parti del messaggio (header, body, uri).

Questa caratteristica di SpamAssassin consente di avere, da subito, un basso numero di falsi negativi.

Per questo motivo, ritengo preferibile iniziare con l'utilizzo di SpamAssassin in luogo di programmi che lavorano esclusivamente con algoritmi bayesiani, la cui efficacia nella catalogazione è elevata, ma deve crescere con il tempo grazie all'addestramento, automatico e manuale, effettuato sui messaggi analizzati.

Una volta costruito un magazzino di messaggi catalogati come spam, potremo in realtà sfruttare la capacità di SpamAssassin di filtrare i messaggi anche utilizzando algoritmi bayesiani.

Tra i programmi che utilizzano esclusivamente tecniche di filtraggio bayesiano i più conosciuti sono:

SpamAssassin, non utilizza solo verifiche euristiche e bayesiane ma può, volendo, effettuare anche network test, eseguiti appoggiandosi a servizi RBL (Real Time Black List) e di spamlist condivise e aggiornate dagli utenti, come Razor, Pyzor e DCC. SpamAssassin può inoltre gestire in maniera automatica una whitelist di indirizzi email.

In rete sono disponibili molti studi, approfonditi ed eseguiti con rigore statistico, circa le performance dei più diffusi software antispam. Non sono in grado di sostenere che SpamAssassin sia il migliore. Ma, quello che più conta per me, è che mi soddisfa.

Relativamente al giudizio sul livello di servizio offerto dai filtri antispam vale infatti questo personale metro di giudizio, unitamente alla consapevolezza che, quanto più sono disponibile a "perdere del tempo" nell'addestrare il software, tanto più sarò soddisfatto della sua efficacia.

Un motivo di critica a SpamAssassin può invece essere quello del carico di lavoro cui sottopone la CPU e della sua velocità nell'eseguire il ciclo di test su ogni messaggio. Tale minore performance rispetto ad altri competitors deriva dal linguaggio interpretato in cui è scritto (Perl) e dal maggior numero di test che svolge (sebbene possa essere disabilitati).

Usandolo però su un pc casalingo, io non ho notato significative differenze rispetto a quando non utilizzavo filtri antispam.

Qualcuno si starà già chiedendo se vale la pena di sottoporre la posta in arrivo alla verifica di più di uno dei software disponibili. La concatenazione è possibile (vedi Frying Spam per un esempio di integrazione tra SpamAssassin e Bogofilter) ma, al di là dell'ovvio incremento di tempo necessario, non ci sono ancora studi significativi circa l'efficacia del lavoro di analisi svolto.

Per approfondire:

^top

Come funziona SpamAssassin

Riducendo la spiegazione ai minimi termini, SpamAssassin assegna ad ogni messaggio analizzato un punteggio, definito score. Più elevato lo score, maggiore la probabilità che si tratti di spam.

Lo score si forma per somma pesata di punti accumulati effettuando una pluralità di test, ove ogni test assegna un punteggio nel caso in cui dia esito positivo. Il punteggio assegnato per ciascun test è predefinito, ma liberamente modificabile dall'utente (consigliato solo agli esperti!).

La soglia (threshold) che SpamAssassin utilizza per discriminare tra ham e spam è fissata sullo score 5. Verrà considerato spam un messaggio con score pari o superiore a 5.

Da approfondite analisi sull'operato dei software antispam, il rischio che messaggi validi vengano inseriti nello spam è molto marginale. Tuttavia, specialmente nel primo periodo di utilizzo del software anti-spam, è opportuno verificare che non si producano casi troppo frequenti di falsi negativi e, soprattutto, di falsi positivi.

Il fine tuning del livello soglia, operabile intervenendo sul valore di una variabile nel file di configurazione, è uno dei pochi settaggi che SpamAssassin ci richiede. Vedremo che, per il resto, gran parte delle impostazioni di default vanno bene.

Nell'impostazione del software, ritengo preferibile avere la quasi certezza di non perdere messaggi validi, anche se a costo di una minore accuratezza nell'identificazione dello spam. Il costo di una errata classificazione di un messaggio valido mi appare infatti superiore al costo di avere uno spam non filtrato.

^top

Configurazione di Procmail per SpamAssassin

Nel Nirvana non trattiamo della configurazione di Procmail e, in questa parte, ci limiteremo a esporre quanto necessario per integrarlo con SpamAssassin.

Procmail, per quanti non lo conoscono, è un Mail Delivery Agent (MDA) che consente di gestire il flusso della posta in arrivo (volendo anche in uscita), eseguendo su di questa eventuali azioni (filtraggio, eliminazione, correzione del formato, archiviazione, ecc..).

L'utilizzo più tipico di Procmail è lo smistamento dei messaggi su mailbox diverse, in base a verifiche eseguite sugli header del messaggio (ad esempio, sul campo From:).

Relativamente al problema dello spam, un approccio radicale potrebbe essere quello di istruire Procmail a dirottare su una mailbox dedicata allo spam (se non addirittura a cancellare) tutti i messaggi ove il mittente NON risulti tra quelli conosciuti (elencati in una whitelist sottoposta a test).

Potremmo cioè fare a meno di SpamAssassin, ma il limite sarebbe evidente: chi ci scrivesse utilizzando un indirizzo email che non abbiamo precedentemente censito, sarebbe bollato come spammer.

Più consigliabile appare, invece, l'introduzione in procmail di regole di filtraggio di messaggi il cui mittente è da noi conosciuto.

Tali regole, inserite prima della chiamata del programma anti-spam, riducono il rischio di generazione di falsi positivi e riducono il numero di messaggi lasciati in carico a SpamAssassin.

Il mestiere di SpamAssassin, lo ripetiamo, è comunque quello di catalogare i messaggi e non di eliminarli, nel rispetto della filosofia *nix ed anche del detto milanese "Ofelè fa il tò mestè" (Panettiere fai il tuo mestiere).

Siamo poi noi a decidere cosa fare dei messaggi catalogati come spam e, nel caso in questione, volendoli smistare su un'apposita mailbox, ci avvaliamo delle capacità di Procmail.

Vediamo allora cosa inserire nei file di configurazione di Procmail.

Il file principale di configurazione di Procmail è ~/.procmailrc.

In testa troviamo la definizione di alcune path.

# La directory deve esistere (crearla se necessario)
MAILDIR=$HOME/Mail/

# Le email non regolate dai vari recipes finiranno in questa mailbox
DEFAULT=$MAILDIR/inbox

# La directory contenente i file con le regole
PMDIR=$MAILDIR/.Pm

# path di formail, usato per processare email
FORMAIL=/usr/bin/formail

# path di sendmail
SENDMAIL=/usr/sbin/sendmail

# path di spamassassin
SPAMASSASSIN=/usr/bin/spamassassin
# path di spamc da utilizzare se si usa il demone spamd
# SPAMASSASSIN=/usr/bin/spamc

Nel file sono quindi inserite le chiamate a ulteriori file contenenti le regole in base alle quali eseguire delle azioni sulla totalità dei messaggi (ad esempio il backup di tutta la posta in arrivo) o per gestire specifici tipi di messaggi (messaggi di amici, messaggi provenienti da mailing list sottoscritte, spam).

# F I L E .RC A G G I U N T I V I (REGOLE)
#----------------------------------------------------------------------
# regole base (archiviazione, controlli formali, ecc..)
INCLUDERC=$PMDIR/general.rc

# regole per posta da me, amici e familiari
INCLUDERC=$PMDIR/friends.rc

# regole per posta da mailing list
INCLUDERC=$PMDIR/lists.rc

# regole antispam + spamassassin
INCLUDERC=$PMDIR/spam.rc

Inoltre, in coda al file, si trova la cosiddetta regola matcha tutto, che consente di smistare alla mailbox principale la posta che non sia stata precedentemente smistata.

# POSTA NON REGOLATA DA REGOLE
#----------------------------------------------------------------------
# regola "matcha tutto" così nulla finisce in /var/spool/mail/ataualpa
# ma nella mailbox "inbox" all'interno della maildir
# In realtà, avendo definito la mailbox inbox come $DEFAULT, non
# c'è nemmeno bisogno di questa regola finale: tutti i messaggi
# che non vengono gestiti da una regola, vengono inoltrati alla
# mailbox $DEFAULT.

:0:
$DEFAULT

Vediamo adesso il contenuto del file spam.rc, richiamato da .procmailrc

# TRATTAMENTO A CURA DI SPAMASSASSIN
# ----------------------------------
# SpamAssassin procmailrc
# fonte: http://wiki.apache.org/spamassassin/UsedViaProcmail
# ----------------------------------
# La prima regola passa la posta a SpamAssassin
# Utilizziamo la variabile $SPAMASSASSIN, definita in .procmailrc
# (se si utilizza la combinazione spamc/spamd, va lanciato spamc)
#
# La condizione assicura che siano processati da SpamAssassin solo
# file di dimensioni inferiori a 250 kB (250 * 1024 = 256000 bytes).
# La maggior parte dello spam è infatti di dimensioni intorno ai pochi
# k e anche così si limitano le elaborazioni a carico di SpamAssassin.
#
# Il lock file assicura che venga eseguita una sola istanza di
# SpamAssassin alla volta.
#
:0fw: spamassassin.lock
* < 256000
| $SPAMASSASSIN

# I messaggi arrivati fin qui e che presentano la taggatura come spam
# operata da SpamAssassin perchè con score superiore al livello soglia
# (il default è 5) vengono dirottati sulla mailbox spam.
# [La variabile di configurazione di SpamAssassin, responsabile della
# definizione del livello soglia, è required_score]

:0:
* ^X-Spam-Status: Yes
spam

# Regola che risolve un bug di Procmail che causa l'elisione della "F"
# nel campo "From" quando si verifica la produzione di output su stderr.
# La regola provvede a reinserire eventuali "F" mancanti in "rom".

:0
* ^^rom[ ]
{
LOG="*** F mancante dall'header From! Sistemato. "

:0 fhw
| sed -e '1s/^/F/'
}

^top

Configurazione di Mutt per SpamAssassin

Visualizzare gli header X-Spam

Aprendo Mutt per leggere la posta avremo messaggi che, precedentemente dati in pasto a SpamAssassin e da questo analizzati, presentano i seguenti header (nella configurazione di default di SpamAssassin):

X-Spam-Status:
- mostra lo score assegnato, lo score necessario per essere spam, i test eseguiti, la catalogazione assegnata dalla funzione di auto learn, la versione del programma
  esempio: No, score=4.2 required=4.5 tests=BAYES_20,HTML_MESSAGE, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RCVD_IN_XBL, RDNS_NONE autolearn=no version=3.2.1
X-Spam-Level:
- valorizzato con asterischi, evidenzia lo score assegnato
  esempio: ****
X-Spam-Checker-Version:
- valorizzato con il nome e versione del programma e la macchina su cui è stato eseguito
  esempio: SpamAssassin 3.2.1 (2007-05-02) on Ciatty.debian.home
X-Spam-Flag:
- inserito e valorizzato con YES quando gli asterischi superano la soglia definita per lo spam (default 5)

Se vogliamo che tali header vengano visualizzati nel pager sappiamo come "arricchire" l'elenco degli header, lavorando su .muttrc:

## H E A D E R
#---------------------------

unignore ....... X-Spam-Status: X-Spam-Level: X-Spam-Flag: X-Spam-Checker-Version:

Parimenti, dobbiamo inserire questi header nell'elenco che ne specifica l'ordine di visualizzazione:

hdr_order ....... X-Spam-Checker-Version: X-Spam-Status: X-Spam-Level: X-Spam-Flag:

Ecco un esempio tratto da due email "scannate" da SpamAssassin:

Email sottoposta a controllo e valutata ham:
- X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on Ciatty.debian.home
  X-Spam-Level: ****
  X-Spam-Status: No, score=4.4 required=5.0
Email sottoposta a controllo e valutata spam:
- X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on Ciatty.debian.home
  X-Spam-Level: *********
  X-Spam-Status: Yes, score=9.8 required=5.0
  X-Spam-Flag: YES

Addestrare SpamAssassin su messaggi mal catalogati

SpamAssassin può tranquillamente operare senza necessità di feedback sul suo operato. Ciò perchè il database bayesiano viene alimentato mediante la funzione di autolearn (attiva di default).

Tuttavia, se lo correggiamo quando riscontriamo falsi positivi o falsi negativi, miglioreremo progressivamente la sua precisione nell'identificazione dello spam.

Meglio ancora se, periodicamente, gli sottoponiamo per l'addestramento del filtro tutte le email sicuramente ham che abbiamo nelle nostre varie mailbox e quelle sicuramente spam che lasciamo nella mailbox dedicata.

Per istruire SpamAssassin direttamente da Mutt su messaggi da lui mal catalogati, possiamo utilizzare sa-learn, parte del pacchetto di SpamAssassin, eseguito grazie a delle macro.

Di seguito un esempio di quanto inserire nel .muttrc, nella parte dedicata alle macro:

# Macro per SpamAssassin

# SpamMerda management
macro index \em "<enter-command>unset weed<enter>\
<pipe-entry>sa-learn --showdots --no-sync --spam<enter>\
<enter-command>set wait_key<enter><enter-command>set weed<enter>\
<save-message>=spam<enter>"\
"Cataloga come SpamMerda"

macro pager \em "<enter-command>unset weed<enter>\
<pipe-entry>sa-learn --showdots --no-sync --spam<enter>\
<enter-command>set wait_key<enter><enter-command>set weed<enter>\
<save-message>=spam<enter>"\
"Cataloga come SpamMerda"

# Ham management
macro index \eh "<enter-command>unset weed<enter>\
<pipe-entry>sa-learn --showdots --no-sync --ham<enter>\
<enter-command>set wait_key<enter><enter-command>set weed<enter>\
<save-message>=inbox<enter>"\
"Cataloga come Ham"

macro pager \eh "<enter-command>unset weed<enter>\
<pipe-entry>sa-learn --showdots --no-sync --ham<enter>\
<enter-command>set wait_key<enter><enter-command>set weed<enter>\
<save-message>=inbox<enter>"\
"Cataloga come Ham"

# annulla precedente valutazione
macro index \ez "<pipe-entry>sa-learn --forget<enter>" "Annulla valutazione sa-learn"

macro pager \ez "<pipe-entry>sa-learn --forget<enter>" "Annulla valutazione sa-learn"

# verifica se un messaggio è valutato spam
macro index \et "<pipe-entry>spamassassin -t<enter>\
<enter-command>set wait_key<enter>" "Testa la spammosità del messaggio"

macro pager \et "<pipe-entry>spamassassin -t<enter>\
<enter-command>set wait_key<enter>"\br /> "Testa la spammosità del messaggio"

^top

Addestrare SpamAssassin con un cron job

Come scritto poc'anzi, periodicamente è opportuno addestrare il filtro bayesiano di SpamAssassin indicandogli manualmente le email spam e quelle ham, anche quelle che non sono state vagliate al momento dello scaricamento (perchè Procmail le ha smistate prima di farle arrivare a SpamAssassin).

Abbiamo appena visto come, controllando i nostri messaggi, possiamo spostare sulla mailbox spam i falsi negativi e riportare in inbox i falsi positivi.

Pertanto, avendo la certezza di dov'è lo spam e dove i messaggi ham, con cadenza settimanale, possiamo far eseguire un job mediante il quale SpamAssassin scansiona tutti messaggi delle nostre mailbox, e apprende che:

i messaggi nella mailbox spam sono spam,
i messaggi non in spam sono ham.

Vediamo lo script che possiamo far eseguire da cron:

#!/bin/bash -e

# filename: cron.sa-learn.sh
# version: 0.000000000000001
# Autore: Ataualpa aka Francesco Ciattaglia
# Attivita' del programma: Addestramento bayesiano di SpamAssassin
# modificare i valori delle variabili in base al proprio sistema!

# indirizzo di sistema a cui inviare l'output di cron
[email protected]

# utente sotto cui eseguire i comandi dello script
USER=ataualpa

# path del database bayes da istruire
BAYESDIR="\
/home/ataualpa/.spamassassin/ \
"

# path delle mailbox ham
HAMDIRS="\
/home/ataualpa/Mail/Friends \
/home/ataualpa/Mail/Sent \
/home/ataualpa/Mail/Lists \
/home/ataualpa/Mail/inbox \
"

# path della mailbox spam
SPAMDIRS="\
/home/ataualpa/Mail/spam \
"

# apprendimento per spam
for spamdir in $SPAMDIRS ; do \
if [ -e $spamdir ]; then
echo Mi istruisco con lo spam contenuto nella mailbox $spamdir ; \
nice sa-learn --spam --no-sync --showdots --mbox $spamdir \
--dbpath $BAYESDIR --username=$USER; \
rm $spamdir > /dev/null; \
touch $spamdir; \
chmod 664 $spamdir; \
chown $USER:$USER $spamdir
fi
done

# apprendimento per ham
for hamdir in $HAMDIRS ; do \
if [ -e $hamdir ]; then
echo Mi istruisco con gli ham contenuti nella mailbox $hamdir ; \
nice sa-learn --ham --no-sync --showdots --mbox $hamdir \
--dbpath $BAYESDIR --username=$USER
fi
done

# sincronizzazione database
sa-learn --sync --dbpath $BAYESDIR --username=$USER

* Sinceriamoci che ci sia una riga vuota in fondo (enter dopo l'ultima riga con il comando sa-learn --sync).

Questo script, che salviamo in un file con nome a piacere e rendiamo eseguibile, lo spostiamo nella directory di cron:

/etc/cron.daily se vogliamo sia eseguito settimanalmente,
/etc/cron.weekly se vogliamo sia eseguito giornalmente.

Dell'avvenuta esecuzione dello script, avremo ogni volta "notizia" grazie alla mail che ci verrà recapitata dal sistema.

Nel testo della mail, per ciascuna mailbox sottoposta per l'apprendimento a sa-learn, leggeremo qualcosa di analogo:
Learned tokens from 165 message(s) (165 message(s) examined)

I tokens sono singole parole e brevi frasi: SpamAssassin le memorizza e poi, utilizzando metodi statistici, arriva a concludere che quando molti messaggi che è stato istruito a considerare spam (tramite sa-learn) contengono lo stesso token, allora probabilmente anche un successivo messaggio contenente quel token sarà uno spam. Lo stesso vale per i messaggi ham.

^top

Configurazione di SpamAssassin

Abbiamo detto che la configurazione standard di SpamAssassin è adeguata per una rapida partenza nel suo utilizzo.

Di seguito vediamo le principali variabili settabili e alcuni suggerimenti per rendere il funzionamento del programma più efficace ed efficiente.

SpamAssassin crea il file di configurazione personale nella home dell'utente al momento del prima esecuzione sul sistema a cura dell'utente stesso (viene effettuata una copia di /etc/spamassassin/user_prefs.template).

Già all'installazione, invece, vengono creati i file di configurazione system wide (contenuti in /etc/spamassassin).

Vediamo un esempio di file di configurazione personale (~/.spamassassin/user_prefs). Alcuni settaggi non sono attivati perchè il default va già bene, ma li ho lasciati perchè tramite la spiegazione commentata possiamo approfondire ulteriormente il modus operandi di SpamAssassin.

# SpamAssassin user preferences file.
# esegui perldoc Mail::SpamAssassin::Conf
# per la pagina di manuale
# Customized by Ataualpa aka Francesco Ciattaglia
##############################

# Punteggio oltre il quale un messaggio viene taggato come spam.
# Riducendo la soglia, si rende più restrittiva la verifica
# default: 5.0 (intero o numero reale. es: 5 o 5.2)
required_score 4.5

# SpamAssassin non modifica gli header Subject, From o To per
# indicare quando ha classificato il messaggio come spam.
# Settando l'opzione seguente l'header specificato viene modificato
# aggiungendo la stringa specificata.
# Nell'header Subject la stringa viene premessa. Negli header
# From e To, la stringa viene aggiunta in fondo.
# rewrite_header { subject | from | to } STRING
# es: rewrite_header Subject [SPAM]
# altro es: rewrite_header Subject [SPAM (_SCORE_)]

# Interruttore per abilitazione/disabilitazione filtro bayesiano
# Il valore di default è 1 (attivo). Pertanto usare solo per
# disattivarlo (settando a 0).
# use_bayes 0

# SpamAssassin utilizza la valutazione offerta dal filtro bayesiano
# solo dopo essere stato istruito su un certo numero di messaggi
# (affinchè l'apprendimento risulti sufficientemente consistente e
# quindi affidabile).
# Con queste variabili si può modificare il numero di ham e spam
# che deve essere raggiunto per iniziare a usare il filtro bayes
# default: 200
#bayes_min_ham_num 200
#bayes_min_spam_num 200

# Interruttore per abilitazione/disabilitazione del classificatore
# interno per istruire automaticamente il filtro bayesiano.
# Il valore di default è 1 (attivo). Pertanto usare solo per
# disattivarlo (settando a 0).
# use_bayes_rules 0

# Interruttore per abilitazione/disabilitazione della funzione di auto
# apprendimento (autolearning) utilizzando il classificatore interno.
# Il valore di default è 1 (attivo). Pertanto usare solo per
# disattivarlo (settando a 0).
# bayes_auto_learn 0

# Le due opzioni seguenti sono previste dal plugin
# Mail::SpamAssassin::Plugin::AutoLearnThreshold
# ed entrano in gioco se l'autolearning è attivo.

# Livello di score che il messaggio non deve superare per
# essere inserito come messaggio ham nel sistema di
# autolearning di SpamAssassin.
# default: 0.1
bayes_auto_learn_threshold_nonspam 0.1

# Livello di score che il messaggio deve almeno avere per
# essere inserito come messaggio spam nel sistema di
# autolearning di SpamAssassin.
# default: 12.0
bayes_auto_learn_threshold_spam 15

# Una volta che il filtro Bayes è stato adeguatamente addestrato
# con il risultato che produce catalogazioni affidabili, è
# consigliato ridefinire (decommentando i settaggi seguenti)
# gli score attribuiti in caso di messaggi con elevata probabilità
# di essere ham o spam. In tal modo si esalta l'impatto del filtro
# Bayes sul punteggio complessivo attribuito al messaggio.
# score BAYES_00 -4
# score BAYES_05 -2
# score BAYES_95 6
# score BAYES_99 9

# La funzione di Auto Whitelist (AWL) è preferibile disattivarla
# finchè la precisione nella catalogazione dei messaggi da parte
# di SpamAssassin non è stata verificata come adeguata. Se un
# un indirizzo email mittente di un messaggio spam/ham non
# riconosciuto viene inserito nella AWL, si corre il rischio di
# avere messaggi mal catalogati per un certo periodo di tempo.
use_auto_whitelist 0

# Gli header aggiunti da SpamAssassin sono da lui, ovviamente,
# conosciuti e pertanto non lo disturbano quando viene istruito.
# Eventuali altri header inseriti da chi ci ha spedito il messaggio
# o dai server attraverso cui è transitato è preferibile segnalarli
# come da non considerare. Analizzate gli header della posta in
# arrivo per identificarli.

# header tratti dai messaggi ricevuti
bayes_ignore_header X-NAI-Spam-Score
bayes_ignore_header X-ifm
bayes_ignore_header X-ifm-sid
bayes_ignore_header X-Scanned
bayes_ignore_header X-Virus-Status
bayes_ignore_header X-Virus-Scanned
bayes_ignore_header X-SGN-MailScanner-Information
bayes_ignore_header X-SGN-MailScanner
bayes_ignore_header X-MailScanner-From
bayes_ignore_header X-Rc-Spam
bayes_ignore_header X-Rc-Virus
bayes_ignore_header X-IronPort-Anti-Spam-Filtered
bayes_ignore_header X-IronPort-Anti-Spam-Result
bayes_ignore_header X-IronPort-AV
bayes_ignore_header X-Antivirus
bayes_ignore_header X-Antivirus-Status
bayes_ignore_header X-Brightmail-Tracker

# header tratti da internet
bayes_ignore_header X-s.logic-spamassas-bar
bayes_ignore_header X-s.logic-spamassas
bayes_ignore_header X-SA-Exim
bayes_ignore_header X-MailScanner-Information
bayes_ignore_header X-MailScanner
bayes_ignore_header X-MailScanner-SpamCheck
bayes_ignore_header X-Sanitizer
bayes_ignore_header X-purgate
bayes_ignore_header X-purgate-ID
bayes_ignore_header X-purgate-Ad
bayes_ignore_header X-GMX-Antispam
bayes_ignore_header X-Antispam
bayes_ignore_header X-Spamcount
bayes_ignore_header X-Spamsensitivity
bayes_ignore_header X-Bogosity
bayes_ignore_header X-CRM114
bayes_ignore_header X-Sieve

# Directory e basename dei database Bayes.
# Spamassassin crea diversi database nella directory e con il
# basename specificati con questo settaggio.
# I database creati con il settaggio di default
# (~/.spamassassin/bayes) sono:
# ~/.spamassassin/bayes_seen, ~/.spamassassin/bayes_toks, etc.
# bayes_path /path/filename

# SpamAssassin consente di specificare degli indirizzi come
# appartenenti a whitelist e a blacklist.
# Le modalità per indicare un indirizzo sono:
# "[email protected]", "*@isp.com", o "*.domain.net".
# whitelist_from [email protected]
# blacklist_from [email protected]

# Score da assegnare ai test eseguiti da SpamAssassin.
# Per alcuni test si può ritenere opportuna una personalizzazione
# dello score associato al buon esito del test. Se non cusotmizzati
# gli score associati sono quelli definiti system wide nel file dei test.
# Per vedere la lista dei test ed il loro score di default
# http://spamassassin.apache.org/tests.html .
#
# score SYMBOLIC_TEST_NAME n.nn

# Speakers of any language that uses non-English,
# accented characters may wish to uncomment
# the following lines.
# They turn off rules that fire on misformatted
# messages generated by common mail apps in
# contravention of the email RFCs.
# score SUBJ_ILLEGAL_CHARS 0

# Opzione che specifica quali locales sono considerati
# Ok per i messaggi in arrivo.
# en = Western character sets
ok_locales en

# lingue utilizzate nel corpo del messaggio da considerare
# valide (se presenti altre il messaggio va considerato spam)
# default: all
# il settaggio serve se è abilitato il plugin nel file
# /etc/spamassassin/v310.pre (disabilitato di default)
# loadplugin Mail::SpamAssassin::Plugin::TextCat
# ok_languages it en

# Opzioni per i network test
# Disabilita controlli RBL (Real Time Blacklists).
# Abilitati di default (valore 0).
# Pertanto settare solo se si vogliono disabilitare (ponendo a 1).
# skip_rbl_checks 1

# Utilizzazione di razor2, dcc, pyzor
# I settaggi use_razor2, use_dcc, use_pyzor oggi vanno settati nel
# file /etc/spamassassin/v310.pre. Le righe interessate sono:
# loadplugin Mail::SpamAssassin::Plugin::DCC
# loadplugin Mail::SpamAssassin::Plugin::Pyzor
# loadplugin Mail::SpamAssassin::Plugin::Razor2

# If you're using SpamAssassin for non-commercial use, you may
# also want to turn on the MAPS rules, which are useful DNSBLs.
score RCVD_IN_MAPS_RBL 2.0
score RCVD_IN_MAPS_DUL 1.0
score RCVD_IN_MAPS_RSS 2.0
score RCVD_IN_MAPS_NML 2.0

Verificare la configurazione di SpamAssassin

Da terminale digitiamo:

spamassassin --lint --D

Ciò per una opportuna verifica:

sui moduli installati e non;
sul corretto caricamento dei file con le regole e la configurazione;
sul corretto caricamento dei moduli disponibili;
sulla eseguibilità dei test.

Analizzando l'output prodotto, potremo accertarci che non ci siano errori di configurazione che bloccano SpamAssassin.

^top

L'efficientamento di SpamAssassin

SPF Query per verificare la congruità indirizzo vs. server SMTP

SpamAssassin dalla versione 3.0 utilizza di default anche i controlli SPF (Sender Policy Framework), che verificano la legittimità di un indirizzo email in base al server smtp che quell'indirizzo deve utilizzare per la spedizione dei messaggi.

Ad esempio se ho un indirizzo alice.it, il mio server smtp non può essere quello di libero che, proprio per evitare di essere utilizzato per spammare, consente l'invio dei messaggi solo agli indirizzi del proprio dominio.

Per poter utilizzare questo tipo di controllo, abilitato nella configurazione di default, dobbiamo avere installato il modulo perl Mail::SPF::Query.

Verifichiamo se il modulo è installato con:

perl -e 'require Mail::SPF::Query'

Dobbiamo installare se otteniamo un errore che lamenta l'impossibilità di trovare il modulo.

L'installazione la eseguiamo (da root) mediante il comando:

# perl -MCPAN -e 'install Mail::SPF::Query'

Analogamente è utile installare il modulo IP::Country::Fast, che consente una veloce verifica del country code mediante l'indirizzo IP.

Aggiornare le regole euristiche di SpamAssassin con sa-update

SpamAssassin dispone di un comando (sa-update) che, eseguito da root, consente di scaricare eventuali nuovi set di regole (in /var/lib/spamassassin) resi disponibili dagli sviluppatori del software.

In Debian, all'installazione di SpamAssassin, viene impostato un cron job giornaliero che consente l'automazione del download di nuove regole e, in caso le precedenti siano state compilate (vedi paragrafo successivo), provvede alla ricompilazione.

Velocizzare SpamAssassin con sa-compile

SpamAssassin dispone del plugin sa-compile che, grazie alla compilazione delle regole, è in grado di velocizzare i tempi di esecuzione dei test sui messaggi. Forse è grazie a questo, che non mi lamento nemmeno della velocità di SpamAssassin?

Per utilizzarlo è necessario:

installare il pacchetto re2c (# apt-get install re2c);
editare /etc/spamassassin/v320.pre, togliendo il commento a loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody
lanciare (da root) sa-compile

In Debian, l'installazione di SpamAssassin crea anche un cron job che provvede ad una periodica riesecuzione di sa-compile.

Velocizzare SpamAssassin eseguendolo come demone

SpamAssassin può girare sul sistema anche come demone. In tal modo si evita di rilanciare SpamAssassin per ogni messaggio da analizzare.

Se già non fatto dovremo installare spamc (il client) e spamd (il daemon).

Usando il demone, la chiamata di Spamassassin effettuata in Procmail sarà verso il suo client, ovvero spamc.

Addestrare SpamAssassin con un db di spam già pronto

Il filtro bayesiano di SpamAssassin, ancorchè attivo (e lo è di default), non entra in gioco nella valutazione dei messaggi se non dopo essere stato istruito su almeno 200 messaggi ham e 200 spam.

Nel file di configurazione è possibile, seppur non consigliabile, ridurre tale numero minimo (variabili bayes_min_ham_num e bayes_min_spam_num).

Una alternativa è quella di addestrarlo utilizzando un database altrui.

A tal fine, in rete sono disponibili molti db bayes di SpamAssassin. Uno, preferibile perchè italiano, è scaricabile dal sito di Michele Marcucci alla pagina Bloccare lo spam con il mio database SpamAssassin.

Per la posa in opera:

scaricare il file spamassassin-bayes-db.tar.bz2
scompattarlo (ad es. in $HOME/.spamassassin)
eseguire sa-learn --restore spamassassin-bayes-db

Poichè con il restore il database eventualmente esistente viene resettato, consiglio di effettuare questa operazione agli inizi dell'utilizzo di SpamAssassin.

Secondo i programmatori di SpamAssassin è preferibile non addestrare il filtro Bayes con email altrui o con archivi di spam pubblici. Il filtro bayes potrebbe essere indotto a considerare che alcuni token vadano associati a spam o ham quando ciò non è corretto, rendendo meno affidabile la valutazione bayesiana.

In tal caso, essendo l'archivio italiano, forse si hanno meno problemi, lascio comunque al lettore la decisione di utilizzare il database succitato.

Personalmente non ho riscontrato anomalie evidenti, potendo d'altro canto avvalermi da subito del lato bayesiano di SpamAssassin :-)

^top

Conclusione

In questo nono capitolo, relativamente all'utilizzo di SpamAssassin contro lo spam, abbiamo imparato:

Le logiche di funzionamento di SpamAssassin.
La configurazione di Procmail e Mutt per utilizzare SpamAssassin.
L'esecuzione di un cronjob per addestrare SpamAssassin.
La configurazione di SpamAssassin.
La compilazione delle regole per velocizzare SpamAssassin.
L'esecuzione di SpamAssassin come demone.
L'utilizzo di un database altrui per istruire SpamAssassin.

PS Preferite Bogofilter?

Se volere provare Bogofilter, antispam bayesiano, scritto originariamente in C da Eric Raymond, in rete sono disponibili numerose pagine di spiegazione, anche chiarificatrici di ciò che va settato per integrarlo con Procmail e con Mutt.

In lingua italica, segnalo Gestire la posta con Mutt, Procmail e Bogofilter di Mirko Maischberger.

Nella lingua di Albione, potete invece dare un'occhiata a Spam Filtering with Bogofilter.

<< Capitolo Precedente Prossimo Capitolo >>

Il Nirvana Con Mutt

Integrare il sistema di posta con SpamAssassin

Le generalità di SpamAssassin

Come funziona SpamAssassin

Configurazione di Procmail per SpamAssassin

Configurazione di Mutt per SpamAssassin

Addestrare SpamAssassin con un cron job

Configurazione di SpamAssassin

L'efficientamento di SpamAssassin

Conclusione