Server di posta locale con Fetchmail e Dovecot

Introduzione

Sempre più spesso i provider cominciano a permettere l’accesso alle
proprie caselle di posta elettronica tramite i server POP3 ed IMAP solo
quando si è connessi tramite loro, permettendo l’accesso dall’esterno
solo tramite la spesso scomoda WebMail.

Per poter aggirare queste restrizioni, sono stati ideati progetti
quali FreePOPs che si
occupa del parsing delle pagine della webmail simulando un server POP3
locale. Per quanto questa soluzione in genere funzioni, non è
sicuramente la più performante, e in alcuni casi può essere abbastanza
inutile. Per esempio quando effettivamente si utilizza una connessione
casalinga col provider in oggetto, ma si ha a disposizione un
portatile con cui ci si collega anche dall’esterno.

Questo articolo vuole proporre una soluzione a questo problema,
utilizzando software libero, senza andare ad “abusare” dei
servizi forniti dai provider. Il risultato sarà un accesso illimitato
alla propria posta da ovunque si vorrà.

Storia

Questo articolo deriva dal mio originale “Server di posta locale con
Fetchmail e Courier IMAP”, ma utilizza, anziché Courier IMAP, il server
di posta Dovecot.

La ragione di questa modifica è che io stesso sono passato dall’usare
Courier ad usare Dovecot, principalmente perché mi ero stufato dei
problemi che Courier continuava a darmi con Apple’s Mail e dei
rallentamenti al caricamento di una cartella con KMail.

Il cambiamento ha anche avuto l’effetto secondario di permettermi di
avere una migliore organizzazione delle cartelle di posta, che ora non
sono più tutte sottocartelle della Inbox, cosa che ha reso più semplice
usare Mail e KMail.

La differenza tra “Fetchmail e Courier IMAP” e “Fetchmail e Dovecot” non
sta solo nella sezione di configurazione del server IMAP. Ho anche
modificato le ragioni per la scelta del server IMAP, e migliorata la
descrizione per il setup della maildir.

Protocolli di posta

Senza voler scendere nel dettaglio tecnico, possiamo dire che esistono
principalmente tre protocolli che si occupano di posta elettronica:
SMTP, POP3 e IMAP4.

Mentre il primo si occupa dell’invio e del transito della posta fino al
server del provider di destinazione, gli ultimi due sono stati creati
per permettere la lettura della posta elettronica con dei client di
posta, e come si può notare dalla data di pubblicazione, sono molto più
recenti del primo. Vedremo più avanti il motivo di questo distacco.

L’invio e il transito della posta

Quando si invia un messaggio di posta elettronica tramite un client,
solitamente questo si connette al server “Posta in uscita”
del proprio provider, ovvero al server SMTP. Tale server è solitamente
chiamato mail.provider.tld, e sempre più spesso tale nome viene in
realtà definito come un round-robin¹ di server.

In ascolto sul server del provider c’è un MTA (Mail Transfer Agent)
ovvero un software che verifica a quale server il messaggio va inoltrato
(verificando il dominio nell’indirizzo del destinatario). Se il server
di destinazione è il server stesso (quindi si è inviata una mail ad un
utente dello stesso provider), il messaggio passa alla seconda fase,
quella di consegna (illustrata nel prossimo paragrafo).

Se invece il messaggio deve essere consegnato ad un altro server, l’MTA
contatta il server definito nel record DNS del dominio di destinazione
(il cosiddetto mail exchanger) e inoltrerà il messaggio all’MTA del
nuovo server, che svolgerà la stessa operazione appena vista.

La consegna della posta

Una volta che il messaggio è stato ricevuto dall’MTA del server del
destinatario, il suo tragitto sugli MTA è (solitamente) finito. A questo
punto il software si occupa di passare il messaggio ad un nuovo
programma, chiamato MDA (Mail Delivery Agent).

Alcuni MTA implementano anche l’MDA nello stesso programma, ma, come
ogni utente di sistemi Unix-Like sa, un software specializzato spesso
può fornire molte più opzioni, quindi praticamente ogni MTA moderno
permette di sostituire il proprio MDA con un altro software. Nel caso di
Courier-MTA, l’MDA fornito è MailDrop, disponibile anche come software a
se stante, ma molto spesso questo viene accoppiato con procmail.

