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 the stuff you have to set up:

• the actual MTA
• the LDA
• 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 *tell you when you broke something* (sometimes)
• 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)
• get 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
• local recursive dns resolver, so that your dnsbls actually work, since they block all the public 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
• oh look now STARTTLS on 587 is preferred over sslwrap on 465, but you need to still run both because of aforementioned shitty neglected "I'll save money by running my own mailserver"s
• oh, and SPF RRtype is deprecated for TXT SPF records, but again you should run both, 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
• oh and there's now a sts preload list for this? cool. *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?
• and this is on top of all the normal work of administering a server and keeping it up to date and secure
• and I know I'm forgetting at least a couple things...

"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.

Honestly, 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, like o365, gsuite, etc.

Feedback - Yes the formatting is garbage I copied this from telegram I'll clean it up someday