WordPress, really?

If you’re reading this blog post, particularly directly on my website, you probably noticed that it’s running on WordPress and that it’s on a new domain, no longer referencing my pride in Europe, after ten years of using it as my domain. Wow that’s a long time!

I had three reasons for the domain change: the first is that I didn’t want to keep the full chain of redirects of extremely old link onto whichever new blogging platform I would select. And the second is it that it made it significantly easier to set up a WordPress.com copy of the blog while I tweaked and set it up, rather than messing up with the domain at once. The third one will come with a separate rant very soon, but it’s related to the worrying statement from the European Commission regarding the usage of dot-EU domains in the future. But as I said, that’s a separate rant.

I have had a few people surprised when I was talking over Twitter about the issues I faced on the migration. I want to give some more context on why I went this way.

As you remember, last year I complained about Hugo – to the point that a lot of the referrers to this blog are still coming from the Hacker News thread about that – and I started looking for alternatives. And when I looked at WordPress I found that setting it up properly would take me forever, so I kept my mouth shut and doubled-down on Hugo.

Except, because of the way it is set up, it meant not having an easy way to write blog posts, or correct blog posts, from a computer that is not my normal Linux laptop with the SSH token and everything else. Which was too much of a pain to keep working with. While Hector and others suggested flows that involved GIT-based web editors, it all felt too Rube Goldberg to me… and since moving to London my time is significantly limited compared to before, so I either spend time on setting everything up, or I can work on writing more content, which can hopefully be more useful.

I ended up deciding to pay for the personal tier of WordPress.com services, since I don’t care about monetization of this content, and even the few affiliate links I’ve been using with Amazon are not really that useful at the end of the day, so I gave up on setting up OneLink and the likes here. It also turned out that Amazon’s image-and-text links (which use JavaScript and iframes) are not supported by WordPress.com even with the higher tiers, so those were deleted too.

Nobody seems to have published an easy migration guide from Hugo to WordPress, as most of the search queries produced results for the other way around. I will spend some time later on trying to refine the janky template I used and possibly release it. I also want to release the tool I wrote to “annotate” the generated WRX file with the Disqus archive… oh yes, the new blog has all the comments of the old one, and does not rely on Disqus, as I promised.

On the other hand, there are a few things that did get lost in the transition: while JetPack Plugin gives you the ability to write posts in Markdown (otherwise I wouldn’t have even considered WordPress), it doesn’t seem like the importer knows at all how to import Markdown content. So all the old posts have been pre-rendered — a shame, but honestly that doesn’t happen very often that I need to go through old posts. Particularly now that I merged in the content from all my older blogs into Hugo first, and now this one massive blog.

Hopefully expect more posts from me very soon now, and not just rants (although probably just mostly rants).

And as a closing aside, if you’re curious about the picture in the header, I have once again used one of my own. This one was taken at the maat in Lisbon. The white balance on this shot was totally off, but I liked the result. And if you’re visiting Lisbon and you’re an electronics or industrial geek you definitely have to visit the maat!

Diabetes management software, online apps, and my projects

So my previous post with glucometerutils news got picked up by Hackaday, and though the comments ended up mostly talking about the (more physical, less practical) note about fiddling with the glucometers hardware themselves (which would suggest me the editor should probably have avoided moving the spotlight in the post, but never mind), I ended up replying to a few comments that were actually topical, to the point that I thought I should be writing about this more extensively.

In the comments, someone brought up Tidepool, which is a no-profit in California that develops what to me appears to be its own data storage and web application for diabetics. This is not far from what Glucosio is meant to be — and you might remember that an interaction with them, had me almost leave open source development, at least for what diabetes is concerned.

The problem with both projects, and a number of others that I’ve been pointed to over the years, is that I find most of them either not practical or web-oriented, or a mixture of the two. With not practical I mean that while building an “universal glucometer” capable of using any random strip is an interesting proposal, it does nothing to improve the patients’ life, and it actually can significantly increase the risks of misreading values and thus, risk the life of the user. For this reason, plus the fact that I do not have enough of a biochemistry understanding to figure out how to evaluate the precision of the meters that are already certified, I don’t invest any time looking into these projects.

