33 karma · joined January 24, 2020
maddy implements de-facto standard milter protocol so it is possible to use any third-party filtering software supporting it.
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.
I guess that needs to be in FAQ...
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 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).
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/
P.S. As far as I am aware, redis is optional for rspamd. I certainly run it for @hexanet.dev email without having redis installed.
This page shows how to configure maddy to only handle SMTP: https://foxcpp.dev/maddy/tutorials/smtp-only/ You can follow it but swap Dovecot for another maddy instance, configured as shown here: https://foxcpp.dev/maddy/tutorials/imap-only/
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.
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.
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.
(Probably i should put a better wording on https://foxcpp.dev/maddy/faq/)
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.