Filtrare lo spam con rspamd
A questo punto avete un server di posta perfettamente funzionante. Ma prima di andare online facciamo qualcosa per la quantità assurda di spam. Nelle versioni precedenti di questa guida ho usato e raccomandato SpamAssassin. Tuttavia ho trovato un pezzo di software che è più versatile, scala meglio ma è comunque facile da integrare: rspamd. rspamd ha una comparazione (forse non obbiettiva) nella sua homepage.
rspamd è un processo permanente che gira sul vostro server. Ascolta connessioni da Postfix usando il protocollo milter (=mail filter). Ogni volta che una mail entra nel vostro sistema, Postfix la manda a rspamd per controllarne il contenuto. rspamd fa molti controlli sulla mail e computa un punteggio totale. Maggiore il punteggio – più è probabile che la mail deve essere considerata indesiderata.
Far usare rspamd a Postfix
Diciamo a Postfix di mandare tutte le mail in arrivo a rspamd. Lanciamo questi comandi nella 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 si connetterà ora a rspamd che sta ascoltando sulla porta TCP 11332 su localhost (127.0.0.1) e passa la mail su questa connessione. Vediamo le opzioni nel dettaglio:
- smtpd_milters definisce la connessione per le email che entrano nel sistema da internet usando il protocollo SMTP.
- non_smtpd_milters è opzionale – serve per controllare tutte le mail originate dal sistema stesso.
- milter_mail_macros definisce alcune variabili che rspamd si aspetta per migliorare il rilevamento dello spam. rspamd poi fa i suoi controlli e dice a Postfix se la mail debba passare o essere respinta.
Testare il rilevamento spam
Per fare un test possiamo usare una mail spam di prova di SpamAssassin. Si chiama GTUBE (Generic Test for Unsolicited Bulk Email). Contiene uno schema creato ad hoc che viene riconosciuto come spam da SpamAssassin. Conoscete EICAR.COM per testare gli antivirus? Questo è lo stesso per lo spam.
Suggerisco di scaricare il file sul server:
wget http://spamassassin.apache.org/gtube/gtube.txt
…e spedire questa mail al nostro utente di prova John…
sendmail john@example.org < gtube.txt
Controllate /var/log/mail.log. Troverete qualcosa di simile:
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)
Le parti interessanti sono quelle in grassetto. “milter-reject” ci dice che il milter (rspamd) ha raccomandato a Postfix di rifiutare la mail, con motivazione “5.7.1 Gtube pattern”. Nelle comunicazioni mail trovate spesso questi codici a tre cifre. Sono definiti nell’RFC3463. La prima cifra è la più importante:
- 2 = Successo
- 4 = Errore transitorio (problema temporaneo – riprovare più tardi)
- 5 = Errore permanente (non riprovare in questo modo)
Quindi 5.7.1 ci dice che il risultato è un errore permanente nella consagna. Se leggete l’RFC troverete che 7 sta per un problema riguardante la politica di sicurezza. Quindi non è un errore tecnico, ma un componente rilevante della sicurezza del sistema ha rifiutato la mail. Quello che ha fatto rspamd. Ci ha anche detto la ragione: “Gtube pattern”. Quindi rspamd sa dello schema del test spam e reagisce come previsto.
Di conseguenza non vedrete questa email nella inbox di John. A proposito usare i milter porta ad un grande vantaggio. Immagine che Postfix riceva una mail di spam e confermi la sua ricezione. Cosa dovrebbe fare se scopre che è una mail indesiderata? Secondo il protocollo non deve buttare via alcuna mail. Creereste un messaggio di bounce per dire al mittente che non avete accettato la mail? Sarebbe una cattiva idea perché è improbabile che il mittente sia quello reale. Mandereste il bounce ad una persona innocente creando così un cosiddetto backscatter, peggiorando le cose. L’approccio giusto è di controllare la mail mentre il server mittente è ancora connesso al nostro Postfix. Questo permette a Postfix di rifiutare la mail con un errore 5.x.x , lasciando la controparte decidere cosa fare.
Misura del punteggio (opzionale)
rspamd però non rifiuterà tutta la posta indesiderata. Quando calcola il punteggio della probabilità che una mail sia spam, potete dirgli quali accettare, quali segnare come spam e quali rifiutare. Date un’occhiata al file /etc/rspamd/metrics.conf. Ci sono tonnellate di punteggi definiti per varie condizioni. All’inizio del file troviamo:
actions { reject = 15; add_header = 6; greylist = 4; }
Queste sono le azioni di default. Se rspamd calcola un punteggio di almeno 15, allora la mail viene rifiutata, come lo schema Gtube nel test precedente. Un punteggio sopra 6 aggiunge l’header “X-Spam: Yes”, in modo che il nostro software mail possa rilevarli e magari mattere il file in un’altra cartella. Un punteggio sopra 4 innesca il greylisting che è un meccaniscmo che rifiuta temporaneamente la mail con un codice 4.x.x ed aspetta di vedere se il server mittente prova di nuovo. Dopo un’attesa di un paio di minuti il greylisting accetterà la mail. L’idea è di rifiutare le mail da sistemi che non hanno una coda di spedizione. Malware su computer Wind*ws infetti erano soliti mandare la mail solo una volta, innescando il greylisting che respingeva lo spammer con successo. Ma anche i programmatori di malware hanno imparato la lezione e possono provare ancora dopo qualche minuto, aggirando il greylisting. Le vostre esperienze potrebbero essere diverse.
Se volete cambiare questi valori predefiniti, create un nuovo file in /etc/rspamd/override.d/metrics.conf contenente:
actions { reject = 150; add_header = 2; greylist = 5; }
Questo virtualmente non rifiuterebbe mai una mail. E segnerebbe come spam ogni mail con punteggio di almeno 2. Il greylisting avverrebbe con un punteggio superiore a 5. Questi non sono necessariamente valori sensati – sono solo un esempio.
Prendetevi un momento per capire come cambiare i valori predefiniti di rspamd. Potete o creare file in /etc/rspamd/local.d/…, che sostituiranno sezioni intere; oppure creare file in /etc/rspamd/override.d/…, che sostituiranno solo piccole parti della configurazione. C’è una utile pagina nella documentazione di rspamd che contiene esempi. In ogni caso – mai modificare i file in /etc/rspamd/* direttamente perché un aggiornamento del software cercherà di rimpiazzarli.
Naturalmente riavviare rspamd dopo qualsiasi modifica alla configurazione:
service rspamd reload
Per controllare se rspamd ha recepito le modifiche usiamo questo comando per vedere la configurazione corrente:
rspamadm configdump
Possiamo testare la configurazione usando
rspamadm configtest
Alternativamente possiamo controllare se tutti i processi di rspamd necessari stanno girando…
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
Aggiungere intestazioni (header)
Come saprete una mail contiene l’intestazione e il corpo. I nostri utenti vedono solo informazioni dell’intestazione come oggetto, mittente, destinatario e date e orario in cui la mail è stata spedita. Ma ci sono molte altre informazioni come il router che la mail ha attraversato o intestazioni estese aggiunte da vari server di posta nel tragitto verso la destinazione. Queste intestazioni estese cominciano con “X-“. rspamd può aggiungere queste intestazioni per aiutarci a filtrare lo spam. Per questo scopo creiamo un file di configurazione /etc/rspamd/override.d/milter_headers.conf con questo contenuto:
extended_spam_headers = true;
Come documentato aggiungerà queste intestazioni:
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
Ogni simbolo in maiuscolo come FROM_HAS_DN significa che un certo rilevatore di rspamd si è innescato. Non significa necessariamente qualcosa di male rigurado la mail. Per esempio R_SPF_ALLOW ha un punteggio negativo che abbassa il punteggio totale perché è qualcosa di buono per la mail. Ci sono diversi simboli con punteggio 0.00. Questi non cambiano il punteggio ma ci mostrano cosa rspamd ha trovato. Se valutate certi criteri buoni o cattivi potete definire i loro punteggi.
L’ultima linea è particolarmente interessante perché il prossimo della nostra lista è…
Spostare lo spam nella cartella della posta indesiderata
I nostri utenti non si accorgeranno che le loro mail spam hanno l’header “X-Spam: Yes” aggiunto. Le loro mail appaiono normali nella loro inbox. Aiutiamoli spostando automaticamente lo spam nella cartella della posta indesiderata dentro l’inbox. Dovecot supporta i filtri Sieve che in pratica sono degli script lanciati automaricamente quando arriva una mail.
John potrebbe loggarsi in Roundcube e configurarsi un nuovo filtro Sieve che salva tutte le mail nella sua posta indesiderata se l’header “X-Spam: Yes” viene trovato. Questa regola potrebbe tornare utile a tutti i nostri utenti, quindi cerchiamo una soluzione generale.
Nota
SpamAssassin, usato nelle versioni precedenti di questa guida, usa un header leggermente differente: “X-Spam-Flag: YES”. Assicuratevi di modificare i vostri filtri Sieve di conseguenza.
Dovecot supporta filtri Sieve globali che si applicano a tutti gli utenti. Modifichiamo il file /etc/dovecot/conf.d/90-sieve.conf. Cerchiamo le linee “sieve_after”. Sono commentate. Quindi aggiungiamo una nuova linea qui:
sieve_after = /etc/dovecot/sieve-after
Il filtro “sieve after” sono eseguiti dopo quelli dell’utente. John può definire i propri filtri. Dopodiché Dovecot controllerà tutti i filtri che trova nei file dentro /etc/dovecot/sieve-after. Creiamo questa cartella:
mkdir /etc/dovecot/sieve-after
E creiamo un file /etc/dovecot/sieve-after/spam-to-folder.sieve contenente:
require ["fileinto","mailbox"];
if header :contains "X-Spam" "Yes" {
fileinto :create "INBOX.Junk";
stop;
}
La linea “require” include funzionalità per muovere le mail in una certa cartella (fileinto) e per creare cartelle se non esistono (mailbox). Quando rspamd segna un mail come spam, questa viene messa nella cartella INBOX.Junk che all’utente apparirà solo come “Junk” sotto la loro inbox.
Dovecot non riesce a gestire questi file in formato leggibile. Dobbiamo compilarli:
sievec /etc/dovecot/sieve-after/spam-to-folder.sieve
Questo genera il file compilato /etc/dovecot/sieve-after/spam-to-folder.svbin.
Riavviamo Dovecot:
service dovecot restart
Ora lo spam di tutti gli utenti verrà spostato automaticamente nelle loro cartelle di posta indesiderata. Carino, non trovate?
Apprendere lo spam esistente
Se avete seguito le precedenti guide ISPmail allora avete usato SpamAssassin per un po’. L’avete istruito per un po’ con mail ham (buone) e spam (indesiderate) che hanno alimentato il database Bayes integrato per aumentare la sua affidabilità di rilevamento. La cattiva notizia è che non potete usare questi dati in rspamd perché usa un algoritmo differente. Ci sono tre modi per cominciare con rspamd…
(a) Nessun apprendimento Bayes
Non è così male come sembra. rspamd ha molte più funzionalità per determinare se una mail è ham o spam. Raccomando di abilitare l’auto apprendimento. Create un nuovo file /etc/rspamd/override.d/classifier-bayes.conf e metteteci dentro:
autolearn = true;
E’ un approccio molto conservativo. Cataloga mail come spam se sono così male che vengono rifiutate. E le cataloga come ham se hanno un punteggio negativo (= molto buono). La documentazione di rspamd ha ulteriori esempi di come mettere a punto l’auto apprendimento.
(b) Usare statistiche preimpostate
rspamd fornisce un database campione con oltre 3000 mail acquisite. Sono del 2015 e forse non sono una buona partenza perché la natura dello spam cambia col tempo.
Stoppiamo rspamd:
service rspamd stop
Prendiamo le loro statistiche preimpostate e mettiamo i file *sqlite nella cartella /var/lib/rspamd. Correggiamo il proprietario di questi file lanciando…
chown _rspamd._rspamd /var/lib/rspamd/*sqlite
E finalmente avviamo rspmad ancora…
service rspamd start
Verifichiamo che il database sia aggiornato lanciando…
rspamc stat
Alla fine dell’output troviamo qualcosa tipo questo…
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) Ri-apprendere ham e spam esistenti
State facendo girare il vostro server già da un po’? Ed avete un buon quantitativo di mail ham e spam? Allora usiamole per addestrare rspamd. E’ importante farlo sia con mail ham che spam.
Il comando rspamc ci consente di dare in pasto al processo di apprendimento intere cartelle di posta. Fortunatamente noi usiamo il formato Maildir per salvare le mail che rspamd capisce. Un esempio per analizzare spam:
rspamc learn_spam /var/vmail/example.org/john/Maildir/.INBOX.Junk/cur
E questo è un esempio per analizzare ham:
rspamc learn_ham /var/vmail/example.org/john/Maildir/cur".
Naturalmente la qualità del rilevamento spam dipende da quanto buona è la fonte dei dati. Quindi per l’addestramento non usate mail spam da utenti che mettono nella loro posta indesiderata mail che non sono in realtà spam.
Controlliamo il numero di mail analizzate lanciando…
rspamc stat
La verifica spam bayesiana non funzionerà prima che siano analizzate almeno 200 mail di spam e ham. Istruire rspamd con meno mail o solo mail spam non funzionerà. Questo è definito dalla variabile min_learns definita in /etc/rspamd/statistic.conf.
Nell’output troviamo che cominciano con “Statfile”…
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
Questo è ciò con cui si parte di solito. Più mail usate nel processo di apprendimento, migliore sarà il tasso di rilevamento. Alcune mail tuttavia possono non essere lunghe abbastanza o essere troppo simili a mail già analizzate. Quindi non preoccupatevi se state anlizzando 1000 mail ma qui ne vedete solo 500.
Apprendere dalle azioni degli utenti
Ora facciamo qualcosa di veramente carino. Diciamo a Dovecot che spostare una mail nella posta indesiderata istruisce rspamd istantaneamente che la mail è spam. E che la mail è ham se è spostata fuori dalla posta indesiderata. Aggiungeremo dei meccanismi di attivazione (in realtà “sieve script”) all’azione di spostare le mail via IMAP.
C’era un plugin di Dovecot carino chiamato “Antispam” ma sfortunatamente è ora sconsigliato. Peccato. Il metodo al momento raccomandato è usare il plugin “IMAPSieve“. Non c’è niente da installare – è già nei pacchetti di Dovecot. Dobbiamo solo configurarlo.
Un avvertimento
Al momento il database di apprendimento spam è globale per tutti gli utenti. Se un utente deliberatamente lo istruisce con spazzatura, rovinerà il vostro tasso di rilevamento. L’approccio descritto qui è idoneo solo per utenti fidati che sanno distinguere ham da spam. E’ anche possibile con rspamd istruire lo spam per ogni utente ma questo va oltre gli scopi di questa guida e può anche diventare problematico perché la maggior parte degli utenti non ricevono abbastanza mail ham e spam per far funzionare correttamente il rilevamento dello spam. Se siete interessati nell’apprendimento spam per ogni utente vedete la relativa documentazione di rpsamd.
Il primo passo è abilitare il plugin IMAPSieve per il protocollo/servizio IMAP in Dovecot. Editiamo il file /etc/dovecot/conf.d/20-imap.conf e troviamo la linea “mail_plugins”. Cambiatela in:
mail_plugins = $mail_plugins imap_sieve
Dobbiamo anche editare la configurazione di Sieve di Dovecot per abilitare due plugin necessari per questo compito. Sieve è un linguaggio di scripting che automatizza tutto ciò che correla mail e cartelle. Editate il file /etc/dovecot/conf.d/90-sieve.conf. Per prima cosa alteriamo la linea “sieve_plugins” così:
sieve_plugins = sieve_imapsieve sieve_extprograms
Ed aggiungiamo queste linee dentro la sezione { … }:
# From elsewhere to Junk folder imapsieve_mailbox1_name = Junk imapsieve_mailbox1_causes = COPY imapsieve_mailbox1_before = file:/etc/dovecot/sieve/learn-spam.sieve # From Junk folder to elsewhere 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 prima regola dice a Dovecot di lanciare le regole Sieve definite nel file /etc/dovecot/sieve/learn-spam.sieve ogniqualvolta una mail viene messa nella cartella “Junk” dell’utente. Creeremo questo script Sieve fra un minuto.
Le seconda regola fa il contrario. Quando una mail viene mossa dalla cartella “Junk” ad una qualsiasi allora lo script Sieve /etc/dovecot/sieve/learn-ham.sieve viene chiamato.
L’opzione “sieve_pipe_bin_dir” definisce dove gli script eseguibili possono risiedere. Metteremo i nostri semplici script di apprendimento qui. Infine l’opzione “sieve_global_extensions” abilita il plugin “pipe” che permette di mandare mail a comandi esterni.
Nota
Se provenite da versioni precedenti di questa guida, le vostre cartelle mail possono usare ancora i punti (“.”) invece che percorsi (“/”) per comporre la struttura delle cartelle. Un chiaro segno di ciò è avere cartelle tipo “INBOX.Junk” invece di solo “Junk” nelle cartelle mail dentro /var/vmail. In tal caso sostituite la parole “Junk” con “INBOX.Junk” nella sezione sopra.
Creiamo poi gli script Sieve definiti in Dovecot. Creiamo una nuova cartella /etc/dovecot/sieve per metterci dentro i nostri nuovi file:
mkdir /etc/dovecot/sieve
Creiamo quindi il file /etc/dovecot/sieve/learn-spam.sieve che contiene:
require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-spam.sh";
Facciamo lo stesso con /etc/dovecot/sieve/learn-ham.sieve
require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamd-learn-ham.sh";
Questi due script devono esser compilati – cioè trasformati in un codice leggibile dalla macchina:
sievec /etc/dovecot/sieve/learn-spam.sieve
sievec /etc/dovecot/sieve/learn-ham.sieve
Questo crea due nuovi file “learn-ham.svbin” e “learn-spam.svbin” che dentro sembrano spazzatura ma che ora sono in un formato che il plugin Sieve di Dovecot può comprendere.
Correggiamo anche i permessi di questi file già che ci siamo:
chmod u=rw,go= /etc/dovecot/sieve/learn-{spam,ham}.sieve
chown vmail.vmail /etc/dovecot/sieve/learn-{spam,ham}.sieve
E l’ultimo passo è quello di creare i semplice script shell che fanno l’effettivo addestramento spam/ham. Il primo file è /etc/dovecot/sieve/rspamd-learn-spam.sh che contiene:
#!/bin/sh
exec /usr/bin/rspamc learn_spam
Sembra semplice, no? Niente di più è necessario. La mail spam è girata a questo script e rspamd la apprende come spam, regolando il suo database di rilevamento spam di conseguenza.
Il secondo script apprende l’ham ed è chiamato /etc/dovecot/sieve/rspamd-learn-ham.sh. Mettiamoci dentro:
#!/bin/sh
exec /usr/bin/rspamc learn_ham
Questi due script shell devono essere eseguibili, quindi correggiamo ciò:
chmod u=rwx,go= /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh
chown vmail.vmail /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh
Spero non siate già usciti di testa. E’ solo una catena di eventi. Reiteriamo come il processo funziona:
- Un utente sposta una mail spam nella cartella “Junk”
- Dovecot realizza che questo scatena la regola Sieve “imapsieve_mailbox1” quindi chiama lo script Sieve /etc/dovecot/sieve/learn-spam.sieve (in realtà la versione *.svbin dello script)
- Sieve prende la mail e la manda (“pipe”) allo script shell eseguibile rspamd-learn-spam.sh
- lo script gira la mail al comando “/usr/bin/rspamc learn_spam”
Questo naturalmente funziona in maniera uguale per l’apprendimento di mail ham.
Sono sicuro che siete impazienti di provarlo. Si, ora è il momento. Tuttavia per vederlo veramente in azione suggerisco di editare il file /etc/dovecot/conf.d/10-logging.conf e settare “mail_debug=yes”. Questo aggiunge molto dettaglio al file /var/log/mail.log e su un server in produzione può causare mal di testa. 🙂
Riavviamo Dovecot…
service dovecot restart
…e guardiamo il file /var/log/mail.log…
tail -f /var/log/mail.log
Ora apriamo il client IMAP (Thunderbird, Evolution, Roundcube, mutt o quello che preferite) e trasciniamo una mail nella nostra cartella “Junk”. Il log mail dovrebbe riprodurre qualcosa di simile…
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’
Cercate errori e avvertimenti. Se alla fine vedete che Dovecot ha chiamato lo script “rspamd-learn-spam.sh” allora siete a posto.
E infine se tirate via una mail dalla cartella “Junk”, dovreste vedere la regola mailbox [2] venir chiamata e la mail segnata come 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’
Ecco fatto. Carino, non trovate?
Autoexpunge
Andi Olsen ha fatto notare che Dovecot ha introdotto una funzionalità per cancellare automaticamente le mail in una cartella che raggiungono una certa età. Questo è particolarmente utile per le cartelle “Trash” e “Junk”. Per abilitare questa funzionalità editiamo il file /etc/dovecot/conf.d/15-mailboxes.conf ed aggiungiamo il parametro “autoexpunge” dove desiderato. Esempio:
mailbox Junk {
special_use = Junk
auto = subscribe
autoexpunge = 30d
}
mailbox Trash {
special_use = Trash
auto = subscribe
autoexpunge = 30d
}
Riavviamo Dovecot dopo ogni modifica alla configurazione.
Logging
rspamd mantiene un log dettagliato delle sue azioni in /var/log/rspamd/rspamd.log. Potete guardare qui se un utente si lamenta che una certa mail è stata bloccata o segnata come spam. Potete confrontarlo con /var/log/mail.log usando l’ID della coda di Postfix. Questi sono numeri esadecimali di 12 cifre tipo “95CE05A00547”. Questi ID si trovano anche in rspamd.log:
2018-01-14 06:39:45 #10424(normal) ; task; rspamd_task_write_log: id: , 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: , rcpts: <…>, mime_rcpt: <…>
L’interfaccia web
rspamd arriva con una fantastica funzionalità bonus: un’interfaccia web. Permette di controllare le mail per lo spam, ottenere statistiche ed affinare i punteggi. E’ già installato ed abilitato di default e si aspetta richieste HTTP sulla porta 11334 nell’interfaccia localhost. Per l’accesso suggerisco di aggiungere una semplice configurazione proxy sulla già funzionante webmail HTTPS.
Prima di tutto abilitiamo il modulo Apache per il proxy HTTP:
a2enmod proxy_http
Possiamo creare un nuovo host virtuale oppure editare il file /etc/apache2/sites-available/webmail.example.org-https.conf. Da qualche parte dentro i tag VirtualHost aggiungiamo:
ProxyPass "/rspamd" "http://localhost:11334"
ProxyPassReverse "/rspamd" "http://localhost:11334"
Questo pezzo di configurazione inoltra ogni richiesta per https://webmail.example.org/rspamd a localhost:11334, dando perciò accesso alla interfaccia web di rspamd.
L’interfaccia è protetta da password. Generiamone una nuova:
pwgen 15 1
Questo restituisce una password tipo “eiLi1lueTh9mia4”. Potremmo metterla nel file di configurazione di rspamd. Ma password in chiaro nei file di configurazione non sono molto eleganti. Creiamo un hash della password:
rspamadm pw
Enter passphrase: …
$2$icoahes75e7g9wxapnrbmqnpuzjoq7z…
Inseriamo la password creata da pwgen e otteniamo un lungo hash della password. Questa procedura è anche documentata nelle pagine di rspamd.
Creiamo un nuovo file di configurazione /etc/rspamd/local.d/worker-controller.inc e mettiamo l’hash della password qui:
password = "$2$icoahes75e7g9wxapnrbmqnpuzjoq7z…"
E’ tutto per la configurazione. Infine riavviamo sia rspamd che Apache per caricare le nostre modifiche:
service rspamd reload
service apache2 restart
Se tutto è andato come previsto dovreste essere in grado di accedere l’interfaccia web di rspamd in https://webmail.example.org/rspamd
Qualcos’altro?
Se avete intenzione di usare rspamd in ambienti più ampi, prendetevi il tempo di leggere la buona quantità di documentazione che forniscono. rspamd scala molto bene ma richiede una configirazione addizionale come Redis per un’analisi spam più veloce tra gateway di posta multipli.