Spam, phishing, virus blocking - no builtin measures. It is easy to integrate rspamd (literally adding one line into config). ClamAV can be used via clamav-milter though some configuration is needed - no direct & easy integration for now.
maddy implements de-facto standard milter protocol so it is possible to use any third-party filtering software supporting it.
IMAP4rev1 is fully and almost [1] correctly implemented.
There are some useful protocol extensions supported but some other important ones are missing (e.g. CONDSTORE).
There are no known issues with popular clients but performance may be a bit rough. Both due to missing extensions and storage implementation quality e.g. SEARCH may get slow for large inboxes.
Default configuration runs everything as a single daemon. This has been done to minimize any management overhead, avoid the complexity and performance overhead introduced by IPC.
It is definitely possible to split things apart though - this is not something of a hard design decision. This is what LMTP is for, right? maddy can work as both LMTP server and client and also supports both server and client parts of Dovecot's authentication delegation protocol.
So you can do something like that:
1. maddy instance running SMTP on port 25, running inbound filtering and then doing transparent LMTP forwarding to ...
2. maddy instance running LMTP on some unix socket, delivering to local storage and providing access to it via IMAP, authenticating users using ...
3. maddy instance running Dovecot auth's protocol on some unix socket providing authentication service using some DB.
4. maddy instance running Submission, managing queue of outbound messages, trying delivery by forwarding them to ...
5. maddy instance running LMTP on some Unix socket, actually attempting outbound delivery.
In fact, you can also put any of these on separate VMs/containers or even physical systems. And if we add some load-balancing capabilities to SMTP client then it can be used to scale message processing (though a single daemon can already handle quite a lot of emails and users without problems).
There is no IP whitelisting feature in maddy. I believe it is possible to do it using whatever off-the-shelf firewall you have on your system. Could you elaborate on the reasons it is not a viable way for you?
Currently the license is GPLv3, you can find it in the COPYING file.
There are some messy bits related to licensing because it was MIT licensed in the past (back then when I did not take this "little pet project" very seriously).
alps was created by the same person who started maddy, by the way.
It is not me. Just wanted to give a little tribute to the amazing person who put a lot of work into email libraries for Go: https://github.com/emersion/
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.
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 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.
Your suggestion is to tie everything to the ownership of alternative root KSK. Meaning that you are explicitly blocking the possibility of multiple CAs for the project.
>if you trust a third party CA they can just sign for anybody without limits
It is possible for a root certificate to have a name constraint making all certificates issued for other e.g. TLDs invalid. Like it is done in dn42 CA.