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.
Sorry, we think it's rested plenty long enough :-)
You've given some excellent examples of how qmail got this way, and what notqmail needs to change to be viable. I have my own running-in-production solutions to most of them -- for instance, https://schmonz.com/qmail/rejectutils for SMTP recipient rejection and https://schmonz.com/qmail/acceptutils for user-facing AUTH and TLS.
These may or may not become part of notqmail. But we believe that together we can carefully and safely evolve notqmail to meet modern needs.
Yep, after reading the post I'm not any less impressed by (or interested in) Rust. If the post's claim were "Wait until Rust changes more slowly before investing more heavily in it," I might be able to agree.
For a project like notqmail, I would worry about portability. qmail runs on a lot of platforms and getting Rust bootstrapped is a bear.
For the moment, we're targeting sysadmins who already run qmail (or netqmail). Much later, when we begin to approach feature parity with Postfix, notqmail might start being an interesting alternative. We hope that time will come. If you can't figure out why you'd run it right now, you're probably right :-)
It will be a lot of work, no question about that. Fortunately none of it will be about Maildir, as folks like you have long since ironed out all those issues (thanks!).
It's possible to package qmail in such a way that it's trivial to install and run, supporting many modern features by default. I've done it. Here's a demo: https://youtu.be/Vq6vu9T3vow
But that required a lot of decision-making and a lot of effort by the packager. With notqmail, we hope to make packaging much much easier.
Yes, and while I haven't run s/qmail myself, I have sometimes borrowed (and then usually refactored) some of his code, and have frequently collaborated with him on improving ucspi-tcp6, ucspi-ssl, etc. I'm still hoping he'll consider participating in notqmail development.
People can put whatever they want in their own .qmail files. That doesn't affect anything unless qmail believes those .qmail files are relevant to what it's delivering. A user controls .qmail files for a domain if and only if an admin has configured qmail to delegate that domain to that user.
Yes, for a long time it's been the case that to run qmail you have to really really want to run qmail. That's why I put so much effort for so many years into cross-platform packages of qmail in pkgsrc, and that's why we have "Meeting all common needs with OS-provided packages" as an explicit goal for the notqmail project.
They can’t, unless qmail has been configured to know they control mail for domain.tld. The admin configuration mechanism for this (control/virtualdomains) is simple and powerful.
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. :-)
Extensibility is [an explicit goal](https://github.com/notqmail/notqmail/wiki#goals), for reasons such as these. If we introduce some more small interfaces -- 1998 qmail was already ripe with examples -- we'll make it easy for anyone to program extensions. If we make it easy for folks to program extensions, we may find there lots of common extensions available. That's the hope, anyway :-)
"This implementation" is notqmail, which none of the netqmail people are involved in.
netqmail 1.06, which none of us notqmail people were involved in, was produced by a handful of people I have often referred to as "list elders". They were very informed, very conservative, and very careful.
Nothing wrong with heuristics. It's a busy world out there. I appreciate that you're aware you're using one here, and I thought you might like to know it's led you astray. As a notqmail developer, I hope we live up to the standards set by the netqmail folks.
Writing Ikiwiki plugins is often very easy, because triggers for most events you'd want to get involved in are available, and because much of Ikiwiki's own functionality is implemented as plugins. Reading and understanding internals, as you point out, can be challenging.
Tricky and/or important bits of functionality are often covered by automated tests (and I've test-driven new functionality in: http://www.schmonz.com/2013/08/22/tdd-by-example-an-ikiwiki-...). A sufficiently motivated person could incrementally test-protect more of the internals and refactor under test. I hope to have more time for this soon.
It represents cumulative improvements to the operating system since NetBSD 9.x was originally branched in 2019.