Nuova pagina di appunti dedicata a SpamAssassin, basata sull'esperienza con SpamAssassin 3.2.4 su Debian Lenny.

Anzitutto si è deciso di chiamare SpamAssassin non come filtro del programma di posta (Exim), ma come filtro sulla consegna in mailbox tramite procmail(1). Questo consente una migliore personalizzazione del sistema antispam per ogni singolo utente.

Come di consueto si installa la versione daemon (più performante) spamd e il relativo client spamc.

Come verificare cosa funziona e cosa no. Grazie a spamassassin –help oppure a man spamassassin-run si scopre il comando:

spamassassin --lint -D

che visualizza tanti messaggi di debug relativi al set di regole, riportando errori di sintassi ecc.

Per testare il funzionamento del filtro su un messaggio si esegue semplicemente:

cat messaggio_spam.txt | spamc | less

È possibile avere un rapporto dettagliato dell'analisi con i punteggi ottenuti dalle singole regole con il comando:

spamassassin -t < messaggio.txt

La scansione non passa per spamd, ma lancia un'istanza di spamassassin per la singola esecuzione. La configurazione usata dovrebbe essere quella di sistema in /etc/spamassassin. Utile ad esempio per testare delle variazioni sui punteggi assegnati tramite regole inserite in /etc/spamassassin/local.cf.

Un messaggio contenente un link blacklisted non viene intercettato dalle regole URIBL_*, scopriamo perché. Anzitutto vediamo quali test vengono effettuati:

cat messaggio_spam.txt | spamc -y
AWL,BAYES_00

Hanno dato risultati solo i test Auto-whitelist e Bayesian spam probability, mancano i risultati dei test URIBL_*.

Quando i test URIBL_ danno dei risultati si ha un output di questo tipo:

cat messaggio_spam.txt | spamc -y
RDNS_NONE,SPF_PASS,URIBL_AB_SURBL,URIBL_BLACK,URIBL_JP_SURBL,
    URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL

e anche un dump delle richieste DNS originate dal server può rivelare se i test vengono effettuati:

tcpdump -i eth1 -n 'port 53'
... > 206.222.12.226.53: 62184% [1au] A? 26.16.57.88.plus.bondedsender.org. (62)
... > 209.67.211.202.53: 41563% [1au] TXT? 26.16.57.88.bl.spamcop.net. (55)
... > 217.23.130.99.53: 26316% [1au] TXT? 26.16.57.88.list.dsbl.org. (54)

Invece di passare per spamc/spamd proviamo a passare direttamente per spamassassin, si scopre che in questo caso i test URIBL vengono fatti:

cat messaggio_spam.txt | spamassassin | less

Riavviando il demone spamd il problema si risolve, quindi esiste qualche condizione (insufficienza di RAM?) che avvelena il demone senza ucciderlo del tutto, rendendolo quasi del tutto inefficace.

È possibile impostare forzatamente un punteggio SPAM molto alto (+100) o molto basso (-100) per un particolare indirizzo email nel proprio database $HOME/.spamassassin/auto-whitelist:

spamassassin --add-addr-to-blacklist='spammer@spam.net'
spamassassin --add-addr-to-whitelist='niccolo@rigacci.org'

Per togliere l'indirizzo dal database si usa:

spamassassin --remove-addr-from-whitelist='niccolo@rigacci.org'

Qualche volta si trova nel file di log il messaggio di warning:

Jan 19 18:33:56 spamd[7122]: prefork: server reached --max-children setting, consider raising it

Debian mette in /etc/default/spamassassin l'opzione –max-children 5 e sconsiglia di modificarla. Per capire in quali circostanze avviene il problema eseguiamo il comando:

grep "prefork: child state" /var/log/syslog | less
Jan 20 16:08:28 spamd[7122]: prefork: child states: II
Jan 20 16:09:31 spamd[7122]: prefork: child states: II
Jan 20 16:10:45 spamd[7122]: prefork: child states: II
Jan 20 16:10:50 spamd[7122]: prefork: child states: BB
Jan 20 16:10:50 spamd[7122]: prefork: child states: BBB
Jan 20 16:10:50 spamd[7122]: prefork: child states: BBBB
Jan 20 16:10:50 spamd[7122]: prefork: child states: BBBIB
Jan 20 16:10:54 spamd[7122]: prefork: child states: BBBBB
Jan 20 16:10:58 spamd[7122]: prefork: child states: BBBBB
Jan 20 16:11:02 spamd[7122]: prefork: child states: BBBBB
Jan 20 16:11:03 spamd[7122]: prefork: child states: BBBBB
Jan 20 16:11:06 spamd[7122]: prefork: child states: BBBBB
Jan 20 16:11:06 spamd[7122]: prefork: child states: BBBBI
Jan 20 16:11:08 spamd[7122]: prefork: child states: BBIBI
Jan 20 16:11:08 spamd[7122]: prefork: child states: IBIBI
Jan 20 16:11:08 spamd[7122]: prefork: child states: IBIB
Jan 20 16:11:09 spamd[7122]: prefork: child states: IBII
Jan 20 16:11:09 spamd[7122]: prefork: child states: IBI
Jan 20 16:11:10 spamd[7122]: prefork: child states: III
Jan 20 16:11:10 spamd[7122]: prefork: child states: II
Jan 20 16:12:59 spamd[7122]: prefork: child states: II
Jan 20 16:13:10 spamd[7122]: prefork: child states: II

Come si vede si è verificato un burst di mail durato circa 20 secondi durante il quale i 5 processi figli erano Busy ed altre richieste non sono state soddisfatte (lo stato dei child process può essere Idle, Starting, Killed o Busy).

A seconda dei casi si può aumentare il numero dei processi figli oppure renderli più veloci. Ad esempio l'accesso alle preferenze dell'utente contenute in $HOME/.spamassassin/ probabilmente non è concorrente e blocca i processi successivi. Forse spostare le preferenze in un database potrebbe migliorare le prestazioni.