My search for an email server
A big theme in the news recently is data protection, how your personal data is being used (and abused), and taking back control of your data. Part of the problem is that people’s personal data is kept in huge private corporate networks, and historically companies have been able to do (essentially) whatever they like with it. I started investigating how difficult it would be to really re-take control of my personal data - beginning with my email.
Email is complicated: this is because it is old, and it has changed over time. One of the first articles I found is a quick rundown of how complex the email system is. Ars technica ran a guide for setting up your own email server:
Why do battle with arcane dragons to roll your own e-mail solution?
The arcane dragons are the pieces of software that have become the most popular choices for email servers. A typical email server configuration contains the following pieces of open-source software: dovecot, postfix, spamassassin, clamav, sendmail, roundcube, mysql. Each of them fills a different role in the email system, and each of them can be configured to operate in many different ways.
I began setting up my email server in this way, however I gave up pretty quickly: I found that walkthroughs on the internet were often out of date, and configuration options had changed or been removed. I also found it really difficult to understand from the guides how all the pieces of the puzzle fit together. I started looking for alternative routes.
Microsoft Exchange Server fulfils all the roles of the separate open-source components in a single piece of software. This sounds much easier to configure: however I don’t have a Windows server, and nor do I want to pay licensing costs for it.
I started looking for an open-source project that fulfils the same role. I found Maddy, inspired by the new minimal-configuration http/2 server Caddy. Sadly, the project is seriously incomplete right now, but the principle sounds great: a self-contained email server with minimal configuration conforming to best practices by default.
Although I made a little effort to cobble together this project into a working email server, I discovered this was a much bigger task than I had anticipated. I discovered some more arcane dragons in the form of the email standards for SMTP and IMAP. These are old, stateful protocols with many extensions, versions and awkward syntax. Modern systems are built with REST APIs for a reason: they are much quicker for the developer to understand and build with (they are also way easier to load balance, due to the lack of state)
I came back around to the idea of using the existing software, but this time I started looking for pre-configured systems. I discovered iRedMail which claims to turn a fresh Debian or Ubuntu install into a working email server. This isn’t bad, but I want to run a few other services from my Raspberry as well, and I’d rather not clobber them by re-installing Debian.
This approach actually leads really neatly onto the last solution I tried, and the one I actually have working: Mailu. This project provides all the same open-source email components (postfix, dovecot), but pre-configured and packaged as Docker images. I feel like this is the best approach for a few reasons:
- You don’t need a fresh Debian install, you just need a working Docker host.
- The hard configuration has been done for you. Just a single config file with a few easy to understand options is required.
- It’s portable: copy over the mailu directory and the docker-compose.yml file to another machine, execute
docker-compose up -dand it’s back online with all the same accounts.
- An admin interface is included.
- It’s open source so you can check if it conforms to current security practices, and modify it if you need to.
- The maintainer kaiyou is very helpful, and gratefully accepts pull requests.
Although the project didn’t work out of the box with Raspberry Pi this was a pretty easy thing to fix. I now maintain a permanent fork of mailu for Raspberry Pi over here