[schmonz]

Hey dude! Been a little while. Hope you’re well.

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. :-)

[cryptonector]

Hey! I'd not noticed you were involved. EDIT: Where are my manners. Hope you're well too!

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

There's more stuff too (delivery options, filtering, ...), but protocol-wise, the above are critical.

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.

[schmonz]

Vanilla qmail was never an open relay unless you really intended to configure it as one. It's just that the only relay controls were IP-based. Back in the day, before AUTH was widely supported, I used a really nice "relay-ctrl" add-on from Bruce Guenter for POP-before-SMTP.

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.

[schmonz]

P.S. On the acceptutils page, check out the POP3 hole I found :-)

[xvilka]

Yes, Rust is a perfect fit for such a project.

[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

[gypsyharlot]

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...