[tptacek]

Not that I disagree, but to inject some clarity: Python would be a perfect fit too. The major MTAs are written in C not because they need to be, but because C was the only serious option in the mid-late 1990s. Any modern language would work.

[atq2119]

If all you care about it is memory safety, sure.

If you also care about performance, I'd be skeptical of such claims.

[vidarh]

I used to run Qmail on a system that handled ~2m users. The main limitation was IO capacity. Today the M.2 NVMe SSD in my laptop can do substantially faster IO than the rack sized storage array we used for that mail system.

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.

[stevekemp]

A few years back I ran `qpsmtpd` which is a flexible mailserver written in Perl. It was extremely easy to hack upon, so you could write plugins for SMTP-time spam-detection, rejection, etc.

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:

http://smtpd.github.io/qpsmtpd/

[cryptonector]

It's not just memory-safety, but type-safety.

[pilif]

for all sites memory safety trumps performance.

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