Mail, SSL and Postfix

In my previous post, I delineated a few reasons why I care about SSL for my blog and the xine bugzilla. What I did not talk about was about the email infrastructure for both. The reason is that, according to the very same threat model that I delineated in that post, it’s not as important for me to secure that part of the service.

That does not mean, though, that I never considered it, just I considered it not important enough yet. But after that post I realized it’s time to fix that hole and I’ve now started working on securing the email coming out of my servers as well as that coming through the xine server. But before going into details about that, let’s see why I was not as eager to secure the mail servers compared to the low-hanging fruit of my blog.

As I said in the previous post, what you have to identify two details: what information is important to defend, and who the attackers would be. In the case of the blog, as I said, the information was the email addresses of the commenters, and the attackers the other users of open, unencrypted wifi networks in use. In the case of email, the attackers in particular change drastically; the only people in a position to get access to the connections’ streams are the people in the hosting and datacenter companies, and if they made mistakes, your neighbours in the same datacenter. So for sure it’s not the very easy prey of the couple sitting at the Starbucks next to you.

The content, well, is a bit more interesting information. We all know that there is no real way to make email completely opaque to service providers unless we use end to end encryption such as GnuPG, so if you really don’t want your server admin to ever be able to tell what’s in your email, that’s what you should do. But even then, there is something that (minus protocol-level encryption) is transmitted in cleartext: the headers, the so-called metadata, that stirred the press so much last year. So once again it’s the address of the people you contact that could be easily leaked, even with everything else being encrypted. In the case of xine, the mail server handles mostly bugzilla messaging, and it is well possible that it sends over, without encryption, the comments on security bugs, so reducing the risk of that information leaking is still a good idea.

Caveat emptor in all of this post, though! In the case of the xine mail server, the server handles both inbound and outbound messages, but at the same time it does not ever let users access their mailbox; the server itself is a mail router, rather than a full mail service. This is important, becuase otherwise I wouldn’t be able to justify my sloppiness on covering SSL support for the mail! If your server hosts mailboxes or allows direct mail submission (relay), you most definitely need to support SSL as then it’s a client-server connection which is attackable by the Starbucks example above.

So what needs to be done to implement this? Well, first you need to remember that a mail router like the one I described above requires SSL in two directions: when it receive a message it should be able to offer SSL to the connecting client, and when it sends a message it has to request SSL to the remote server too. In a perfect set up, the client also offers a certificate to prove who it is. This means that you need a certificate that works both as a server and as a client certificate; thankfully, StartSSL supports that for Class 2 certificates, even if they are named for web servers, they work just fine for mail servers too.

Unfortunately, the same caveat that apply to HTTP certificates, apply to mail servers: ciphers and protocol versions combinations. Unfortunately, while Qualys has SSL Labs to qualify the SSL support in your website, I know of no similar service for mail routers, and coming up with one is not trivial, as you would want to make sure not to become a relay-spammer by mistake, and the only way to judge the message pushing of the server is to trick it into sending a message to your own service back, which should not be possible on a properly non-open relay of a server.

So the good news is that of all of the xine developers with an alias on the domain have a secure server when routing mail to them, so the work I’ve been done is not for nothing. The other note is that a good chunk of the other users in Bugzilla uses GMail or similar big hosting providers. And unlike others I actually find this a good thing, as it’s much more likely that the lonely admin of a personal mail server (like me for xine) would screw up encrypion, compared to my colleagues over at GMail. But I digress.

The bad news is that not only there is no way to assess the quality of the configuration of a mail server, but at least for the case of Postfix you have only a ternary setting about TLS: yes always, yes if client requests it (or if the server provides the option, when submitting mail), or not at all. There is no way to set up policy so that e.g. gmail servers don’t get spoofed and tricked into sending the messages over a clear text connection. A second bad news is that I have not been able to get Postfix to validate the certificates either as server or client, likely caused by the use of opportunistic TLS rather than forcing TLS support. And the last problem is that servers connecting to submit mail will not fallback to cleartext if the TLS can’t be negotiated (either because of cipher or protocols), and will instead keep trying to negotiate TLS the same way.

Anyway, my current configuration for this is:

smtpd_tls_cert_file = /etc/ssl/postfix/server.crt
smtpd_tls_key_file = /etc/ssl/postfix/server.key
smtpd_tls_received_header = yes
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_ask_ccert = yes
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_cert_file = /etc/ssl/postfix/server.crt
smtp_tls_key_file = /etc/ssl/postfix/server.key
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2, !SSLv3

If you have any suggestions on how to make this more reliable and secure, please do!

An easy way for Italian companies to look silly to Free Software developers (and not only)

Lately I’ve noticed that a few Italian companies (none of which I work for luckily) still reply to email messages with the “R:” prefix.

