Finished article on Mailu

1 files changed, 18 insertions, 20 deletions

diff --git a/_posts/2018-06-01-mailu.md b/_posts/2018-06-01-mailu.md
index a3a0efd..edf7a48 100644
--- a/_posts/2018-06-01-mailu.md
+++ b/_posts/2018-06-01-mailu.md
@@ -5,38 +5,36 @@ date:   2018-06-01 20:17:00 +0100
 categories: jekyll update
 ---
 
-I'm a big user of Google's software & services. Sometimes though, I wonder if I am too dependent on their services. The saying I have heard is that if you aren't paying for the product, then you are the product. I can use Google's services on their terms, which may include picking through my data for whatever reason.
+## My search for an email server
 
-Having recently acquired a [Raspberry Pi][rpi], I decided to see what I could move my data away from Google's cloud and back into my own home. I made the following list of services that I regularly use:
+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
-* Instant messaging
-* Social media
-* Photo storage
-* Document storage
+Email is complicated: this is because it is old, and it has changed over time. [One of the first articles I found](https://www.digitalocean.com/community/tutorials/why-you-may-not-want-to-run-your-own-mail-serve) is a quick rundown of how complex the email system is. [Ars technica][ars-technica-guide] ran a guide for setting up your own email server:
 
-This blog post is about email. Email is great. Email has been around since the very early internet days, and there are numerous excellent free & open-source bits of software that do email. At first glance, it may seem trivial to download all the relevant software, get it configured and hey presto, you have an email server. This isn't quite how this project turned out.
+>Why do battle with arcane dragons to roll your own e-mail solution?
 
-Dovecot for IMAP. Postfix for SMTP. Get this working basically first, then add: Spamassassin for spam filtering, then clamav for anti-virus. Then maybe roundcube for webmail...
+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 quickly found myself mired in configuration choices. Did I want real user accounts on my pi, or virtual user accounts in a database? How do I route the mail through spamassassin? Do I allow incoming mail from the local network without authentication? 
+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. 
 
-There is plenty of [documentation][dovecot-basic] and [guides][ars-technica-guide] about how to (and why) set up your own email server. The arstechnica guide I particularly like because it sets the scene so well: 
+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. 
 
->Why do battle with arcane dragons to roll your own e-mail solution?
+I started looking for an open-source project that fulfils the same role. I found [Maddy](https://github.com/emersion/maddy), inspired by the new minimal-configuration http/2 server [Caddy][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.
 
-Eventually I actually gave up trying to configure by myself all the services required to do email properly. It would have taken way more time, research, and testing than I was willing to put in. So I started looking for alternative routes. 
+Although I made a [little effort](https://github.com/MFAshby/gomail) 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)
 
-Around the same time, I was revisiting the [Go][golang] programming language. There is now an excellent minimal-configuration web server called [Caddy][caddy], written in go, with a simple configuration file and good stuff like HTTPS & HTTP/2 included by default. I embarked on a mission to write [my own mail server 'gomail'][gomail] with the same principles. This kind of worked, except it turns out to be a monumental effort to correctly implement the IMAP and SMTP protocols. A kind soul [emersion][emersion] has actually done most of the hard protocol work, creating nice go wrappers for SMTP and IMAP. Even with all this background work completed, it's still a monumemtal task. Emersion had already tried with [maddy][maddy], but as of writing this blog it's still very much incomplete. The idea has even been discussed on the [Caddy forums][caddy-forum-non-http], but no real progress made.
+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][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.
 
-There are a couple of alternative ways to get a good mail server setup: [iRedMail][iredmail] offers what is essentially a configuration script to get a new Debian / Ubuntu install to become a working mail server. This approach works fine, as long as you are starting with a fresh Debian install.
+This approach actually leads really neatly onto the last solution I tried, and the one I actually have working: [Mailu][mailu]. This project provides all the same open-source email components (postfix, dovecot), but pre-configured and packaged as [Docker][docker] images. I feel like this is the best approach for a few reasons:
 
-This approach actually leads really neatly onto the last solution I tried, and the one I actually have working: [Mailu][mailu]. This project provides all the same open-source email components (postfix, dovecot), but pre-configured and packaged as [Docker][docker] images. This has a couple of advantages over iRedMail: 
-* You don't need a fresh Debian install. You only need a working Docker installation.
-* You can configure & run other services on the same machine without interference.
-* It's more easily portable: copy over the single /var/lib/mailu directory to another machine, and spin up all the servers again with `docker-compose up` and it's all back up & working again.
+* 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 -d` and 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](https://github.com/kaiyou) is very helpful, and gratefully accepts pull requests. 
 
-The project didn't work out of the box with Raspberry Pi - not all the base images are ARM compatible. This was a pretty easy thing to fix though, and I now maintain a permanent fork of mailu for Raspberry Pi over [here][mailu-rpi]
+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][mailu-rpi]
 
 [rpi]:https://www.raspberrypi.org/
 [dovecot-basic]:https://wiki.dovecot.org/BasicConfiguration