Private e-mail in the 21st century
Some time ago I decided that it's time to move away from Gmail. It is a decent e-mail provider, but I don't really like its web-client, and its incompatibility with existing standards1 makes it hard to use any alternatives. I also wanted to use my own domain, but could do it only if I buy GSuite for 5$/month. I've looked at other e-mail providers, but all of them require more or less the same fee for a custom domain. At that point I've thought: why do I have to trust them with my mail2 and pay the fee when I can set up and maintain my own private server for the same price, right?
Right. The only problem is that having your own mail server nowadays seems to be a huge pain. Most setup manuals require you to take many steps and install and configure several pieces of software. Hell, people even bundle all of it together and make an installer3. It happens because modern e-mail server software is very complex. It manages users and their mailboxes, supports dozens of storage and authentication backends, tries to be compatible with older systems, etc.4 5
But should it be that way if you plan to have e-mail server only for yourself? I doubt that. I believe that for that task you don't need most of the features of modern e-mail software. Take support of several storage backends for example. Would you care if your messages are stored in a plain text file or a database? Probably not. You'd rather care about secure and reliable access to them and convenient representation in a client. What about user management if you are the only one using the system? Or compatibility with some legacy protocol when your e-mail client uses modern one?
So, what would be my ideal setup? First I start with the assumption "one domain
= one user". This way mail server doesn't need to manage users, and thus to
implement this huge and complex feature. In case of family you can use
subdomains, e.g. mail@john.doe.com and mail@jane.doe.com, and configure
separate mail server for each person.
Next let's deal with mailboxes, i.e. the part of e-mail address before @.
I like an idea of having separate mailboxes for different things, e.g. I use
dev for conversations about my software projects, gov for exchanging
messages and documents with governmental institutions, mail for private
conversations, and rubbish for everything non-important. Messages for each
mailbox go under their own separate label and into global inbox folder.
I believe this setup is quite convenient, and also allows mail server to
greatly simplify implementation of virtual mailboxes.
Now move on to message storage. There are several formats for storing e-mail messages, e.g mbox, maildir, but I believe that keeping messages in database is the best way. Database deals with concurrent reading and writing, and is more suitable for saving small pieces of data6, which messages are. Though I couldn't find any SQL schema standard for storing e-mail, schema from Archiveopteryx looks interesting, though it might need to be simplified since Archiveopteryx is a full-fledged mail server that supports a lot of stuff.
So far, so good. Since receiving and storing messages are covered, let's talk about delivering them to the user. Usually for that one need to install and set up another server that exposes messages to clients. I think it doesn't make much sense to keep sending/receiving and delivering parts separated, so it should be one piece of software to handle everything (not necessary one executable though). IMAP and POP3 are usually used for serving messages but they both have disadvantages7 8 9, and though many existing e-mail clients support them, I prefer to have an HTTP API to access my mail. The reason for that is simple: HTTP is the backbone of web; it is optimized for fast and secure delivery of information, and is supported by lots of libraries and tools. JMAP protocol is based on HTTP and JSON and looks quite promising, though again, it might be rather complex in case of personal e-mail.
Of course, server should be secured and authenticated. That part should be automated as much as possible, though I do not see many ways to improve it besides automatically generating keys and certificate requests using sane defaults, and then instructing the user on how to install and use them properly.
-
E.g. moving to "All mail" instead of deleting when using IMAP
-
I really don't want to start a rant about privacy, so here is a short summary for the curious ones: I have nothing to hide. Why should I care about my privacy?