if you never seen the Italian version of Outlook and Outlook Expres you most likely don’t know this problem. For some reasons I never understood, instead of prefixing the replies with the de-facto standard “Re:” prefix (or case variants thereof), they prefix them with “R:”. In recent Microsoft Outlook versions, as well as in the newer Outlook Express releases, if I remember correctly, there is a checkbox in the configuration file that switches to “international prefixes”, thus replacing “R:” with “RE:” (and “I:” with “FW:” for forwarding).

I expected Wikipedia to have at least an article on this issue, but it isn’t even listed in the major glitches of Outlook Express. Strange.

So what’s the problem with this “alternative” prefix? Well the most obnoxious one is with UseNet. Back when I actually followed the Italian newsgroups, it was obnoxious to see people replying with R: because it caused almost all news clients to split the threads as they thought the subject changed. Agent had a nice feature to specify which reply prefixes to identify, other readers provided a way to turn off threading by subject.

Nowadays a lot of clients support either threading or identify mail threads as “conversations” (no it’s not just a feature of GMail, Apple’s Mail client had that for a while too). These tricks suffer from the same problem. Either they group together mail just by reference (and thus won’t break up the thread when the subject change, making different conversations look like a huge one if the other side is hitting “reply” even when writing of stuff that has nothing to do with any previous message), or the end up splitting a single thread in two-message conversations. Or they support adding multiple reply prefixes. It becomes even more obnoxious when the subject start having as a prefix “RE: R: R: R: R: R: R: R:”, as one client doesn’t know about the “R:” prefix and the other will not “eat up” multiple prefixes.

I do have a “thread” in GMail, that happened with a former colleague of mine, that ends up having nine reply prefixes. And of course GMail won’t group those messages together, making it hard to actually understand what’s going on in the thread.

Now, as long as you’re a single person, you might not care about “R:” prefixes. If you are a small company that works only in Italy, or a medium one who is not working in the IT sector, I can understand, I still think you should be considerate when you use the network, and that your IT managers should just tick that checkbox on, but I can understand.

When you are a medium to average company, whose main sector is IT, whose employers are supposed to know enough technical details to be able to deal with issues that might come up, or might write technical documentation, leaving the “R:” prefix makes you look silly, at least to my eyes (and I’m sure I’m not alone). To me it’s like screaming “We’re subject to Microsoft will, and we don’t give a crap about any other vendor”. When this happens during hiring it’s like a huge banner for me “this is not a company you want to work for”.

As far as I know the “R:” prefix is an Italian prerogative, I don’t think any other Outlook Express version changed that. I suppose it came from the same people who decided that Windows’s Minesweeper was too violent, and had to be replaced with “Prato fiorito” (literally Flowered Garden; it was the exact same code of Minesweeper, just resources changed so that the icon was a flower and instead of mines you had to avoid flowers… I suppose it could work if one has an allergy…).

Sigh, like there wasn’t enough bad stuff already in Italy, even Microsoft wanted to make people laugh at us…

GMail and Viruses

I’m an almost happy user of GMail for quite a while, almost because it still doesn’t work properly with my browser of choice. On the other hand I can use it through IMAP so I’m happier than with my own ISP’s mailserver which is reachable only from inside their network.

One thing I can’t really get, though, is how comes that I receive tons of viruses on GMail. Don’t get me wrong, I do like the spam filter that they provide and it’s really nice, even though I do receive huge amount of spam every day (when I used to use GMail through POP and a local IMAP server, I received a good 100 e-mail messages a day that were unfiltered by GMail and detected by SpamAssassin).

From time to time a new rush of spam arrives, and GMail is not prepared to filter it, but probably because of the huge pool of users marking the stuff as spam, it is usually taken care of quickly. But viruses don’t seem to get filtered that easily.

Since last week I received a number of viruses – or at least I assume they are viruses – with “Hi” or “Re: Hi” or similar subjects, a few random lines and then an attachment. They still arrive even today.

The funny thing is that when this kind of problems arise on a mailbox I fetch with GMail from a POP server, they are able to filter it out, although they then send me a mail telling me the message was left there for that reason, which is just as annoying.

I’d like to know what is up with GMail and viruses, maybe it’s just a method to remember that you should be using a decent operating system and/or pay money for an antivirus (up to you decide what is better ;)).

Claws and IMAP

So what is the cool thing of the week for those who weren’t waiting Mac OS X Leopard already? Of course is Google providing IMAP support for GMail.

Indeed it was a feature I also was waiting for a long time: I’m running my own IMAP server for years now, but that’s a bit of a hassle as I need to keep Enterprise online to get it to work and so on. Well, now I can move everything on GMail and just use that, right? Well, somewhat.

While GMail’s IMAP server works perfectly fine from the Nokia E61 and from Apple’s Mail on my MacBook Pro, it does not work correctly with Claws Mail, and I have no idea why yet.

