a) a docker container (or other standardized, easy to deploy technology) with a "mail server in a box implementing best practices"
b) a test for the stuff that Docker can't cover like DNS config, ideally with scripts to set it up on the most popular providers and clear copy&paste instructions for the rest.
People shouldn't need to fully understand DKIM, SPF, etc. - they should just be able to click a button, copy&paste generated DNS records, and be up and running.
Otherwise, commercial providers are just the only option that makes operational sense for most cases, _even if you know how to do it right_, because doing everything right manually step by step is still to much work to be worth it in many cases.
Agreed. A few years back when moving my personal domain from a failing provider I considered running my own email server on Digital Ocean; they had some great tutorials on setting up various parts and I followed a HN recommended tutorial. I was already happy setting up LAMP with a nginx reverse proxy, how hard could it be - I got it setup, and realised two things: Keeping everything running without getting compromised was going to take way too long compared to the benefit. Two, Google and MS wouldn't accept my email - not even to myself when I whitelisted it - it's a crap shoot.
Email has serious economies of scale and keeping such a critical system operational, on a small scale, was going to be some deal of stress.
So I just went with my hosting providers Plesk-fronted setup, which matches your para.3 description.
As mentioned in https://news.ycombinator.com/item?id=23960831 it's good for security to have SMTP server and IMAP server segregated, even separate physical machines, which you'll have a hard time doing when everything runs in the same process. What happens when maddy gets a security hole discovered.
To me maddy would feel like sleeping on live electrical wires, only they are insulated by a thin layer of paper. Hope the isolation does not get scratched anywhere while you sleep. Even a non-dockerized, traditional setup like postfix+dovecot has better isolation.
I believe a server wriiten in a memory safe language greatly reduces the risk of running such setup. To the point where it is an acceptable trade-off to get simpler maintenance.
Depending on how many targeted attacks you get in a day, you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.
> you may pull apart the monlithic server and run inbound processing, filtering, IMAP access and outbound queueing as separate processes or even on separate systems.
Can this be done without forking source code? E.g. just configuring two instances.
Thanks for the link to FAQ. Actually, simple, no bloat’ little dependency software definitely has some appeal.
This works because maddy implements both client and server
for Dovecot's SASL delegation protocol.
Alternatively you can configure pass_table to read from shared
SQL database. Hm, maddy-tables(5) man page is not rendered on
the website but you can look at sql_query module.
If I had an infinite amount if time, I would sure write maddy in Rust. But as practice shows, there are only around 24 hours in a day.
That being said, my project greatly benefits from Go concurrency features and simple I/O primitives. Also there are libraries written by emersion for nearly everything.
I think that is overkill for self hosting. Also as the author says below, Go is more memory safe than C/C++ in that there is no use after free and buffers are bounds checked.
You would not really want so many "private" ports exposed on a public facing machine.
A machine which has IMAP open tends to look like it has some good stuff.
I just forward incoming emails to an internal SMTP server which also serves as IMAP server, so MX records won't simply reveal your IMAP server as well.
This is actually how usual Postfix+Dovecot setup works in practice. Dovecot runs an LMTP server which is SMTP with some minor modificaitons. Postfix forwards messages to Dovecot's LMTP.
>People shouldn't need to fully understand DKIM, SPF, etc. - they should just be able to click a button, copy&paste generated DNS records, and be up and running.
I oppose this. People should know what they are configuring. This applies to all stuff related to mailservers.
You probably learn more by setting it up the "hard" way (without containers) so that in case of failure you at least have a little insight in how the components work.
I have my own domain, my own bind and my own mail servers. I forward all the mail to google for reading and searching and the main value I get out of it is I actually understand how DNS and SMTP work. Which comes in handy once a quarter at work. I book marked TFA because I never got the newer (!) stuff setup like proper TLS and DKIM. It is very old setup from like 2005 or so and I think is grandfathered into Gmail somehow. At least my newest domain I treated worst than my older ones.
In search of self hosting email I tried out both MailInABox and Mailcow.
MailInABox wanted to control DNS records which was a no-go. The primary driver behind the project seems to have arrogant attitude towards having users do DNS records themselves. Mailcow seemed nice but was guzzling up ram for seemingly no good reason.
Finally tried out Mailu a few days ago which seems to work nice, albeit with limited testing.
Mail in a box suggests being the DNS server in an attempt to be more user friendly, there are a lot of DNS records to setup for mail. How ever external DNS is supported (see "System status & DNS" in https://mailinabox.email/guide.html)
Automatically checks DKIM, SPF and DMARC settings for your domain, comes with docker and can be upgraded by running a single script, and has a webgui and spam protection.
a) a docker container (or other standardized, easy to deploy technology) with a "mail server in a box implementing best practices"
b) a test for the stuff that Docker can't cover like DNS config, ideally with scripts to set it up on the most popular providers and clear copy&paste instructions for the rest.
People shouldn't need to fully understand DKIM, SPF, etc. - they should just be able to click a button, copy&paste generated DNS records, and be up and running.
Otherwise, commercial providers are just the only option that makes operational sense for most cases, _even if you know how to do it right_, because doing everything right manually step by step is still to much work to be worth it in many cases.
None of this seems _hard_, it's just tedious.