schmonz
Joined 13 years ago
Karma
100
Submissions
29
Member since
Jun 9
Recent submissions
Comment · 2 years ago
The NetBSD Project is pleased to announce NetBSD 10.0, the eighteenth major release of the NetBSD operating system.
It represents cumulative improvements to the operating system since NetBSD 9.x was originally branched in 2019.
Comment · 6 years ago
We’ve released notqmail 1.08, addressing these vulnerabilities (among other things). HN discussion thread for the 1.08 release: https://news.ycombinator.com/item?id=23252421
Comment · 7 years ago
I haven't experienced a need for more granular restrictions. Can you give an example of a problem it would solve?
Comment · 7 years ago
You wanna write a new MTA from scratch? Me neither :-p
Comment · 7 years ago
P.S. On the acceptutils page, check out the POP3 hole I found :-)
Comment · 7 years ago
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.
Comment · 7 years ago
Thank you!
Comment · 7 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
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 :-)
Comment · 7 years ago
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.
[ my public key: https://keybase.io/schmonz; my proof: https://keybase.io/schmonz/sigs/UZlFbgoFkn_Famx1wCU1xLncjAzbrrKrzIt_GtOEMNU ]
aspe:keyoxide.org:PAC6KHICU3QSHQZVPJCZFS7KIA