Formati di consegna

Sui sistemi Unix classici le mail venivano salvate all’interno di file
in formato mbox, ovvero un unico file di testo (per ogni utente) dove le
mail erano separate da una riga specifica.

Tale formato però soffre di gravi problemi: il file deve essere posto
sotto lock per mantenerne l’integrità (evitando che una
lettura/scrittura concorrente faccia perdere dei messaggi), aumenta
considerevolmente di dimensioni quando arrivano molti messaggi, non
permette un’organizzazione gerarchica (in cartelle) della posta, e
utilizzando un solo file, nel caso in cui questo sia danneggiato da un
fault del filesystem tutti i messaggi andrebbero persi.

Per evitare ciò, D. J. Bernstein, l’autore di QMail, ha introdotto il
formato Maildir, in cui ogni messaggio viene salvato in
un file separato all’interno di una struttura di directories che
permette anche l’archiviazione gerarchica. Tale formato viene ora
utilizzato da molti altri software, sia server che client, come Courier,
Procmail, KMail ed Evolution.

Directory di consegna

Anche il posto dove le mail vengono consegnate non è sempre lo stesso.
In genere sono due le directory dove la posta viene salvata per la
consegna: nei sistemi in cui viene gestita la posta solo per gli utenti
del sistema, questa viene solitamente consegnata all’interno delle home
directories degli utenti stessi, in un file mbox oppure nella
directory Maildir.

Mentre nei server dei provider, dove vengono gestite utenze email che
non corrispondono alle utenze del sistema (oppure vengono gestiti più
domini sullo stesso server, tramite virtual domains), vengono
solitamente salvati in una struttura di directory su /var/spool/mail.

La lettura della posta

Nei primi anni della grande rete, quando la posta elettronica veniva
solitamente usata dagli utenti locali dei computer, per leggere la posta
bastava utilizzare un client che andasse a leggere il proprio mbox,
sulla macchina locale (o eventualmente dallo share NFS del server di
posta nel caso di terminali, per esempio nelle universtità).

Col passare degli anni però la posta elettronica è diventata un servizio
offerto al pubblico da grandi provider, che ovviamente non potevano
fornire utenze all’interno dei propri server per poter leggere la posta
direttamente. Per risolvere questo problema, venne ideato il protocollo
POP (Post Office Protocol), la cui prima incarnazione (RFC 918) vede la
luce nell’ottobre del 1984. A questa seguirono altre due versioni, fino
a giungere all’attuale versione 3.

Parallelamente al protocollo POP, nacque un protocollo appositamente
pensato per i client moderni, l’IMAP (originariamete Internet Mail
Access Protocol, attualmente Interactive Message Access Protocol),
che fornisce diverse funzionalità non presenti nel protocollo POP.

Post Office Protocol

Il protocollo POP3 è attualmente il protocollo più diffuso per l’accesso
alla posta elettronica. Tramite questo protocollo, il client si connette
al server e scarica tutti o una parte dei messaggi disponibili per la
consultazione fuori linea. Può inoltre cancellare un messaggio o
semplicemente dire al server che tale messaggio è già letto (per evitare
di riscaricarlo).

Quando si utilizza questo protocollo e si possiede più di un computer,
il metodo più semplice per poter leggere le email da entrambi è
impostare uno dei client per cancellare tutti i messaggi, e gli altri
per non farlo. A questo punto la posta deve però essere scaricata da
tutti i client in un ben preciso ordine se si vuole che la posta sia
disponibile su tutti i client. Allo stesso tempo, se un messaggio
arrivasse mentre è in corso la sequenza di download della posta, non
sarebbe disponibile su alcune macchine.

Interactive Message Access Protocol

Per poter risolvere i problemi del protocollo POP, è stato ideato il
protocollo IMAP, che cambia sostanzialmente l’approccio che i client di
posta hanno rispetto al server.

In un server IMAP, il server fa più che fornire la possibilità di
scaricare i messaggi ai client, ma si occupa di tenere archiviati i
messaggi, organizzandoli gerarchicamente (in cartelle), similmente a
come i client moderni gestiscono la posta salvata localmente.

