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.
