I highly suggest that technical people like HN readers use the https://workaround.org/ispmail tutorials instead and set up postfix/dovecot from their OS repos. You'll learn enough on the way to fix things when they do go wrong rather than relying on some turnkey stuff who's internals are obscure and hard to fix when the inevitable problems happen.
Setting up a proper mailserver this way does take a few hours (from VPS setup to sending mail) but once it's set up it's good to go for a decade. And when the time comes to update the distro you're running it on you'll know how to port your data/config to the next VPS.
I don't agree with this take, talking as someone who has maintained their own email server in one form or another for many years. I think the separation of components in the traditional email stack is absolute bonkers and an artefact of various historical happenings, and not a technical necessity. That's why I love projects like Maddy or Mox who ship the whole stack in a single binary. Yes, you need to learn about DKIM, SPF and other high level email protocol concepts, but you shouldn't have to know how components interact between each other. So my recommendation to people is to go with projects like Maddy and Mox, and hopefully more people will host their own emails because of the lower entry barrier, so we can get some empathy from huge providers like Google and Microsoft.
It's certainly a good idea to understand how email works when you are running your own email server. I don't think setting up half a dozen services is the best way to get that knowledge though. Ideally, mox will explain some of it on its admin pages in the future. But I understand your point. Existing mail server components are long-lived, battle-tested, high-quality.
I wouldn't say internals of mox are obscure, it's all open source and relatively lean code (but clearly I'm biased). But indeed, if something goes wrong, you may not currently be able to google-search your way out of it. Mox is very young. The FAQ suggests first installing it a subdomain to gain experience, instead of switching your email over immediately.
FWIW, I implemented the mail export functionality before import functionality. You can easily get a tgz or zip with all maildirs or mbox files out of mox.
I’ve actually found that this is not the case and that while the learning is enjoyable, it’s very difficult to retain, especially if the result is a low maintenance server. A decade after I set it up, I will most certainly have forgotten how I set it up in the first place (speaking from experience).
This is generally true. Patiently documenting steps as well as logging any corrective and preventive actions (something that I learnt when studying for ISO 9001) is prudent.
I (mostly) stopped documenting in prose and used ansible instead. It's a bit more work, but it paid off numerous times since then. The prose that's still left, because it's really really to cumbersome to implement, is left in the comments of ansible files.
The main benefit of this is (a) when using a distribution like Debian, you get automatic security updates, and (b) it is virtually guaranteed to be supported for decades, and there is extensive documentation. It’s also more flexible to customize, and it integrates with other packages and features of the distribution.
From my own experience maintaining a mail server for over a decade, I do not agree with this.
The time between any tweaks needed is large enough that I completely forget how it was set up and need to relearn stuff. And it's definitely not trivial, so I can't do that in 5minutes (the way I can with acme/letsencrypt, for example).
In the same way that caddy just makes web server setup easy, it's good to have a modern setup supported out of the box for mail as well.
Setting up a proper mailserver this way does take a few hours (from VPS setup to sending mail) but once it's set up it's good to go for a decade. And when the time comes to update the distro you're running it on you'll know how to port your data/config to the next VPS.