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).
The web's answers for a suitable antonym seem inappropriate [0] (all referring to "small" rather than "many parts". I reckon megalithic is the way to go.
Although I've been hosting my own mail server (postfix/dovecot) for years I must admit that I treat most of its parts as a single black box. My head just doesn't grok the entirety of processes and the various sub components (spam, grey listing, filters).
I prefer monolithic every day. It's not hard to provide plugins that allow custom filtering/ spam etc, so the end result can easily be the same.
Especially for personal /small business servers, simplicity wins everytime IMHO.
Mono - one, lithic - stone. "One stone". It's in the name, right?
So it's not a monolith, it's a composite. If that makes sense.
Sure, the components of postfix are not standalone tools, they are very much like systemd. One codebase (monorepo, yaay, old is new), sharing a lot of common internal code.
In the end multi-process composite (like oracle and postgresql RDBMSes) or a multi-threaded monolith (like MySQL or anything that runs on a JVM) is not that big of a difference nowadays. Both can be performant, both can be maintained well/efficiently by big teams and by a one-man-army (see how postfix is mostly maintained by Wietse Venema).
Project site says "all-in-one" (one daemon) to replace postfix, etc. Like sendmail?
Please say more.
For 20+ plus years I've been advocating for postfix instead of sendmail style architectures.
I don't know what to call the "one task, one process" style of postfix. What's the opposite of monolithic?
This tension is replaying (again) in the web services vs monolithic architecture debate.
Ironically, I prefer monolithic web apps over web services based designs. Contradicting myself.
I'd like to better understand when each style is better suited to the task at hand.