Tra i servizi aggiuntivi che i server IMAP possono fornire, c’è la
possibilità di ordinare i messaggi per thread (discussione) server-side,
l’ordinamento per un determinato parametro sempre server-side, la
ricerca server-side, e la richiesta di una singola parte di un messaggio
(per esempio si possono scaricare tutti gli header di una cartella, poi
decidere di quali si vuole scaricare il corpo del messaggio, e intanto
eliminare i messaggi che già si vedono non desiderati, per finire si
possono scaricare solo gli allegati che ci interessano).

Questo protocollo, tenendo archiviati i messaggi lato server, è
sicuramente la scelta più comoda per poter accedere alla posta da più di
un computer, o da più di un client, ma soffre di un grave problema: i
messaggi restando sul server continuano ad occupare spazio sulla
mailbox, che finirebbe per riempirsi in breve tempo.

Si tratta alla fine di un metodo simile a quello utilizzato dalle
webmail che, anzi, molto spesso utilizzano proprio IMAP4 per l’accesso
ai messaggi.

Il problema e la soluzione

Come abbiamo visto, uno dei problemi maggiori che si possono avere
quando si possiede più di un computer, ed uno è un portatile o è per
esempio nel proprio ufficio (o in ogni caso in una rete diversa da
quella del proprio provider) è quello di accedere alla posta che si
trova nei server del provider.

Un altro problema è il fatto che utilizzando POP3 non è affatto semplice
avere la posta a disposizione su tutti i client per poterla leggere con
calma, mentre con IMAP4 si finisce col consumare la propria quota nella
mailbox. Inoltre poiché raramente i provider forniscono supporto per
connessioni sicure al server IMAP, utilizzare questo può in qualche modo
creare un problema di privacy.

Per risolvere questo, ho ideato una soluzione elaborata nell’insieme, ma
semplice da creare, che permette di avere sempre a disposizione la
propria posta senza problemi di reti, privacy o complicazioni varie.
Tale soluzione richiede veramente poche risorse, e le normali capacità
tecniche necessarie per la configurazione di un server di rete, ed
utilizza solamente software libero.

Richieste hardware e software

Per poter applicare con successo questa soluzione c’è sicuramente una
necessità hardware da soddisfare: una macchina collegata ad Internet 24
ore su 24 (o quasi, in ogni caso collegata nel momento in cui si vuole
controllare la propria posta dall’esterno).

Le richieste software sono abbastanza vaghe in realtà: il computer che
farà da server deve disporre di un sistema operativo Unix-like, come può
essere Linux, ma anche OpenBSD, FreeBSD, Solaris e chi più ne ha più ne
metta possono funzionare (io ho avuto esperienza diretta usando Gentoo
Linux e OpenBSD).

È poi necessario avere i seguenti pacchetti: fetchmail, maildrop e
dovecot. Opzionalmente è possibile utilizzare bogofilter o spamassassin.

Inoltre per poter accedere alla vostra macchina dall’esterno senza
conoscerne di volta in volta l’IP, vi consiglio di dotarvi di un
hostname dinamico come quelli forniti da dyndns.org, e di un client che
si occupi dall’aggiornamento automatico dello stesso.

Scelte pratiche

Entriamo dunque nel pieno dell’implementazione e partiamo con
un’illustrazione delle scelte che ho fatto quando sono partito con
questa mia idea.

Software Server

La scelta del software a lato server è stata sicuramente quella che mi
ha fatto impiegare più tempo. A parte la scelta del sistema operativo,
che va oltre ai fini di questo articolo, ho impiegato un po’ di tempo
nella scelta del server IMAP da utilizzare.

Scartai inizialmente QMail non tanto per la sua licenza particolare, ma
per il fatto che la sua configurazione è abbastanza complessa,
probabilmente ciò è dovuto al fatto che è stato pensato per server su
vasta scala che non sono quelli di cui abbiamo bisogno noi in questo
momento.

