Server di posta locale con Fetchmail e Courier IMAP (rev 1.0)

Transcript

Server di posta locale con Fetchmail e Courier IMAP (rev 1.0)
Server di posta locale con Fetchmail e Courier
IMAP (rev 1.0)
Diego Pettenò <[email protected]>
19 giugno 2005
Indice
1 Introduzione
2
2 Protocolli di posta
2.1 L'invio e il transito della posta . . . . . . .
2.2 La consegna della posta . . . . . . . . . . .
2.2.1 Formati di consegna . . . . . . . . .
2.2.2 Directory di consegna . . . . . . . .
2.3 La lettura della posta . . . . . . . . . . . .
2.3.1 Post Oce Protocol . . . . . . . . .
2.3.2 Interactive Message Access Protocol
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3.1 Richieste hardware e software . . . . . . . . . .
3.2 Scelte pratiche . . . . . . . . . . . . . . . . . .
3.2.1 Software Server . . . . . . . . . . . . . .
3.2.2 Filtri per la posta . . . . . . . . . . . .
3.2.3 Connessione sicura . . . . . . . . . . . .
3.2.4 Webmail . . . . . . . . . . . . . . . . . .
3.3 Raccogliere la posta . . . . . . . . . . . . . . .
3.4 Prepariamo il server IMAP . . . . . . . . . . .
3.5 Incasellare la posta . . . . . . . . . . . . . . . .
3.5.1 Inserire le mailing list in diverse cartelle
3.5.2 Cancellare lo spam conosciuto . . . . . .
3.5.3 Filtrare il possibile spam . . . . . . . . .
3.5.4 Reinoltrare una copia delle email . . . .
3.6 Completare l'installazione di fetchmail . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 5
. 5
. 5
. 6
. 6
. 6
. 7
. 7
. 8
. 9
. 9
. 10
. 11
. 12
3 Il problema e la soluzione
.
.
.
.
.
.
.
2
2
3
3
3
4
4
4
4 Ringraziamenti
12
5 Nota Legale
12
1
1 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![1]
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
eettivamente 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à.
2 Protocolli di posta
Senza voler scendere nel dettaglio tecnico, possiamo dire che esistono principalmente tre protocolli che si occupano di posta elettronica: SMTP [2], POP3[3] e
IMAP4[4].
Mentre il primo si occupa dell'invio e del transito della posta no 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.
2.1
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à denito come un round-robin 1 di server.
In ascolto sul server del provider c'è un MTA (Mail Transfer Agent ) ovvero un
software che verica a quale server il messaggio va inoltrato (vericando 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 denito 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.
2.2
La consegna della posta
Una volta che il messaggio è stato ricevuto dall'MTA del server del destinatario,
il suo tragitto sugli MTA è (solitamente) nito. A questo punto il software si
1 Un
hostname che viene risolto di volta in volta con un diverso IP scelto tra una lista di
server paralleli che svolgono la stessa funzione.
2
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.
2.2.1 Formati di consegna
Sui sistemi Unix classici le mail venivano salvate all'interno di le in formato
mbox, ovvero un unico le di testo (per ogni utente) dove le mail erano separate
da una riga specica.
Tale formato però sore di gravi problemi: il le 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 le, nel caso in cui questo sia danneggiato da un
fault del lesystem tutti i messaggi andrebbero persi.
Per evitare ciò, D. J. Bernstein, l'autore di QMail, ha introdotto il formato
Maildir[5], in cui ogni messaggio viene salvato in un le 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.
2.2.2 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 le 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.
2.3
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 oerto 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 Oce Protocol ), la
cui prima incarnazione[6] vede la luce nell'ottobre del 1984. A questa seguirono
3
altre due versioni, no 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.
2.3.1 Post Oce Protocol
Il protocollo POP3 è attualmente il protocollo più diuso 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.
2.3.2 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
nire 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 sore di un grave problema: i messaggi restando sul
server continuano ad occupare spazio sulla mailbox, che nirebbe per riempirsi
in breve tempo.
Si tratta alla ne di un metodo simile a quello utilizzato dalle webmail che, anzi,
molto spesso utilizzano proprio IMAP4 per l'accesso ai messaggi.
3 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
ucio (o in ogni caso in una rete diversa da quella del proprio provider) è quello
4
di accedere alla posta che si trova nei server del provider.
Un altro problema è il fatto che utilizzando POP3 non è aatto semplice avere
la posta a disposizione su tutti i client per poterla leggere con calma, mentre con
IMAP4 si nisce 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
congurazione di un server di rete, ed utilizza solamente software libero.
3.1
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 courier-imap.
Opzionalmente è possibile utilizzare bogolter o spamassassin. Maildrop e
Courier-Imap fanno entrambi parte della suite Courier, che comprende però
anche un MTA, un server POP3 e una webmail, che non ci interessano al
momento.
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.
3.2
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.
3.2.1 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 ni
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 congurazione è 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. Invece courier è stato abbastanza semplice da congurare.
5
Esistono in realtà due versioni di Courier che possono essere utilizzate: la
prima è la suite, che comprende oltre al server IMAP anche un MTA, un server
POP3, MailDrop (l'MDA) e una webmail, mentre l'altra è il singolo courierimap.
Quando ho applicato per la prima volta questa soluzione, su Gentoo Linux, usai
la suite, anche perché non era ancora molto anata e inizialmente pensavo di
usare anche l'MTA. L'attuale server invece utilizza Courier-IMAP e Maildrop.
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 proprio come il server IMAP.
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.
3.2.2 Filtri per la posta
Visto l'aumentare vertiginoso dello spam che riceviamo sulle nostre caselle email,
è molto probabile che vogliate impostare un ltro 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 congurato sul mio server un ltro usando bogolter, mentre
sull'attuale server ho congurato (anche se non funziona per qualche problema
con perl) spamassassin. La congurazione è molto semplice.
Volendo è anche possibile eettuare una scansione antivirus usando clamav,
nel caso in cui si disponga di macchine che possono essere attaccate da virus
(Windows).
3.2.3 Connessione sicura
Sarò paranoico, ma da un po' di tempo sono abbastanza preoccupato che il
traco tra le mie macchine ed Internet sia sniato 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 congurato
il mio sistema di posta è stata quella di utilizzare la connessione cifrata usando
SSL. Per fortuna Courier supporta tranquillamente IMAP-over-SSL.
3.2.4 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 congurato come server HTTP sicuro
(SSL).
Ho deciso di non utilizzare sqwebmail perché non mi piacciono i CGI e preferisco
darmi di PHP quando è possibile.
6
3.3
Raccogliere la posta
Il primo problema da arontare per risolvere la questione è come raccogliere la
posta. Abbiamo visto che gli MTA si occupano di far arrivare la posta no al
server del nostro provider, e poi tocca a noi riuscire a prenderla. Solitamente
se ne occuperebbe un client (graco 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 le
/etc/fetchmailrc (con permesso di lettura solo a root), la cui sintassi generale
è questa:
poll pop3.provider.tld with proto POP3
user '[email protected]' there with password 'segreto'
is 'localuser' here options fetchall
In questo caso si dice a fetchmail che deve raccogliere la posta dal server pop3.provider.tld usando il protocollo POP3, e che la posta dell'utente
[email protected] 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
congurazione generale con questa:
poll pop3.provider.tld with proto POP3
user '[email protected]' 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 localuser.
Nel caso si abbia più di un utente locale a cui si vuole inoltrare la posta
basta semplicemente cambiare localuser nella congurazione 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.
3.4
Prepariamo il server IMAP
Il motivo per cui prima di congurare 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
7
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 Courier IMAP, che esce dal seminato di questo articolo.
Una volta installato Courier IMAP troverete in /etc/courier-imap/ i suoi
le di congurazione. Quelli che ci interessano maggiormente sono imapd e
imapd-ssl, poiché il server IMAP-over-SSL viene congurato da entrambi i
les.
In genere i defaults vanno bene per tutti, ma per chi avesse un solo utente
sul server (quindi è un server casalingo per una persona soltanto), consiglio
di diminuire il numero dei demoni attivi. Per fare questo, basta impostare la
variabile MAXDAEMONS a 10 dentro al le /etc/courier-imap/imapd.
Se volete diminuire il carico di processore della macchina localmente, potete
congurare anche il server IMAP senza SSl, in modo da utilizzarlo quando ci si
connette dalla rete interna. Per fare ciò però vi conviene impostare la variabile
ADDRESS all'indirizzo interno della macchina (o 127.0.0.1 se la macchina che
utilizzate è il server stesso).
Per nire, ricordatevi di congurare il le da cui verrà poi generato il certicato SSL, si tratta del le imapd.cnf.
Fate molta attenzione che il valore CN che trovate in quel le corrisponda all'hostname che utilizzerete per connettervi alla macchina, in caso contrario la
maggior parte dei client di posta (Thunderbird, Apple's Mail, e altri ancora) si
lamenteranno che il certicato non è valido per il server a cui ci si è collegati.
Bisogna poi congurare la directory che Courier utilizzerà per presentare
i messaggi ai client. Predenita è la directory ~/Maildir, ma visto che può
dare impaccio in un uso giornaliero della macchina, quando avevo courier
sulla macchina Linux usavo ~/.maildir. Per cambiare l'impostazione basta
modicare la variabile MAILDIRPATH dentro al le /etc/courier-imap/imapd;
il percorso è relativo alla home directory.
A questo punto bisogna creare la maildir in cui salvare i dati. Per farlo, la
cosa più banale è questa:
$ cd ~
$ mkdir Maildir Maildir/cur Maildir/new Maildir/tmp
Ricordatevi solo di lanciarlo dall'utente da cui volete leggere la posta, e di
sostituire Maildir con la directory che avete impostato sul le di congurazione
di imap.
Per nire avviate il server IMAP (come fare questo dipende dal sistema operativo che state usando) e congurate un client per connettervisi, mi raccomando
perché è necessario per il prossimo passo.
3.5
Incasellare la posta
Arriviamo dunque alla parte più intricata della congurazione: lo script per
maildrop.
Dico questo perché maildrop è sicuramente un software molto avanzato, ma allo
stesso tempo ha un le di congurazione 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 semplicare le cose al massimo.
8
Creiamo dunque un le ~/.mailfilter . Iniziamo in realtà dal fondo, o
meglio dal minimo necessario, e poi costruiamo uno script più complesso.
Come ultima riga del le, 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 specica una directory come argomento
al to, lui salverà i messaggi in formato mbox, non utilizzabile da Courier IMAP.
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 .*.
3.5.1 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
denita sul le di congurazione, 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 le di congurazione, 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'identicazione 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: [email protected]/ )
to "Maildir/.wine-devel"
to "Maildir"
Se non trovate un identicatore che sia sempre unico per la mailing list, ma
dovete per esempio vericare l'header To:, cercandoci una sottostringa, potete
usare una regular expression del tipo /To:.*[email protected].*/.
3.5.2 Cancellare lo spam conosciuto
Spesso riceviamo spam conosciuto ovvero spam di cui riusciamo ad identicare in un modo o nell'altro la provenienza, perché per esempio proviene dal
9
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 traco in arrivo
da un determinato indirizzo email, poniamo caso sia [email protected] .
Trasformiamo quindi il nostro script in questo:
if ( /From:.*[email protected].*/ )
exit
if ( /X-BeenThere: [email protected]/ )
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 eettuati prima di consegnare il messaggio.
Tenete bene in testa questa cosa, perché il prossimo passo è l'inserire un ltro
che permette di classicare i messaggi come probabile spam.
3.5.3 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
classicazione 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 ltri, bogolter
(un ltro 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 ltro 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
Bogolter Bogolter è un ltro mail che classica i messaggi come spam o
non-spam attraverso un'analisi statistica dell'intestazione e del contenuto dei
messaggi. Il programma è capace di imparare dalle classicazioni e correzioni
dell'utente.[7]
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 bogolter la classicazione. 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.
10
Per eettuare il ltering tramite bogolter, 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 bogolter, 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 congurazione, che ho lasciato ai default, e non saprei proprio come spiegarlo, quindi mi limito ad inserire la regola da utilizzare,
similmente a Bogolter in precedenza, prima del to nale:
xfilter "/usr/local/bin/spamassassin"
if (/^X-Spam-Flag: *YES/)
{
to "Maildir/.Junk Mail"
}
3.5.4 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 eettuare 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 no a
quel punto), basta inserire una riga di questo tipo:
cc "| /usr/sbin/sendmail -- [email protected]"
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.
11
3.6
Completare l'installazione di fetchmail
Ora che abbiamo congurato il server IMAP e l'MDA, possiamo nalmente
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.
4 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.
5 Nota Legale
c 2004 Diego Pettenò.
Copyright Questo testo è distribuito dall'autore sotto la CCPL secondo le norme indicate
all'indirizzo http://creativecommons.org/licenses/by-nc-sa/2.0/it/deed.it.
Riferimenti bibliograci
[1] http://freepops.sourceforge.net/
Simple Mail Transfer Protocol. Agosto 1982.
[3] J. Myers, M. Rose. RFC 1939: Post Oce Protocol - Version 3. Maggio
[2] Jonathan B. Postel. RFC 821:
1996.
[4] M. Crispin. RFC 3501:
Marzo 2003.
Internet Message Access Protocol - Version 4rev1.
Using maildir format. http://cr.yp.to/proto/maildir.html
[6] J. K. Reynolds. RFC 918: Post Oce Protocol. Ottobre 1984.
[5] D. J. Bernstein.
[7] Introduzione
sulla
homepage
http://bogolter.sourceforge.net/
12
di
Bogolter: