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.
And your sales people will call this a misconfiguration serious enough to fire the sysadmin who did this. The problem is that, typically, nobody trains or supervises the filter applied to the outgoing mail, and nobody is warned that it did, in fact, reject an email, and there is no manual override if the filter is, in fact, wrong. And spammers (from the viewpoint of a particular organization) don't exist and can't exist inside the organization, so any rejected outgoing email is, by definition, a false positive.
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).
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/
Not sure if Maddy covers this use case specifically (I didn't see it covered in the documentation, but I figure it actually is possible).
I'm hoping to use a Golang-based application as a simple SMTP Relay, which also allows for ranges of IP addresses to be whitelisted to connect openly to it from within our campus network.
Basically, the scenario is as follows: a number of internal services are older and may not support the authenticated route so we can use Sendgrid directly and send emails securely, so instead we currently have them routed to an internal Windows server which is running an older piece of IIS functionality (it's an SMTP Server in Windows that can be turned on). That piece is configured to be open (so it can receive messages on Port 25) but is also limited to a set of IP address ranges that internal servers are using (so that it's not generally usable by just anyone inside our network) and is configured to send those received messages out using Sendgrid.
And I'll probably need to follow up with the developer again (or try and make the contribution back to the project on my own), but the main issue it had was that the IP range whitelisting wasn't available (and even whitelisting by specific IP addresses seemed problematic, so in my testing I had to keep it completely open for it to work as expected).
If Maddy can fulfill the need instead though I can give it a shot ;-).
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?
Fantastic job to both of you! Really appreciate the high quality work you folks have been doing on maddy and the email libraries. Are you guys running migadu as well? I might just switch if you are related.
As someone who uses and loves Caddy, I'm very excited about a mail server with a similar philosophy. I'm rooting for you!
That said, Caddy's killer feature for me was automatically configuring certs, that's what made me switch from Apache back when we were moving everything to HTTPS. I still don't fully understand how certs work, but fortunately I don't really need to. Until Maddy does this, it won't be a good comparison.
Also I would really appreciate some documentation for making this work with Caddy handling TLS certificates for me. I guess I'll file a bug about that.