Scartai anche cyrus-imapd semplicemente perché non riuscivo a capire
come funzionasse. Courier, la mia prima scelta effettiva, è stata poi
scartata per problemi di compatibilità con Apple’s Mail e altre cose.
Dovecot, invece, è più compatibile, semplice e funzionale.

Come MDA ho appunto scelto lo stesso fornito con la suite Courier,
Maildrop, che è abbastanza potente e non ha grossi problemi conosciuti.
Inoltre è disponibile come pacchetto separato, per l’uso con server
diversi da Courier.

Ora, come ho già detto, non necessitiamo di un MTA, perché per
recuperare la posta (come vedremo) utilizzeremo fetchmail, che parlerà
direttamente con l’MDA senza altri intermediari.

Filtri per la posta

Visto l’aumentare vertiginoso dello spam che riceviamo sulle nostre
caselle email, è molto probabile che vogliate impostare un filtro sulla
posta in ingresso. Per farlo, possiamo dire all’MDA di passare le email
attraverso un programma esterno che ne determini o meno la natura di
spam.

Inizialmente avevo configurato sul mio server un filtro usando
bogofilter, mentre sull’attuale server ho configurato (anche se non
funziona per qualche problema con perl) spamassassin. La configurazione
è molto semplice.

Volendo è anche possibile effettuare una scansione antivirus usando
clamav, nel caso in cui si disponga di macchine che possono essere
attaccate da virus (Windows).

Connessione sicura

Sarò paranoico, ma da un po’ di tempo sono abbastanza preoccupato che il
traffico tra le mie macchine ed Internet sia sniffato da intermediari.
Forse è dovuto al fatto che perlopiù mi collego tramite la rete della
mia (ex-)scuola.

Per questo, una delle cose a cui ho fatto attenzione quando ho
configurato il mio sistema di posta è stata quella di utilizzare la
connessione cifrata usando SSL. Per fortuna Dovecot supporta
tranquillamente IMAP-over-SSL.

Webmail

Poiché non sempre ho a disposizione una connessione di rete per il
portatile quando posso navigare ad Internet (molto spesso navigo per
esempio dall’università), ho voluto installarmi anche una webmail che si
colleghi al nuovo server per poter leggere le mie email con comodità.

Anche per questa funzione ho scelto un software libero, SquirrelMail,
un’applicazione PHP, avviata su un Apache configurato come server HTTP
sicuro (SSL).

Ho deciso di non utilizzare sqwebmail perché non mi piacciono i CGI e
preferisco fidarmi di PHP quando è possibile. Inoltre, SquirrelMail
supporta qualsiasi server IMAP, anziché solo courier.

Raccogliere la posta

Il primo problema da affrontare per risolvere la questione è come
raccogliere la posta. Abbiamo visto che gli MTA si occupano di far
arrivare la posta fino al server del nostro provider, e poi tocca a noi
riuscire a prenderla. Solitamente se ne occuperebbe un client (grafico o
testuale), ma a noi occorre che ad occuparsene sia un qualcosa che ci
permetta di farla avere poi al nostro server IMAP.

Per risolvere questo esiste un bellissimo programma chiamato fetchmail,
che si occupa di scaricare la posta da server POP3 o IMAP4 e di
reimmetterla poi localmente tramite un MTA oppure un MDA. Procediamo
quindi a creare un file /etc/fetchmailrc (con permesso di lettura solo
a root), la cui sintassi generale è questa:

poll pop3.provider.tld with proto POP3
    user 'utente@provider.tld' there with password 'segreto'
    is 'localuser' here options fetchall

In questo caso si dice a fetchmail che deve raccogliere la posta dal
server usando il protocollo POP3, e che la posta dell’utente sul server,
accessibile con la password segreto, deve essere inviata all’utente
locale localuser, scaricando anche la posta segnata come già letta.

Questo però farebbe sì che fetchmail prenda e tenti di collegarsi ad un
MTA locale, usando SMTP, e tenti di inviare i messaggi per l’utente
localuser. Non è quello che vogliamo però, perché in tal caso dovremmo
impostare anche un MTA ed è un problema da non sottovalutare.

In soccorso ci arriva l’opzione mda di fetchmail, cambiamo quindi la
riga di configurazione generale con questa:

poll pop3.provider.tld with proto POP3
    user 'utente@provider.tld' there with password 'segreto'
    is 'localuser' here options fetchall
    mda "/usr/bin/maildrop -d localuser"

in questo caso fetchmail invece di contattare l’MTA locale, manderà la
mail direttamente all’MDA (maildrop) dicendogli di consegnarla
all’utente .

Nel caso si abbia più di un utente locale a cui si vuole inoltrare la
posta basta semplicemente cambiare localuser nella configurazione di
fetchmail con i nomi dei vari utenti.

A questo punto è necessario impostare un cronjob che avvii ripetutamente
fetchmail, ma prima di fare ciò è bene completare l’impostazione del
server IMAP e dell’MDA.

Prepariamo il server IMAP

Il motivo per cui prima di configurare l’MDA consiglio di preparare il
server IMAP è semplicemente una comodità per creare le sottocartelle in
cui incasellare la posta.

Iniziamo dunque i preparativi. Per prima cosa bisogna installare il
server, per farlo io ho utilizzato portage in Gentoo e pkg_add in
OpenBSD, quindi spero che la distribuzione Linux (o il sistema operativo
che state utilizzando) abbia i precompilati da installare, altrimenti vi
lascio a seguire la documentazione per la compilazione di Dovecot, che
esce dal seminato di questo articolo.

Una volta installato Dovecot, dovrete configurarlo, attraverso
/etc/dovecot.conf.

La documentazione del file di configurazione è abbastanza esplicita, e
quindi c’è poco da dire perlopiù. Le cose importanti saranno qui
elencate per sicurezza.

protocols = imaps: questa impostazione è necessaria per utilizzare
IMAP-over-SSL.

default_mail_env = maildir:%h/Maildir: questa impostazione dice a
Dovecot di cercare una directory di nome Maildir all’interno della home
dell’utente ($%$h indica proprio la home directory).

Se volete diminuire il carico di processore della macchina localmente,
potete configurare anche il server IMAP senza SSl, in modo da
utilizzarlo quando ci si connette dalla rete interna. Per fare ciò basta
aggiungere imap alla lista di protocolli alla voce protocols.

A questo punto bisogna creare la maildir in cui salvare i dati. Per
farlo, maildrop mette a disposizione il comando maildirmake che crea
la struttura completa della Maildir:

$ cd ~
$ maildirmake Maildir

Ricordatevi solo di lanciarlo dall’utente da cui volete leggere la
posta, e di sostituire Maildir con la directory che avete impostato sul
file di configurazione di imap.

Per finire avviate il server IMAP (come fare questo dipende dal sistema
operativo che state usando) e configurate un client per connettervisi,
mi raccomando perché è necessario per il prossimo passo.

Incasellare la posta

Arriviamo dunque alla parte più intricata della configurazione: lo
script per maildrop.

Dico questo perché maildrop è sicuramente un software molto avanzato, ma
allo stesso tempo ha un file di configurazione molto intricato, e mal
documentato. Per poterne trarre qualcosa di semplice, ho dovuto fare
abbastanza ricerche su Google, e quindi in questa sezione tento di
semplificare le cose al massimo.

Creiamo dunque un file  /.mailfilter . Iniziamo in realtà dal fondo, o
meglio dal minimo necessario, e poi costruiamo uno script più
complesso.

Come ultima riga del file, poniamo questo:

to "Maildir"

che indica a maildrop di mettere dentro la directory Maildir tutti i
messaggi che non sono stati trattati da regole precedenti.

Nota: Maildrop può utilizzare sia Maildir che mbox, quindi fate
attenzione perché se gli passate un nome che non specifica una directory
come argomento al to, lui salverà i messaggi in formato mbox, non
utilizzabile da Dovecot.

Per facilitare la comprensione delle regole indicate più avanti, quando
si inserisce una stringa tra due slash (/) nello script di maildrop,
ci si riferisce ad una regular expression, quindi per indicare
“qualsiasi cosa” basta inserire .*.

Inserire le mailing list in diverse cartelle

