How to Run Your Own Mail Server (2017)

I'm in the same boat - been running my own mail since the 90s. I could understand complaints about lots of weird hoops to jump through to get mail from your server accepted elsewhere - that has become harder over time[1] - but there's a very short list of things that need to be done to avoid being hijacked.

Mail server setup for the uninitiated does look a little daunting, especially if you're more accustomed to "all-in-one"-ish software. If you want to do this, I recommend starting with making sure you have a clear mental model of mail server architecture, especially where it touches other things (DNS, DKIM, spam filters, local delivery, probably IMAP, maybe LDAP, maybe databases, etc.) Without a clear idea of the dataflow and reasons for different decision-points, you're going to have a very bad time troubleshooting things.

[1] SBCGlobal.net has been rejecting me for over a decade despite there being zero spam ever having been emitted by my domain. Eh, my userbase communicates with exactly one SBC user; ATT can bite me.

One thing I'd like to see covered is sender dependent outgoing mail routing.

For example, suppose I have things set up so all outgoing mail from my home goes through my SMTP server. If I send an email with a from address of tzs@mydomain, then the setup in the article is perfect.

Suppose, though, I send an email from home with my from address set to tzs@employer, where "employer" is my employer's domain? Assume this email is not to an @employer address [1]. With the setup in the article (and in almost every other similar setup I've seen covered in similar articles) this might run into spam filter issues unless I've convinced my employer to add my SMTP server to their SPF record.

The way I want this to be handled is for my SMTP server to see that the mail is from an @employer address, and instead of trying to deliver it directly, relay it through employer's SMTP server.

This is similar to the common "smart host" configuration often used when you run an SMTP server at home, but want it to send all outgoing mail through your ISP's SMTP server instead of trying direct delivery. Essentially what I want is a conditional smart host based on the from address.

Postfix supports this. In fact, it seems to support it in a couple different ways. I played with it a bit but could not quite get it working.

What I'm doing for now, until I find out how to do it right, is only send work email outside of work from my desktop Mac. I took tzs@employer off the list of mail aliases for my mydomain mail account, and created a second account in Apple Mail for @employer. I set the incoming mail server to POP3 on 127.0.0.1 so that it would fail, and set the outgoing server to smtp.employer. It complained for a while that it could not contact the POP3 server, but eventually stopped complaining, and the address in the configuration dialog changed to 0.0.0.0.

With that setup Apple Mail sends mail from @employer directly to my employer's SMTP.

Sometime recently, after an OS update, that stopped working. It would no longer let me enable an account unless it could successfully talk to the incoming mail server for that account.

I did find an ugly workaround for that. I gave it the correct address for employer's POP3 server, and the correct password. Once it was happy, I went to Keychain Access, found the saved password for the POP3 server, and changed it in Keychain Access to something incorrect. Mail then complains that it cannot login to the POP3 server, but that does not cause it to disable the account. Net effect: a send only account in Apple Mail. (It is important to do the password change in Keychain Access, not in Mail, because Mail won't save the change until it sees the new password work).

(If that had not worked, I probably would have written a dummy POP3 server that always reports no mail and used that).

[1] This happens reasonably often for me, because I have my mail server set up to use fetchmail to fetch my incoming work email and deliver it via procmail. Same for any other SMTP accounts I have. That way I only have to configure mail clients to work with mail server and I get access to all my mail from all of my non-web email accounts.

To be fair I've been running my infrastructure for years and it's usually fine.

The problem I have is that it's a pain in the ass to setup correctly and when things do go wrong it's really hard to figure out what's going on.

> Can you explain what you mean by attacks and exploits from spammers?

I haven't encountered a remote exploit (yet) but yes: accidentally running an open relay, backscattering, etc. You also have to worry about the system security of the box you're running it all on but let's treat that as a separate concern.

I'd been running my setup for years and as recently as August of last year I was dealing with an outage of my email server. I must've missed something somewhere because someone had figured it out and started using my server as a relay. It took me a few days to figure it out and I'm still not sure what the problem was or how I fixed it. Though my server stopped bouncing emails and started forwarding things again so... win?

As I was fixing this issue, not the first time, it occurred to me that it was just criminally easy to not know if your system is being exploited as a relay or not. There are a bunch of different configuration files in all different formats and guides that require working through dozens of steps. It's way too easy to get something wrong.

For someone like me who works at deploying software running on hundreds of nodes it seems manageable but I don't think it's ready for my cousin who's good with computers.

That's where the idea for a secure-by-default MTA that couldn't possibly be configured to be an open relay came from. Minimize the configuration so it was hard to get wrong even at the expense of flexibility.

I dunno, maybe it's not a great idea. But it's fun to hack on in the evenings when I've got nothing better to do and hopefully I'll have a fewer text files to manage in the future.

See, for me running my own mailserver removes one of the biggest weaknesses with third party mail servers: the helpdesk. How many mail exploits are simple social engineering attacks against the service provider? Probably more than half.

Of course I still have to worry about attacks at my domain provider level, but at least it removes one weak point. I'm waiting for the day that someone pretended to be me calls me to get me to reset my mail account password.

On the plus side, do you really want to communicate with anyone who uses a SBCGlobal email address?