Making a Mess of an E-mail Host
I made an attempt at making my own e-mail server. I was talked into it by Qorg, who reminded me of the existence of the original emailwiz script by Luke Smith. Seeing as I run an Arch Linux server, rather than a Debian-derivative, I would attempt to port it.
I intended to finish this completely, if only for the sake of credibility when I share my findings regarding the process of setting up an e-mail server, but in the end I have left it 98% finished. For various reasons I'll talk about, it wasn't quite worth finishing for me. But still, nonetheless, I hope what I have learned from it can be of use to someone.
How would this in theory be done?
I have made a port of the script, to Arch Linux, which you can find here. If you use a Debian-derivative you can make use of the original script, but for the other handful of weirdos out there that use Arch as a server OS, this may help you. I've taken the time to test most aspects of the script and iron out bugs caused by the peculiarities between Debian and Arch. The README details much of the prerequisites, and the process involved in set-up.
As I have said, I got 98% of the way there before throwing in the towel, not 100%. I am confident that this script should get you most of the way there. It will not get you all of the way there, there will be debugging to be done, but it should make your set-up process substantially simpler than it would have been otherwise.
Is this a good idea to try?
Eh, maybe. Here's some criteria that may help you make up your mind on whether or not you should try it yourself, if you are interested.
You must be able to set up a PTR record (reverse DNS) to your e-mail host. You may need to negotiate it with your ISP, or your server provider. This also typically means you have a static IP. I suspect this was the stumbling block that made my set-up much more difficult, and without it your e-mail server will be much less useful (large providers will filter you).
You should meet more than half of these criteria:
- You have a working knowledge (beyond novice) of Unix-like server administration.
- You plan to make your service useful to many people.
- You already have a server prepared.
- Privacy is enough of a concern that you are troubled by your mail being hosted anywhere but your own system.
- You are prepared to spend hours learning and debugging if needs be.
Debugging is your friend
You will in all likelihood run into issues. Here's some good things to try:
- 'sudo systemctl status *' - whatever the offending component could be, e.g. opendkim, postfix, etc.
- 'journalctl -xe'
- Use your mail client's error tracing - e.g. 'mutt -d 5'.
Thoughts on the pros and cons of self-hosting mail
Naturally, self-hosting will always be better from a privacy standpoint. The number of components you need to trust is smaller. Any other mail provider will be able to read your e-mails if they want to. Even if they offer server-side encryption in the event of a possible attack, this doesn't mean they can't decrypt it themselves.
Client-side encryption will to a degree somewhat level the playing field here. With client-side encryption, any mail you send is illegible to anyone par the sender and the recipient, provided your keys do not become compromised, no matter what e-mail provider you are using. Of course, if your e-mail provider has things like your real name, your phone number, and so on as part of registration, you are screwed anyway.
This one will probably go to larger e-mail providers, rather than to small individual projects. Unless you really think you know security and administration better than teams of people serving thousands - if you do, I have no idea how you got here and why you're reading this. In most cases you will need to thoroughly educate yourself to be able to utilise a comparable level of security - although, it can be argued that a mail client serving a single individual or a few people is also a smaller and less enticing target for attacks.
This could go either way. If you can guarantee the physical safety of your server, the lack of network traffic, you may find it to be more reliable and faster than a large provider. Or you may not. It really depends on your server, which you should know better than anyone.
Why have I left the e-mail server unfinished?
Mainly because it would not be worth it to me. As I mentioned, I cannot get a PTR record as I do not have a static IP address, so no reverse DNS lookups. This would make my e-mail less useful, as the e-mail I would send to large providers would be silently dropped and never reach their destination. I planned to finish this largely for the credibility in what I'm talking about. But, I decided to cut this short, because I'm beginning to build up a backlog of other things I'd like to do and things I would prefer to talk about.
My thoughts on some e-mail providers
If you've read all of the above, and would prefer to find a better, more privacy-respecting provider, but without going as far as making your own server, I have experience with some.
Note however that Cock.li is fairly honest about the fact that it's entirely possible to read your e-mails. They are transparent about this on their home page:
Cock.li doesn't parse your E-mail to provide you with targeted ads, nor does cock.li read E-mail contents unless it's for a legal court order. However, it is 100% possible for me to read E-mail, and IMAP/SMTP doesn't provide user-side/client-side encryption, so you're just going to have to take my word for it. Any encryption implementation would still technically allow me to read E-mail, too. This was true for Lavabit as well -- while your E-mail was stored encrypted (only if you were a paid member, which most people forget), E-mail could still technically be intercepted while being received / sent (SMTP), or while being read by your mail client (IMAP). For privacy, we recommend encrypting your E-mails using PGP using a mail client add-on like Enigmail, or downloading your mail locally with POP and regularly deleting your mail from our server.
With the lack of sign-up requirements and the ability to use your own clients - and when combined with use of client-side encryption - I find Cock.li works well for my use case. It sells itself as a joke service, but there are a few serious-sounding domains. People complain that it goes down, but in my experience that has been a number of times I could count on my hand in the last year, for a few hours at most.
Dismail supports alternative mail clients, you may sign up with Tor without filling a Captcha, and it requires no personal information. The process of signing up requires you to respond to an automated message over XMPP, which in my experience I was waiting an hour or so.
Their terms of service do not sound ideal, and give the impression there are many ways in which you could be banned. One example is below:
sending of messages with the aim of harming or destroying, violate privacy, infringe the intellectual property, to issue statements offensive, fraudulent, obscene, racist, xenophobic, discriminatory, or any other form of content prohibited by law.
Why not Disroot/RiseUp/other privacy-respecting mail service?
As I said, I have tried many, and I found trying to apply to them impractical. RiseUp is an insider-invite-only service, and Disroot has a large list of potential offences you could fall under. Additionally, when signing up to Disroot, I was told to wait because it was the weekend. I came back during the week, and I was told to wait because it was the weekend. I try to balance maximising my privacy with ensuring actual practicality.