Sicuramente però ci sarà della posta che volete inserire automaticamente
dentro una cartella diversa dalla inbox, per esempio se siete iscritti a
qualche mailing list. Creiamo dunque una cartella chiamata ’wine-devel’
col client di posta, e vediamo che viene creata una nuova maildir sul
server, dentro la directory definita sul file di configurazione,
chiamata .wine-devel, che è quella in cui vogliamo inserire i
messaggi.

Per conoscere il nome che viene assegnato alla directory che contiene i
messaggi della cartella IMAP basta ricordarsi che tutte sono
sotto-directory della maildir impostata nel file di configurazione, e il
loro nome inizia sempre per ., e che il separatore per le sotto
directory è sempre . (per esempio se la cartella IMAP fosse stata
chiamata devel e fosse stata a sua volta dentro ad una cartella
chiamata Wine il nome della maildir sarebbe stato .Wine.devel).

Fate attenzione perché nello script di maildrop dovremo utilizzare il
nome delle maildir, non delle cartelle IMAP.

A questo punto, resta solo da inserire prima dell’ultima riga una regola
che dica a maildrop di spostare le email che arrivano dalla lista
wine-devel dentro quella cartella. Per farlo però bisogna avere
un’identificazione unica di tali messaggi. Per fortuna le mailing list
gestite con MailMan inseriscono un header X-BeenThere che indica
l’indirizzo della mailing list. Il nostro script per maildrop si
presenta ora così:

if ( /X-BeenThere: wine-devel@winehq.org/ )
    to "Maildir/.wine-devel"

to "Maildir"

Se non trovate un identificatore che sia sempre unico per la mailing
list, ma dovete per esempio verificare l’header To:, cercandoci una
sottostringa, potete usare una regular expression del tipo
/To:.*mailinglist@dominio.tld.*/.

Cancellare lo spam conosciuto

Spesso riceviamo spam “conosciuto” ovvero spam di cui
riusciamo ad identificare in un modo o nell’altro la provenienza, perché
per esempio proviene dal nostro stesso provider. Per liberarsi da tale
spam, basta aggiungere qualche semplice regola al nostro script di
maildrop.

Prendiamo per esempio caso di voler cancellare tutto il traffico in
arrivo da un determinato indirizzo email, poniamo caso sia .
Trasformiamo quindi il nostro script in questo:

if ( /From:.*newsletter@provider.tld.*/ )
    exit

if ( /X-BeenThere: wine-devel@winehq.org/ )
    to "Maildir/.wine-devel"

to "Maildir"

A questo punto tutti i messaggi ricevuti da quell’indirizzo saranno
semplicemente ignorati (exit dice a maildrop di non processare il
messaggio, e non arrivando a nessun to, semplicemente viene
cancellato).

Come vedete le regole le sto inserendo una sopra l’altra, facendo in
modo che quelle che “sfoltiscono” i messaggi siamo poste
prima delle altre, accorciando la quantità di test che devono essere
effettuati prima di consegnare il messaggio.

Tenete bene in testa questa cosa, perché il prossimo passo è l’inserire
un filtro che permette di classificare i messaggi come “probabile
spam”.

Filtrare il possibile spam

Visto che non è mai possibile azzerare lo spam con delle semplici regole
statiche, molti client di posta hanno aggiunto recentente delle
funzionalità per la classificazione della posta come spam. Ne è un
esempio Mozilla Thunderbird.

Possiamo a questo punto inserire anche noi un controllo per il possibile
spam sul nostro server locale. Per farlo io ho provato almeno due
filtri, bogofilter (un filtro bayesiano simile a quello usato da
Thunderbird) e spamassassin (più complesso e più conosciuto), anche se
in realtà ho avuto solo la prova del primo, a causa del fatto che perl
non funziona sulla macchina su cui ho il server ora.

Qualsiasi sia il filtro che vogliate utilizzare, è sconsigliabile
cancellare le email completamente, perché non sono rari i falsi positivi
(ovvero mail che vengono catalogate come spam anche se non lo sono), ed
è quindi meglio spostare le email in una cartella diversa, da
controllare e svuotare di tanto in tanto.

Creiamo quindi una cartella Junk Mail dentro la Inbox, la sua maildir
sarà Maildir/.Junk Mail

