If we were starting from scratch, I’d be first to say let’s pick something safer than C. But we’re starting from where DJB left off, so there’s not much left to decide about language. Our roadmap aims to provide mostly Unix-process extension points such that new code can be written in any language.
Postfix is great, and I certainly hold Viktor in high regard (haven’t met Wietse). It’s just that some of us really like qmail. :-)
So, yeah, qmail is fine as a starting base, but there are important things that a modern MTA/MSA needs to have:
- MSAs need to support user authentication in
SUBMIT (no open relays)
- MTAs and MSAs need to support TLS
- MTAs should -really, need to- support DANE
for authenticating SMTP servers
I'm not sure that portability is such a problem that you can't use Rust. Rust runs on all modern OSes, which is all you need to support in a new MTA/MSA. And Rust is fairly easy to get into, actually.
For mandatory user-facing TLS and AUTH on port 587, and opportunistic server-to-server TLS on port 25, I've written https://schmonz.com/qmail/acceptutils. For SMTP recipient checks, I've written https://schmonz.com/qmail/rejectutils. It's too soon to say how notqmail will solve these problems, but they're solvable and we intend to solve them. For DANE... definitely not there yet.
If you also care about performance, I'd be skeptical of such claims.
For most sites, performance is a total non-issue for providing the feature-set that qmail provided.
And if you are a site that processes enough email for performance to start becoming an issue, you're probably better off with a custom solution that's tailored to your specific issues
These days the project is stalled, I think most of the development moved over to a nodejs based project.
Anyway the project was pretty simple to work with, and scaled wonderfully:
If you're building a competitor for Gmail or Hotmail, then maybe that performance difference will matter. For almost everyone else it's largely irrelevant.
EDIT: I'm confused by the downvotes for this. If someone has practical experience that suggests that performance is a real concern for this type of use, I'd love to hear about it. For my part I built and ran such a system for a couple of years, and spent a lot of time looking at the performance constraints. CPU usage just was not a factor even on ~20 year old (by now) hardware, running on 4-5 machines where the beefiest one had either 2 or 4 cores. All our optimization efforts consistently went on trading increased CPU usage for reducing IO use, because that is where the bottlenecks were. That's been reinforced with other mail systems I've run over the years, including large scale mail processing with PHP (not my choice) - every such system I've seen have been IO constrained rather than CPU constrained.