Are there any good email servers which aren't horrible legacy messes? No UUCP support, no M4 macros, no ancient C code?
I once looked at writing an immediate email forwarder in Go, a mail forwarder for servers that don't receive mail. It would, upon receiving a message via SMTP but before replying with a status, open a connection to forward the email, and return the status of the send to the input SMTP connection. No local message storage at all. Runs in a jail. It's not hard to do this as a minimum viable product in Go. But all the anti-spam stuff you need today makes it a far larger project.
It would be interesting to write both that, and a pure SMTP to IMAP server. No local mail access, just pure IMAP. Together, the two programs add up to a mail server much simpler than most today.
Depends what you mean by "ancient C code" - if it's basically Sendmail you're complaining about (and given the m4 mention, that seems likely), then there have always been other options.
Both qmail and postfix have security models pretty similar to the ones you describe - the process that accepts the mail in either has almost no privileges. See here for how postfix does this: http://www.postfix.org/OVERVIEW.html
Yep, qmail may be old but it can do all the new tricks, and it can work like you say. https://cr.yp.to/qmail.html steep learning curve but it'll do it all and the design is great once you "get it".
Not to plug my own projects unduly, but I've grown tired of writing configuration files running to hundreds and thousands of lines and kind of snapped and implemented the basic protocols (SMTP & POP3) myself - the project is @ http://cmail.rocks/ (and https://github.com/cmail-mta/cmail).
I've since moved all my mail for the last year (for about 10 domains) via a cmail setup and so far have not had a major hickup. Sure, it may not be as full-featured as other mail servers, but thats not the mission statement ;) One of the main reasons I'll probably never go back (besides pride) is the ease of altering the runtime configuration via our admin tools (eg. adding a new domain to the mail server is one command in the simplest form).
Some of my peers who contributed code or bug reports also run instances and are very happy with the amount of configuration they need to support for cmail vs. the amount of things to do to run for example exim.
Code-wise, it's still C (because that's what I'm most comfortable with), but hopefully it doesn't read as ancient :) I've tried to keep the bulk of it understandable and modular. We extensively use static analysis (clang analyzer and Coverity Scan) as well as fuzzing with afl-fuzz as part of our testing.
IMAP is the only major protocol we do not yet support (though the groundwork is laid in another branch of the main repo), and that's mainly because the specification is a major PITA (at least compared with the relatively sanely specified SMTP and POP3). IMAP also implicitly requires multithreaded handling of connections, which so far cmail has managed to avoid, because in my experience multithreading is a) not necessary in most sane server designs and b) a major source of non-trivial bugs.
Edit: Oh, since you mention build systems - we use a simple makefile, so yeah, no m4 macros ;)
I once looked at writing an immediate email forwarder in Go, a mail forwarder for servers that don't receive mail. It would, upon receiving a message via SMTP but before replying with a status, open a connection to forward the email, and return the status of the send to the input SMTP connection. No local message storage at all. Runs in a jail. It's not hard to do this as a minimum viable product in Go. But all the anti-spam stuff you need today makes it a far larger project.
It would be interesting to write both that, and a pure SMTP to IMAP server. No local mail access, just pure IMAP. Together, the two programs add up to a mail server much simpler than most today.