Web-based applications such as Tidepool and similar are also far from my interests. I do not have a personal problem with accessing my blood sugar readouts for the sake of research, but I do have some concerns about which actors are allowed access to them. So in particular a startup like Glucosio is not someone I’d be particularly fond of giving access to my data to. Tidepool may be a no-profit, but that does not really make me feel much better, particularly because I would expect that an US-based no-profit would not have gone through all the possible data processing requirements of EU legislation, unlike, say, Abbott. I have already written a lot about why I don’t find self-hosting a good solution so I don’t think I need to spend much time on it here.

Except, there is one extra problem with those apps that require you to set up your own instance — like some of the people who have not been waiting some time ago. While running an app for my own interest may sound like an interesting thing to do, particularly if I want to build up the expertise to run complicated web app stacks, my personal ultimate goal is to have my doctor know what my blood sugar levels are over time. This is the whole point why I started that tool, I wanted to be able to output a PDF that my doctor could see without having to jump around a number of hoops to produce it — I failed to do so, but in part because I lost interest after I started using the awesome Accu-Chek Mobile.

If I were to tell my doctor «Log in on this site here with these credentials and you can see my readouts» he might actually do it, but mostly because of novelty and because he entertains my geekery around trying different meters and solutions. If he started to get this request from dozens of his patients, not only he’d have to keep a password managers just to deal with credentials, but he’d probably just couldn’t have the time to deal with it. The LibreLink app does have the ability to share data with a few services, and he did suggest me to look into diasend, but it looks like it got merged into something else that might or might not work for now, so I gave up.

Now, here is an interesting prospect, and why such apps are not completely worthless in my opinion. If the protocols are open to be used, and the apps are open source and can be set up by anyone, there is space for the doctors to have their own instance set up so that their patients can upload their data. Unfortunately, the idea that being open source this does not involve a significant investment in time and money is patently false. Particularly for important data like this, there has to be proper security, starting from every session being encrypted with TLS, and the data encrypted at rest (it is ironic that neither Tidepool nor Glucosio, at the time of writing, use TLS for their main websites). So I still don’t expect doctors in the public sector to be using these technologies any time soon. But on the other hand, there are more and more apps for this being built by the diabetes tech companies, so maybe we’ll see something happening in the future.

Where does this leave my project? Well, to begin with it’s not a single project but two of them. glucometerutils was born as a proof of concept and is still a handy tool to have. If someone manages to implement output to HTML or to PDF of the data, that would make it a very useful piece of software that does not need to interact with any remote, online application. The protocols repository serves a distinct need: it provides a way for more people to contribute to this ecosystem without requiring each of them to invest significant time in reversing the protocols, or getting in bed with the manufacturers, which – I can only guess – involves NDAs, data-sharing agreements, and similar bureaucracy that most hobbyist developers can’t afford.

Indeed, I know of at least one app, built for iOS, proprietary and commercial (as in, you have to pay for it), that has built support for meters thanks to my repository (and the author gave back in form of corrections and improvements on the documentation!). This is perfectly in line with my reasons to even have such a repository. I don’t care if the consumers and contributors to the repository build closed-source tools, as long as they share the knowledge on how to get to the data. And after that, may the best tool win.

As I said before, smartphones are no longer a luxury and for many people they are the only way they can access the Internet. It makes sense that the same way, for many diabetics it is their only way to analyse their readouts. This is why Contour Next One comes with Bluetooth and a nice app, and why there even are standard Bluetooth specification for glucometers (GLP/GLS) and continuous monitors (CGMP/CGMS). If my work on an open-source tool brings more people the ability to manage their diabetes, even with closed-source software, I’ll consider myself satisfied.

Now, there is one more interesting bit with Tidepool, though: they actually publish a Chrome-based uploader app that is able to download data from many more glucometers than my own tool (and the intersection between the two is minimal). This is great! But, as it happens, it comes with a little bit of a downside: the drivers are not documented at all. I confirmed the reason is that the access to the various meters’ protocols is subject to NDA — so while they can publish the code that access those meters, they cannot publish the specs of the protocols themselves, and that appears to include in-code comments that would make it easy to read what’s going on.

So, one of the things I’m going to do is read through those drivers, and try to write a protocol spec for the meters. It appears that they have a driver for Contour Next meters, which may or may not work for the Contour Next One which I’ve been trying to reverse engineer — I know there is at least one other open-source implementation of accessing data from Contour Next meters, but the other one is GPL-2 and, like OpenGlucose, I’ve avoided looking too closely to the code.

Projects such as Tidepool are extremely important to provide a proper alternative to the otherwise closed-garden of proprietary cloud diabetes management software. And if they become simple, and secure enough to set up, it is possible that some of the doctors will start providing their own instances where their patients can upload the readings, and that will make them also practical. But for now, to me they are only a good source of confrontation to figure out a way forward for my own tools.

Running services on Virgin Media (Ireland)

Update: just a week after I wrote this down (and barely after I managed to post this), Virgin Media turned off IPv6-PD on the Hub 3.0. I’m now following up with them and currently without working IPv6 (and no public IPv4) at home, which sucks.

I have not spoken much about my network setup since I moved to Dublin, mostly because there isn’t much to speak, although admittedly there are a few interesting things that are quite different from before.

The major one is that my provider (Virgin Media Ireland, formerly known as UPC Ireland) supports native IPv6 connectivity through DS-Lite. For those who are not experts of IPv6 deployments, this means that the network has native IPv6 but loses the public IPv4 addressing: the modem/router gets instead a network-local IPv4 address (usually in the RFC1918 or RFC6598 ranges), and one or more IPv6 prefix delegations from which it provides connectivity to the local network.

This means you lose the ability to port-forward a public IPv4 address to a local host, which many P2P users would be unhappy about, as well as having to deal with one more level of NAT (and that almost always involves rate limiting by the provider on the number of ports that can be opened simultaneously.) On the other hand, it gives you direct, native access to the IPv6 network without taking away (outbound) access to the legacy, IPv4 network, in a much more user-friendly way than useless IPv6-only networks that rely on NAT64. But it also brings a few other challenges with it.

Myself, I actually asked to be opted in the DS-Lite trial when it was still not mandatory. The reason for me is that I don’t really use P2P that much (although a couple of times it was simpler to find a “pirate” copy of a DVD I already own, rather than trying to rip it to watch it now that I have effectively no DVD reader), and so I have very few reasons to need a public IPv4 address. On the other hand, I do have a number of backend-only servers that are only configured over the IPv6 network, and so having native access to the network is preferable. On the other hand I do have sometimes the need to SSH into a local box or HTTP over Transmission or similar software.

Anyway back on my home network, I have a Buffalo router running OpenWRT behind the so-called Virgin Media Hub (which is also the cable modem — and no it’s not more convenient to just get a modem-mode device, because this is EuroDOCSIS which is different from the US version, and Virgin Media does not support it.) And yes this means that IPv4 is actually triple-natted! This device is configured to get a IPv6 prefix delegation from the Hub, and uses that for the local network, as well as the IPv4 NAT.

Note: for this to work your Hub needs to be configured to have DHCPv6 enabled, which may or may not do so by default (mine was enabled, but then a “factory restore” disabled it!) To do so, go to the Hub admin page, login, and under Advanced, DHCP make sure that IPv6 is set to Stateful. That’s it.

There are two main problems that needs to be solved to be able to provide external access to a webapp running on the local server: dynamic addressing and firewalls. These two issues are more intertwined than I would like, making it difficult to explain the solution step by step, so let me first present the problems.

On the machine that needs to serve the web app, the first problem to solve is making sure that it gets at least one stable IPv6 address that can be reached from the outside. It used to be very simple, because except for IPv6 privacy extensions the IPv6 address was stable and calculated based on prefix and hardware (MAC) address. Unfortunately this is not the the case now; RFC7217 provides “Privacy stable addressing”, and NetworkManager implements it. In a relatively-normal situation, these addresses are by all means stable, and you could use them just fine. Except there is a second dynamic issue at hand, at least with my provider: the prefix is not stable, both for the one assigned to the Hub, and for that then delegated to the Buffalo router. Which means the network address that the device gets is closer to random than stable.

While this first part is relatively easy to fix by using one a service that allows you to dynamically update a host name, and indeed this is part of my setup too (I use Afraid.org), it does not solve the next problem, which is to open the firewall to let the connections in. Indeed, firewalls are particularly important on IPv6 networks, where every device would otherwise be connected and visible to the public. Unfortunately unless you connect directly to the Hub, there is no way to tell the device to only allow a given device, no matter what the prefix assigned is. So I started by disabling the IPv6 firewall (since no device is connected to the Hub directly beside the OpenWRT), and rely exclusively on the OpenWRT-provided firewall. This is the first level passed. There is one more.

Since the prefix that the OpenWRT receives as delegation keeps changing, it’s not possible to just state the IPv6 you want to allow access to in the firewall config, as it’ll change every time the prefix changes, even without the privacy mode enabled. But there is a solution: when using stable, not privacy enabled addresses, the suffix of the address is stable, and you can bet that someone already added support in ip6tables to match against a suffix. Unfortunately the OpenWRT UI does not let you set it up, but you can do that from the config file itself.

On the target host, which I’m assuming is using NetworkManager (because if not, you can just let it use the default address and not have to do anything), you have to set this one property:

# nmcli connection show
[take note of the UUID shown in the list]
# nmcli connection modify ${uuid} +ipv6.addr-gen-mode eui64

This re-enables EUI-64 based addressing for IPv6, which is based off the mac address of the card. It’ll change the address (and will require reconfiguration in OpenWRT, too) if you change the network card or its MAC address. But it does the job for me.

From the OpenWRT UI, as I said, there is no way to set the right rule. But you can configure it just fine in the firewall configuration file, /etc/config/firewall:

config rule
        option enabled '1'
        option target 'ACCEPT'
        option name 'My service'
        option family 'ipv6'
        option src 'wan'
        option dest 'lan'
        option dest_ip '::0123:45ff:fe67:89AB/::ffff:ffff:ffff:ffff'

You have to replace ::0123:45ff:fe67:89AB with the correct EUI64 suffix, which includes splicing in ff:fe and flipping one bit. I never remember how to calculate it so I just copy-paste it from the machine as I need it. This should give you a way to punch through all the firealls and get you remote access.

What remains to be solved at this point is having a stable way to contact the service. This is usually easy, as dynamic DNS hosts have existed for over twenty years by now, and indeed the now-notorious (for being at the receiving end of one of the biggest DDoS attacks just a few days ago) Dyn built up their fame. Unfortunately, they appear to have actually vastly dropped the ball when it comes to dynamic DNS hosting, as I couldn’t convince them (at least at the time) to let me update a host with only IPv6. This might be more of a problem with the clients than the service, but it’s still the same. So, as I noted earlier, I ended up using Afraid.org, although it took me a while where to find the right way to update a v6-only host: the default curl command you can find is actually for IPv4 hosts.

Oh yeah there was a last one remaining problem with this, at least when I started looking into fixing this all up: at the time Let’s Encrypt did not support IPv6-only hosts, when it came to validating domains with HTTP requests, so I spent a few weeks fighting and writing tools trying to find a decent way to have a hostname that is both dynamic and allows for DNS-based domain control validation for ACME. I will write about that separately, since it takes us on a tangent that has nothing to do with the actual Virgin Media side of things.

My thoughts on the Self-Hosting Solution

You probably noticed that in the (frequent) posts talking about security and passwords lately, I keep suggesting LastPass as a password manager. This is the manager that I use myself, and the reason why I came to this one is multi-faceted, but essentially I’m suggesting you use a tool that does not make it more inconvenient to maintain proper password hygiene. Because yes, you should be using different passwords, with a combination of letters, numbers and symbols, but if you have to come up with a new one every time, then things are going to be difficult and you’ll just decide to use the same password over and over.

Or you’ll use a method for having “unique” passwords that are actually comprised of a fixed part and a mobile one (which is what I used for the longest time). And let’s be clear, using the same base password suffixed with the name of the site you’re signing up for is not a protection at all, the moment more than one of your passwords is discovered.

So convenience being important, because inconvenience just leads to bad security hygiene, LastPass delivers on what I need: it has autofill, so I don’t have to open a terminal and run sgeps (like I used to be) to get the password out of the store, it generates the password in the browser, so I don’t have to open a terminal and run pwgen, it runs on my cellphone, so I can use it to fetch the password to type somewhere else, and it even auto-fills my passwords in the Android apps, so I don’t have to use a simple password when dealing with some random website that then patches to an app on my phone. But it also has a few good “security conveniences”: you can re-encode your Vault on a new master password, you can use a proper OTP pad or a 2FA device to protect it further, and they have some extras such as letting you know if the email you use across services are involved in an account breach.

This does not mean there are no other good password management tools, I know the name of plenty, but I just looked for one that had the features I cared about, and I went with it. I’m happy with LastPass right now. Yes, I need to trust the company and their code a fair bit, but I don’t think that just being open source would gain me more trust. Being open source and audited for a long time, sure, but I don’t think either way it’s a dealbreaker for me. I mean Chrome itself has a password manager, it just feels not suitable for me (no generation, no obvious way to inspect the data from mobile, sometimes bad collation of URLs, and as far as I know no way to change the sync encryption password). It also requires me to have access to my Google account to get that data.

But the interesting part is how geeks will quickly suggest to just roll your own, be it using some open-source password manager, requiring an external sync system (I did that for sgeps, but it’s tied to a single GPG key, so it’s not easy for me having two different hardware smartcards), or even your own sync infrastructure. And this is what I really can’t stand as an answer, because it solves absolutely nothing. Jürgen called it cynical last year, but I think it’s even worse than that, it’s hypocritical.

Roll-your-own or host-your-own are, first of all, not going to be options for the people who have no intention to learn how computer systems work — and I can’t blame them, I don’t want to know how my fridge or dishwasher work, I just want them working. People don’t care to learn that you can get file A on computer B, but then if you change it on both while offline you’ll have collisions, so now you lost one of the two changes. They either have no time, or just no interest or (but I don’t think that happens often) no skill to understand that. And it’s not just the random young adult that ends up registering on xtube because they have no idea what it means. Jeremy Clarkson had to learn the hard way what it means to publish your bank details to the world.

But I think it’s more important to think of the amount of people who think that they have the skills and the time, and then are found lacking one or both of them. Who do you think can protect your content (and passwords) better? A big company with entire teams dedicated to security, or an average 16 years old guy who think he can run the website’s forum? — The reference here is to myself: back in 20002001 I used to be the forum admin for an Italian gaming community. We got hacked, multiple times, and every time it was for me a new discovery of what security is. At the time third-party forum hosting was reserved to paying customers, and the results have probably been terrible. My personal admin password matched one of my email addresses up until last week and I know for a fact that at least one group of people got access to the password database, where they were stored in plain text.

Yes it is true, targets such as Adobe will lead to many more valid email addresses and password hashes than your average forum, but as the “fake” 5M accounts should have shown you, targeting enough small fishes can lead to just about the same results, if not even better, as you may be lucky and stumble across two passwords for the same account, which allows you to overcome the above-mentioned similar-but-different passwords strategy. Indeed, as I noted in my previous post, Comic Book Database admitted to be the source of part of that dump, and it lists at least four thousand public users (contributors). Other sites such as MythTV Talk or PoliceAuctions.com, both also involved, have no such statement ether.

This is not just a matter of the security of the code itself, so the “many eyes” answer does not apply. It is very well possible to have a screw up with an open source program as well, if it’s misconfigured, or if a vulnerable version don’t get updated in time because the admin just has no time. You see that all the time with WordPress and its security issues. Indeed, the reason why I don’t migrate my blog to WordPress is that I won’t ever have enough time for it.

I have seen people, geeks and non-geeks both, taking the easy way out too many times, blaming Apple for the nude celebrity pictures or Google for the five million accounts. It’s a safe story: “the big guys don’t know better”, “you just should keep it off the Internet”, “you should run your own!” At the end of the day, both turned out to be collections, assembled from many small cuts, either targeted or not, in part due to people’s bad password hygiene (or operational security if you prefer a more geek term), and in part due to the fact that nothing is perfect.

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-robin1 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.


  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.

    [return]

Facilitare l’accesso ai propri servizi con DynDNS e DJBDNS

Uno dei problemi che si possono avere accedendo ai servizi della propria
LAN casalinga dall’esterno è che IP e hostnames non corrispondono, e
richiedono dei giochi per poter funzionare indistintamente.

Questo articolo darà modo a chi ne avesse bisogno di semplificare
l’accesso ai propri servizi, non richiedendo modifiche alla
configurazione dei programmi per gli accessi interni o esterni.