Sniffing the traffic to know what’s going on is a bit difficult considering that the whole conversation is over SSL, so I will have to wait for Ticho to respond to my ping so I can ask him how to debug it.

On the other hand, I have to say I’m quite full of spam on my GMail account, even if their antispam filter is quite good on its own. Unfortunately up to now I used GMail mostly with POP3 and fetchmail (beside the time when Enterprise was down of course), so even when the spam passed through the filter, it was often filtered out by SpamAssassin, and trying to clean it up from GMail’s All Mail was a long and boring task (I did it a few times for the first 20 pages or so then I stopped because it was too boring and too long). Marking stuff as spam with Apple’s Mail and IMAP instead sounds easier: I can just change the order of the mails so that the ones with priority set are grouped, or group them by sender or subject, then I can select all of them and just move them on the Spam folder. Quick and easy, mostly. The problem is that I gave order to Apple’s Mail to move more than two thousands messages, and it’s taking some time to give the orders to the server.

And today is a long day..

HD dying

For the people who like to find trends and cabals, I’ve seen two new trends lately. The first is Hard Disk dying, the other is people bouncing back to sender the spam.

For the first trend, I joined the cabal myself: Defiant’s disk is dying, and this is bad because I was going to stress it even more with catalyst building today, as Zac fixed the portage bug that prevented me to work on it yesterday (thanks Zac, without you we wouldn’t be able to continue using Portage day by day :) ). Luckily, the box is not my main box nor my server (Farragut and Enterprise run both on Samsung drives, only Defiant ran on Maxtor), and I do have a spare Maxtor 80G to give it. The problem is that I have to reinstall it from scratch, and this is probably not going to happen today because I have a friend of mine coming to my house that I need to help.

Well, this 20G drive I was using is quite old now, I bought it for my first Pentium 133, which means it was either 1998 or 99, so it’s not that unexpected that the disk was going to die sooner or later. It’s just an unfortunate coincidence that it died today. Oh well, I’ve the spare and I will put it on tomorrow most likely, so if all goes well, while I’m at the meeting Tuesday afternoon, Defiant will be simply building everything again (I hope).

Talking about the second trend, I wonder why on the Earth mail admins has to reject mails with high spam score. You know, if the mail is spam, the From address is surely forged, you’re just going to spam someone else. The same happens for viruses. The rare cases where a false positive happens, well, are, in my opinion, not worth the hassle you shove on other people.

The funny thing is that I didn’t start receiving such a mail for a while till two days ago, when postmodern started doing so. Then I’ve seen other four mail servers doing the same, with the most different messages for rejection. Stupid stupid thing!

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.

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.

^[return]

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

Introduzione

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.

L’invio e il transito della posta

La consegna della posta

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.

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

La lettura della posta

Post Office Protocol

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.

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

Richieste hardware e software

È poi necessario avere i seguenti pacchetti: fetchmail, maildrop e
courier-imap. Opzionalmente è possibile utilizzare bogofilter 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.

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

Scartai anche cyrus-imapd semplicemente perché non riuscivo a capire
come funzionasse. Invece courier è stato abbastanza semplice da
configurare.

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 courier-imap.

Quando ho applicato per la prima volta questa soluzione, su Gentoo
Linux, usai la suite, anche perché non era ancora molto affinata e
inizialmente pensavo di usare anche l’MTA. L’attuale server invece
utilizza Courier-IMAP e Maildrop.

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

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

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 Courier supporta
tranquillamente IMAP-over-SSL.

Webmail

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.

Raccogliere la posta

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

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.

Una volta installato Courier IMAP troverete in /etc/courier-imap/ i
suoi file di configurazione. Quelli che ci interessano maggiormente sono
imapd e imapd-ssl, poiché il server IMAP-over-SSL viene configurato
da entrambi i files.

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 file
/etc/courier-imap/imapd.

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ò 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 finire, ricordatevi di configurare il file da cui verrà poi generato
il certificato SSL, si tratta del file imapd.cnf.

Fate molta attenzione che il valore CN che trovate in quel file
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 certificato non è
valido per il server a cui ci si è collegati.

Bisogna poi configurare la directory che Courier utilizzerà per
presentare i messaggi ai client. Predefinita è 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 modificare la variabile
MAILDIRPATH dentro al file /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
file di configurazione di imap.

Incasellare la posta

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

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.

Inserire le mailing list in diverse cartelle

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

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

to "Maildir"

Cancellare lo spam conosciuto

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"

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

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

Bogofilter

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 seconda riga invece cerca tale header, e se lo trova, inserisce la
mail dentro la cartella che abbiamo predisposto per il probabile spam.

SpamAssassin

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

Reinoltrare una copia delle email

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"

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

*/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.

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.

^[return]