Reflections on running my own mail server for 10 years
2023-08-09Introduction
Ten year ago I started running my own mail server. As this number invites some reflection, this post contains some thoughts on that matter.Why I started running my own mail server
On August 8, 2013 I lost access to my private email account that I used for almost all online activities. I unknowingly happened to share the same email provider as Edward Snowden: Lavabit. The US government was forcing Lavabit to hand over encryption keys in order to get information on Snowden. Ladar Levison, the owner, did not comply with the request and instead decided to shut the service down. Despite the inconvenience for me (and others), I consider this the right decision. I sometimes wondered whether Lavabit was actually a honeypod, but this pretty much made it clear that it wasn't.The following day, I registered this domain and started setting up my own email server. I no longer wanted to be dependent on free mail providers, especially not under US jurisdiction. I wanted to see what it's like, to see whether it really is that hard as many people say and ultimately, wanted some sense of control.
Setup: Hardware and Software
I took a cheap VPS provider, began renting a VM for < 5 €/month and installed Debian on it. The software stack is pretty much what is considered more or less standard these days: postfix handles SMTP, Dovecot deals with IMAP. Accounts are handled as UNIX users, nothing fancy there. A backup MX running opensmtpd was also involved for a while. opendkim is handling DKIM.There is only a single user: me. This allows me to keep dovecot's IMAP ports unexposed. It only listens on localhost, clients connect to it over an SSH tunnel. This reduces potential attack vectors. As a bonus, you don't have to worry about the validity of IMAP SSL certs as the SSH tunnel secures the connection.
Overall, it can be said the initial setup remained largely untouched in the last 10 years. I only performed minor modifications to fight spam or to add some new aliases.
Context
The role of my own mail server is 99.9% simply receiving mails. It's handling my "online life", things like:- Registration mails when I create an account somewhere
- Monitoring/Notification mails
- Newsletters
- Anything involving open source projects: Mailing lists, github interactions etc.
For more important matters (things that involve money, job applications...), I don't rely on my own. I then simply use a paid professional email service on another domain. There two reasons for that:
(1) The risk of getting filtered. Will your mail actually get delivered? Large (big tech) mail providers do a lot to fight spam, so a small, low-volume independent mail server might get caught in the net. Even if you do everything right by setting up SPF, DKIM, etc., you can still lose. A "bad neighbour" using the same hoster as you may be a spammer, and whole IP blocks may end up on blacklists. Unfortunately, you therefore can't know whether your mails got delivered, flagged or silently dropped.
(2) It's running on a low-budget machine. This has implications on availability
For these reasons, but especially not wanting to deal with (1), I am not 100% committed to my own mail server (yet). This a pragmatic decision given the circumstances. At some point I might instead switch to a trusted relay for outgoing mails, but so far the current approach has worked out quite well.
Why not use the "important mail server" for everything?
However, if my important stuff gets handled by a service I pay for... why not use that one also for everything and spare myself the trouble of running my own?(1) Dedicated mailboxes
I am subscribed to many mailing lists. Mailing lists are handled by dedicated users/INBOXes. I prefer this over using subfolders. At some point, I'd have to pay extra for this kind of setup on most mail providers.
(2) Full control over spam filters
As you have full control over the spam filters in place, you won't have emails getting filtered out. You also won't have any weird delays when receiving emails that can be caused by methods such as graylisting.
(3) Notification system
It enables a fairly straightforward way of sending mails on Unix systems by piping into mail:
echo "something" | ssh host "mail -s 'Subject' alias@yourdomain.tld"
(4) GPG encryption for all incoming mails
Initially, I created a setup where every incoming mail was being encrypted by my own GPG public key. The script was utilizing postfix content filters. A plugin for my mail client was decrypting GPG encrypted mails automatically.
I no longer use this since it makes searching more complicated and overall email is not known to offer the most private means of communication anyway. If senders want security, they can PGP encrypt the mail on their end. I came to the conclusion that encrypting mails on rest this way was a nice gimmick, but not worth it to me in the end. But it demonstrates the flexibility that an own mail server offers.
(5) Misc
There a few more things that come to mind where an own mail server shines. Outgoing header checks, allowing you to filter e. g. "User-Agent" strings sent by your MUA so recipients don't learn things about your what client (and OS) you use. If you are a fan of CLI mail clients, you can set it up your server and access the same setup from any machine. Lastly, git send-email does not need any complex config if you just run it on your own server.
Backup MX: Not worth it
As mentioned above, a cheap VM may not always be the most reliable. Indeed, nobody should expect the best uptime or most stable network. I don't consider a potential, short downtime a huge issue though (as long as they don't happen regularly). For one, mail servers will retry for a while when a delivery doesn't succeed. Secondly, you can setup a backup MX. Initially, that's what I did. It gave me an excuse to play around with opensmtpd and it felt more right having a backup MX. However, they tend to complicate the setup. You'll have to duplicate spam filters on both machines, otherwise IP-based filtering gets more complicated. Ideally, you'll also set it up in such a way that TLS certs between your backup and main MX will be verified or pinned. At some point I gave up in this. The benefit wasn't worth it. opensmtpd was also fairly new back then and still maturing, which occasionally lead to some (minor) issues.These days I am relying on Hetzner which offers stable VMs while still costing me less than < 5€ a month. I never noticed a downtime for ~4 years (since I migrated there). Therefore, I have gotten rid of the backup MX and so far have no regretted this decision.
Spam: Not a problem
To this day, I do not have any dedicated spam filter in place. Though many tutorials tell you how to setup things like spamassasin, implying it is required, I find it redundant. I don't even use graylisting. The amount of spam I receive is negligible. Most spam can be avoided by using different aliases when signing up for things. The rest can be handled with simple rules.Examples:
An ebook shop was sending me newsletters (I don't remember subscribing to). The mails did not have an unsubscribe button. I simply disabled that alias.
An alias I used to register for an online service started receiving spam one day. So I deactivated this particular alias. A few week later I learned from the press that the service actually got hacked and the database stolen...
Of course, some aliases cannot be disabled. Luckily, spammers weren't always very smart about this. The subject line in spam mails was always similar, making it trivial to filter them out using a regex. Or they used the same fake FROM address.
At one point, I used a RBL blacklist for a while for a few particular aliases. I wasn't particularly happy about this dependence, but it got the job done without requiring complex Spam filtering solutions.
Overall, while it might have largely been luck, spam was never a noteworthy problem. It was mildly annoying dealing with it when it was happening, but as we are looking back a decade, it overall wasn't a big deal.
Abuse mail
The most annoying part was dealing with an abuse mail. I've migrated the backup MX to another hoster and cancelled my old contract. At some point, the IP that was originally assigned to my backup MX was reassigned to another customer. Then somebody started using that IP for attacks. However, it seems the PTR record was still pointing to the subdomain of the backup MX. Instead of contacting the actual owner of the IP, the attacked hoster contacted me, probably due to the PTR record (not exactly a very competent move). Anyway, this was the closest thing to a "situation" involving my setup, but ultimately wasn't a big deal and got resolved with an email.
Closing remarks
So, what's the takeaway here? The experience was rather uneventful, as it should be. Postfix and dovecot are rock-solid. Many upgrades went by smoothly without me having to adjust any configs. I only remember a single upgrade where it was required for dovecot. Incoming spam isn't a problem for me despite having no dedicated solution in place for this.While it's not something you should do without any sysadmin experience, I don't buy into the myth that running your own mail server is "hard". Most of this probably comes from sendmail's reputation. Of course, the initial setup is "hard" in the sense that it takes some reading and time to set things up. It took me some hours over a couple of days. Since then it has been low maintenance work. For a server with only a few users, the "hard" part is outgoing mail, ensuring your mails get delivered by keeping your server out of blacklists. I did what I can here (SPF, DKIM, DMARC...), but as other people's spam filters are outside my control, I simply use a paid service on another domain for important things where delivery must be "guaranteed". The main reason for that is that providers such as Gmail are known to sometimes block servers without any clear explanation or discernible pattern, even if you did everything right. Begging them to unblock you is too time-consuming and nerve-wrecking.
Overall, moving away from free mail towards the setup described above was the right decision. The benefits in flexibility outweigh the setup/maintenance costs.
Update This section was clarified post initial publication. Previous revision here
For comments/remarks: Contact me