[cubesnooper]

I run OpenSMTPD, mostly because of how simple it is to configure but also how its privilege separated design has reduced the impact of bugs when they happen. (See Qualys’s sometimes complimentary comments in their OpenSMTPD vulnerability writeups.)

It’s really important to use a distro that you understand well and are comfortable keeping secure and up to date. For me that’s OpenBSD; for you it might be something else.

For security reasons, I recommend keeping the server setups simple, minimal, and isolated as much as possible. I have three machines: the sending server, the receiving server, and the VPS.

The VPS is the only machine directly accessible from the Internet, so it is locked down as much as possible: it forwards incoming port 25 over a WireGuard tunnel to the receiving server, it forwards traffic from a second WireGuard tunnel (from the sending server) to the Internet, and that’s it. No other services, and all other incoming and outcoming ports are blocked with the firewall. The SPF settings in my DNS list only this VPS’s IP address as a trusted sender, and the MX settings point to the VPS too.

The receiving server runs on a Raspberry Pi. Since it’s almost directly accessible from the Internet over port 25, this one’s heavily locked down too. It’s firewalled from making Internet connections except those relevant to mail receipt (incoming port 25, reverse DNS lookup, DMARC lookups, etc.). It delivers to a Maildir.

The sending server is an Intel NUC actually running two VMs, only one of which is for sending. The second VM is the viewing VM. It periodically rsyncs new mails from the receiving server to a Maildir. I interface with the Maildir directly by logging in with SSH and using command-line tools like mblaze and notmuch. This machine also runs Dovecot as an IMAP server backed by the Maildir; the IMAP is used by my phone, Thunderbird, and my self-hosted webmail (Roundcube).

The other VM, the sending VM, is what I point my mail clients’ outgoing SMTP settings to. It listens for outgoing mails from my LAN (requiring TLS client certificates for authentication), and sends them to the destination server, but with the traffic routed through the VPS so it looks like they came from there rather than a residential connection.

What I described is what I ran for a while, but over time I’ve added additional complexity for the sake of higher uptime. That’s not really necessary, since downtime was already rare and SMTP handles outages of a few hours gracefully, but like the progressive steps in my previous comment, after several months I was comfortable with my setup and wanted to push it further. Now there are two VPSes from different providers (mitigating downtime at one datacenter and the risk of being tied to one VPS provider), port forwarding to two MXes on my LAN. I’m planning to get a second ISP at home, so a VPS can have an alternate path to its MX if one ISP is down.