Introduzione

Avendo a casa una piccola LAN (tre computer in realtà), ho dato ai due
fissi il compito di gestirmi alcuni servizi, come per esempio la posta
@localmailserver o il BNC1.

Ovviamente quando sono collegato alla rete interna, il portatile accede
a questi senza passare dal router (che ha un’interfaccia a 10Mbit e
verrebbe appesantito dalla necessità di effettuare il NAT inverso
sull’interfaccia WAN per poter fornire i servizi alle altre macchine),
ma se usassi gli indirizi IP interni poi dovrei riconfigurare da capo
tutti i programmi quando fossi fuori della mia LAN (per esempio a scuola
o a casa di amici).

In questo articolo voglio provare a dare una piccola soluzione a questo
problema che potrebbe riguardare anche altre persone, utilizzando i
servizi forniti da DynDNS, e il server DNS dnsmasq.

Hostname dinamici: perché e come

La prima cosa da fare se si vuole poter fornire servizi all’esterno
della propria LAN senza avere bisogno di conoscere in continuazione il
proprio IP è utilizzare un hostname dinamico, a meno che non abbiate un
IP fisso.

Gli hostname sono nati apposta per poter fornire un identificativo
mnemonico per le macchine su internet, ma nell’epoca in cui la maggior
parte dei provider forniscono soltanto IP dinamici, i classici hostname
sono inutili.

Per questo divrsi siti offrono servizi di hostname dinamici, ovvero
hostname il cui IP può essere cambiato automaticamente tramite un
client, un nome utente e una password.

Per prima cosa, registriamoci su , fino ad avere un nome utente (che
sarà per noi, appunto, utente), e una password (che sarà per noi,
ancora una volta, password). A questo punto poi potrete registrare un
hostname (che per facilità sarà il mio 2).

Configurazione del client

Ora installiamo un client, io solitamente utilizzo ddclient, che è
disponibile per la maggior parte delle distribuzioni linux e dei sistemi
operativi liberi (tra cui OpenBSD dove lo eseguo).

Modifichiamo quindi il file /etc/ddclient.conf, inserendo le seguenti
righe:

login=utente
password=password

server=members.dyndns.org 
protocol=dyndns2 
flameeyes.homelinux.net 
wildcard=yes

Notate quest’ultima riga, wildcard=yes, perché è molto importante. In
pratica consente di risolvere i domini di quarto livello (come per
esempio pippo.flameeyes.homelinux.net) con lo stesso IP configurato
sull’hostname di terzo livello. Ora vedremo per cosa ci serve questa
opzione.

Una volta che ddclient è configurato, basta semplicemente impostarlo per
l’avvio automatico (questo dipende dalla vostra distribuzione / sistema
operativo).

Configurazione delle macchine

Una volta configurata l’hostname, dobbiamo iniziare a configurare le
macchine. Per fare ciò prima di tutto scegliamo dei nomi per le singole
macchine se già non ne hanno. Seguendo i consigli di DJB@djb-hints, i
nomi delle macchine dovrebbero essere scelti in modo da essere tra loro
simili, e che non vadano ad interferire con le proprie competenze. Io
per esempio utilizzo i nomi di astronavi presi da Star Trek.

Una volta che abbiamo deciso i nomi per le varie macchine, possiamo
unirli al dominio preso da DynDNS per avere il nome completo delle varie
macchine. Per esempio possiamo avere una macchina chiamata defiant che
diventa il nome defiant.flameeyes.homelinux.net .

Per configurare le varie macchine abbiamo ora diverse possibilità a
seconda di quale distribuzione linux o sistema operativo si usa. Posso
quindi solo dare alcuni esempi generali.

Gentoo Linux

In Gentoo Linux per la configurazione di hostname e dominio basta
modificare due files.

Il primo è /etc/conf.d/hostname, in cui bisogna semplicemente settare

HOSTNAME="defiant"

Il secondo è /etc/conf.d/domainname, che va modificato in modo da
avere

DNSDOMAINNAME="flameeyes.homelinux.net"

Un riavvio ed è finita.

OpenBSD

In OpenBSD il cambiamento è ancora più semplice, basta eseguire il
comando

