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: