It's also /well/ clearer as an admin than configuring Postfix, which seems to have random options which do random things in multiple logical places. From an outside perspective, Postfix is a "big ball of muck", while configuring exim involves defining logical pipelines.
I don't know anything about Exim's UX, because reading the code (something I did a decent bit of back in the day) convinced me never to use it.
But however better Exim's UX might be, it's important to understand that it's a first-generation MTA design. The second generation of MTAs happened specifically to address the security calamity that the first generation architecture caused: minimal privileges and fine-grained privilege separation, root-and-branch replacement of both standard C library functions and of standard C idioms that create memory corruption flaws, and, probably most importantly, a design that has security as an objective, informed by (well, what was in ~1996) the best understanding we had of secure programming.
The second generation was not entirely successful; in 2022 (and, for that matter, 2012), it essentially makes no sense to run a memory-unsafe MTA; memory-safe userland programs written in popular, general-purpose languages have no trouble keeping up with workloads much more stringent than SMTP.
(If you're curious, I'd say that memory-safe languages and database backends --- keeping individual messages off the filesystem --- defined the third and subsequent generations).
But Postfix and qmail were a giant step forward from Sendmail and SMail; like, there's just no comparison. So far as I can see, Exim did not take that step; it's hard to see how it could, because Exim did not start with a security-first design (you can find comp.security.unix threads from back in the day that discuss this in more detail).
Sure. But if the "second-generation MTA" is next to impossible to learn how to configure, it doesn't really matter how good it is technically - it's unuseable unless configuring mail servers is literally your job, or you're happy copy-pasting someone else's config. Perhaps, one day, the Postfix people will realise that, but they apparently don't now.
I ran into a configuration issue with exim in the last few months that prevented me from receiving some email from Amazon SES. The logged error told me at what logical step in the process it happened, and contained a user-configured error message on that specific step, which allowed me to quickly find and update it. That's something I never got from Postfix.
Postfix's configuration is a completely flat mapping on a fixed pipeline, where that pipeline is not properly exposed to the user, and the documentation is not well-ordered outside a handful of quick tutorials - postconf.5 lays out the options in alphabetical order, not according to what part of the pipeline the options affect.
Tom, what on earth is a nth generation MTA? SMTP has largely remained static as a standard (when did that EHLO thing arrive?) for decades. OK, there are a lot of add ons such as SPF, DKIM and DMARC.
I'm also not sure what UX means either in this context - its an MTA.
I'll take your comment on the quality of the code as stated - I respect your judgement on that but bear in mind that Exim is continuously developed. I lurk on their mailing lists and Jeremy and Co are continuously refining it.
It is a single binary and that single binary is written in C but whenever CVEs come up, they seem to be handled with professionalism and alacrity. So, perhaps you might like to give it another go.
It is rather powerful in what you can do with it. For example you can update exim.conf and then run exim -bhc w.x.y.z and run through a SMTP session to test it as though you are coming from the IP address w.x.y.z.
Anyway, I suspect I have way worse binaries from a purist's perspective doing stuff on my systems than Exim. However, I do know I've shifted many, many millions and perhaps billions of emails with it without any snags.
Nobody I'm aware of has formalized the "generations" of MTAs, but they clearly exist.
There may have been a generation preceding them, but SMail and Sendmail are the first generation: highly featureful, no security design (they were often designed to simply shell out to pipelines to get things done!), with C foundations written --- I know this is hard for people in 2022 to grok --- before there was any common understanding of memory safety, not even overflows, let alone memory lifecycle issues like UAF. People forget that the first published stack overflow exploit (after the idiosyncratic Morris Worm) wasn't until 1995.
The next generation --- I'll call it the "second" generation --- improved both the performance (which was abysmal) and the security of the first; security was the motivation for them. qmail and Postfix are the big two designs here, and they share a bunch of architectural features.
And, my claim is, for like the last 10-15 years, nobody sane would have implemented an MTA in a memory-unsafe language (there's just no need), nor would they have used Unix Programming 101 techniques for storing data.
The UX of an MTA refers to how it's configured. As I wrote it, I thought maybe people would get hung up on that; after all, we'd refer to the "DX" of a development platform, so maybe I want to say "AX" for "admin experience". But then I thought, nah, that's silly.
The point of modern secure software designs is not to have the CVEs in the first place. Your operating assumption needs to be that your adversary knows about the "CVE" before you do.