echo "defiant.flameeyes.homelinux.net" > /etc/myname

Per finire un riavvio.

Installazione del DNS

A questo punto resta solo la parte più critica: installare e configurare
il server DNS in modo da rispondere alle richieste per il nostro nuovo
dominio flameeyes.homelinux.net.

Il software che consiglio è dnsmasq. Per una semplice rete casalinga, la
sua gestione è semplice ma allo stesso tempo funzionale. Inoltre, è un
programma molto leggero e non consuma risorse di alcun genere.

La sua installazione è praticamente banale. Il consiglio è sempre quello
di controllare se la propria distribuzione mette a disposizione un
pacchetto per dnsmasq, in tal caso, la cosa più semplice è installarlo
tramite questa.

Nel caso non sia presente un pacchetto precompilato o un metodo per
installare dnsmasq direttamente tramite la propria distribuzione, la sua
compilazione e installazione è comunque molto semplice.

Per prima cosa scaricate dal sito l’ultima versione del programma, che
al momento è dnsmasq-2.23.tar.gz. A questo punto, basta estrarre i
sorgenti e lanciare il comando di compilazione e installazione:

    $ tar zxf dnsmasq-2.23.tar.gz
    $ cd dnsmasq-2.23
    $ gmake
    $ su -
    # gmake install

Nota: se si è sotto Linux, è possibile utilizzare make al posto di
gmake; se si è sotto BSD però è necessario utilizzare il make GNU.

Per sistemi basati su RPM, come SuSE e Fedora, è presente nel pacchetto
dei sorgenti anche un file rc.d per l’avvio automatico del servizio. Per
altre distribuzioni, si faccia riferimento ai pacchetti ufficiali e non.

In ogni caso, per avviare il servizio basta, una volta completata la
configurazione spiegata nella prossima sezione, basta eseguire il
comando dnsmasq, che entrerà da solo nello stato di daemon
preparandosi a ricevere richieste.

Configurazione

Anche la configurazione di dnsmasq è molto semplice, un file di
configurazione di esempio è disponibile nel tarball dei sorgenti, ma
quello che viene qui riportato è un esempio di configurazione per una
rete LAN classica.

    server=999.999.999.999      # server DNS del proprio provider
    local=/flameeyes.homelinux.net/ # considera questo dominio locale
    no-resolv           # non cercare su resolv.conf
    no-poll

A questo punto, basta fornire a dnsmasq le coppie di hostname e
indirizzi IP da risolvere. Per fare questo, basta configurarare
/etc/hosts ponendo gli hostname con un indirizzo fisso:

    127.0.0.1   localhost
    192.168.0.1 defiant.flameeyes.homelinux.net
    192.168.0.2 voyager.flameeyes.homelinux.net
    192.168.0.3 northstar.flameeyes.homelinux.net

dnsmasq leggerà il file per risolvere gli hostname locali, e troverà
l’IP a cui risolvere l’hostname fornito. Se l’indirizzo non è locale,
dnsmasq rimanderà la richiesta al server specificato, così che sia
sempre possibile avere una risposta corretta.

Configurare le macchine

Ovviamente perché le macchine della lan possano sfruttare il servizio
offerto da dnsmasq è necessario configurarle per utilizzarlo come server
DNS. Per fare ciò, su macchine Unix o Unix-like, basta configurare
/etc/resolv.conf come segue:

domain flameeyes.homelinux.net
nameserver 192.168.0.1
nameserver 999.999.999.999

tenendo conto che qui è stato scelto 192.168.0.1 come server DNS su cui
gira dnsmasq.

Ora potete provare a pingare l’host voyager, e vedrete che la
richiesta sarà verso 192.168.0.2 (sempre se avete settato il file
/etc/resolv.con come spiegato prima con l’opzione domain).


  1. Una specie di “proxy” per le connessioni IRC, che
    supporta anche i log delle conversazioni private quando non si è
    presenti.

    [return]

  2. Non uso più questo hostname da tempo, e ora è settato
    semplicemente staticamente su 127.0.0.1

    [return]

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

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à.

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-robin1 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
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.

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

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.

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 Courier 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.

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 Courier IMAP,
che esce dal seminato di questo articolo.

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.

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

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.


  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.

    [return]