Bogofilter

Bogofilter è un filtro mail che
classifica i messaggi come spam o non-spam attraverso un’analisi
statistica dell’intestazione e del contenuto dei messaggi. Il
programma è capace di imparare dalle classificazioni e correzioni
dell’utente.

Si tratta in pratica di un programma che “impara” a capire
quando un messaggio è spazzatura o meno tramite l’intervento
dell’utente. Ho trovato comodo utilizzarlo quando il server di posta era
il mio desktop, e usavo KMail per far sapere a bogofilter la
classificazione. Non è molto comodo quando il server e il client di
posta primario non sono la stessa macchina perché richiede l’esecuzione
di un comando sul server.

Per effettuare il filtering tramite bogofilter, subito dopo le regole
per le mailing list, e prima dell’ultima to, inseriamo questa regola:

xfilter "bogofilter -u -e -p"
if ( /^X-Bogosity: Yes, tests=bogofilter/)
       to "Maildir/.Junk Mail"

La prima riga si occupa di lanciare il comando bogofilter, chiedendogli
di leggere dallo standard input il messaggio e riscriverlo sullo
standard input inserendo degli header che ritornino una probabilità
(compresa tra 0 e 1) del fatto che la mail sia spam. Inoltre se tale
percentuale supera 0.5, valuta la mail come sicuro spam, inserendo
X-Bogosity: Yes tra gli header.

La seconda riga invece cerca tale header, e se lo trova, inserisce la
mail dentro la cartella che abbiamo predisposto per il probabile spam.

SpamAssassin

SpamAssassin è uno dei più conosciuti antispam. Non sono molto pratico
della sua configurazione, che ho lasciato ai default, e non saprei
proprio come spiegarlo, quindi mi limito ad inserire la regola da
utilizzare, similmente a Bogofilter in precedenza, prima del to
finale:

xfilter "/usr/local/bin/spamassassin"
if (/^X-Spam-Flag: *YES/)
{
        to "Maildir/.Junk Mail"
}

Reinoltrare una copia delle email

In certi casi si vuole fa avere una copia di tutte o di una parte delle
email ad un altro indirizzo. Per esempio c’è chi utilizza servizi di
webmail con una alta quota per effettuare una copia di backup della
propria posta.

In altri si vuole semplicemente che delle email con determinati soggetti
o comunque che sottostanno a determinati check (come quelli visti prima
per le mailing list o lo spam), siano inviati ad un altro indirizzo
email (per esempio quello di un collega, oppure di una mailing list di
sviluppo nel caso riguardino dei programmi di cui si è sviluppatori).

Per inviare una copia di tutte le email (che hanno passato le regole
fino a quel punto), basta inserire una riga di questo tipo:

cc "| /usr/sbin/sendmail -- altroindirizzo@altrodominio.tld"

Questa riga non fa altro che inviare tutte le email che riescono a
giungere ad essa nello script all’indirizzo indicato utilizzando
sendmail (si suppone che il comando sendmail nel sistema funzioni
correttamente).

Solitamente inserisco questa regola dopo le regole statiche per lo spam
conosciuto e prima di quelle delle mailing list, per poter ricevere
tutta la posta che potrebbe non essere spam.

Completare l’installazione di fetchmail

Ora che abbiamo configurato il server IMAP e l’MDA, possiamo finalmente
inserire un cron job che si occupi di lanciare ripetutamente fetchmail
per andare a scaricare la posta e immetterla localmente. Per fare
questo, inseriamo questa linea in /etc/crontab :

*/5  *  * * *  root  /usr/local/bin/fetchmail -d0 -f /etc/fetchmailrc 
    -s --syslog > /dev/null 2>&1

e il gioco è fatto.

Ringraziamenti

Il più grande ringraziamento per questo documento va sicuramente a Fabio
“FVZ” per i chiarimenti riguardo al funzionamento e alla
terminologia dei servizi di posta elettronica.

Desidero inoltre ringraziare Bernardo “inquis” per avermi
spinto a scrivere questo articolo.

Per la nuova edizione, voglio inoltre ringraziare Roy
“Uberlord” per il suo consiglio riguardo Dovecot.