Don't Run Your Own Email

Running your own email is generally a terrible idea. The work and maintenence required is much larger than it seems like it should be, and it's neverending.

Here's what you'll be dealing with:

• setting up the actual MTA (Message Transport Agent, like postfix)
• setting up the LDA (Local Delivery Agent, like dovecot)
• yes exim does both, no you should not use it (holy CVEs, batman)
• dkim signing so other people know your mail is actually from your MTA
• dkim in dns to make that work
• dkim validation for incoming mail
• dmarc validation for incoming mail
• dmarc in dns so other MTAs accept your mail and know how to use spf/dkim and (sometimes) tell you when you broke something
• spf in dns so others know what servers can send mail as you
• spf validation for incoming mail
• PTR records in DNS for IPv4 and IPv6
• spamassassin reading the headers added by the above validation stuff and doing spam filtering
• spamassassin setup and tuning, and that is an entire separate box of worms that is neverending
• sieve for server-side filtering
• certbot for certs, and a post-renew hook to reload your MTA and LDA
• blocklist hunting so your mail actually gets delivered (also neverending)
• submitting blocklist removal requests (pain in the ass)
• set up a bunch of trusted-sender programs so major providers accept your mail
• set up a bunch of junk reporting and reputation programs so you can see why they're still rejecting it (e.g. MS' JMRP and SNDS)
• convince your host to unblock outbound tcp/25
• set up monitoring to lessen the chances of "wait... why haven't I gotten any replies for two weeks"
• probably clamav for AV
• and you better make sure that's auto-updating
• oh, now it's preventing²⁰¹⁰ me from receiving any mail
• and on second thought, should I even bother with clamav?
• local recursive dns resolver, so that your DNSBLs actually work, since they block all the public recursive resolvers
• did I mention spamassassin tuning
• a sql server for virtual aliases/domains/etc
• actually configuring everything for virtual aliases/domains/etc
• realizing all the documentation is outdated and you need to rebuild everything
• more spamassassin tuning, setting up rule weights, configuring bayesian learning in a cron job
• don't forget to test all of this because you *will* break something and not realize until you've missed two days of mail, or your resumés haven't been getting to inboxes
• configure your ciphers, modern and secure but not *too* modern and secure or stuff will give up or fall back to plaintext, since all those idiots running their own mailservers are probably running openssl 1.4 w/ SSLv2
• go update your stuff regularly and check for new best practices and re-test everything
• more monitoring, after updating and finding out that postfix is accepting TCP connections but not mail
• oh look now STARTTLS on 25/587 are preferred over sslwrap on 465, but maybe you should still offer it because of the aforementioned neglected mailservers of inept or inattentive penny-pinchers
• oh, and SPF RRtype is deprecated for TXT SPF records, but maybe you should still run both of these too, because yeah
• wait what's this about DANE TLSA? does that work for SMTP?
• oh, now there's mta-sts, so I need a webserver to serve that
• and thunderbird/k-9/etc try to autodetect settings, take forever, then fail? how do I set that up?
• *sigh* and outlook uses a different autodiscover system
• wait, why am I getting spam in my inbox with no X-Spam-* headers?

  spamc: skipped message, greater than max message size (512000 bytes)

  oh, by default spamassassin doesn't scan messages >512kb, cool
• and there's now a sts preload list for this? *sigh*. let's see how this goes, considering the above TLS concerns
• dnssec? what's the status of that, would it tangibly increase my security?
• what's this "return path" thing?
• and this is on top of all the normal work of administering a server and keeping it up to date and secure
• oh, I can reduce spam by blocking mail from @mydomain coming from other hosts! wait, that breaks all of the whitelabeled services
• found a cheaper VPS host or need a beefier machine? time to start over on your IP reputation cleaning work!
• and I'm certainly forgetting more...

In summary: do not run your own email.

"But you're just some dog on the internet!" Okay, here is Eva Galpern, the director of cybersecurity for the Electronic Frontier Foundation, and Matt Blaze, a professor of computer science at Georgetown.

Truly, it's like cryptography. "Don't roll your own crypto", and don't run your own email*
* Absolutely do your own email/crypto - in a lab. Do not rely on it until it's been reviewed by competent folks, running well for some amount of time, you've got monitoring, etc.

What should you do instead?

Pay someone with people who can give it their undivided attention. Prices below are for the cheapest plan with a custom domain, and unless noted are per-user per-month as paid annually. These aren't endorsements, just research notes.

• Microsoft 365, $4 for 50GB
  • Trump regime data sovereignty concerns: Microsoft blocks the account of the chief prosecutor of the International Criminal Court ( AP, heise )
• Google Workspace, $7 for 30GB
  • Some google services aren't available to gwork accounts
• Migadu, $19/yr for soft caps of 200 emails/day in, 20/day out, 5GB
• Purelymail, $10/yr for a soft cap of ~20GB
• Infomaniak, free for 1 user with 15GB, or ~$1.50 for unlimited
  • Bad takes on anonymity
• Fastmail, $5 for 60GB
  • Possible union-busting behavior - reddit
• Mailbox.org, ~$3 for 10GB
• MXroute, $50/yr for 10GB
• or many others!