schmonz

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.

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

I haven't experienced a need for more granular restrictions. Can you give an example of a problem it would solve?

You wanna write a new MTA from scratch? Me neither :-p

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

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.

Thank you!

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.

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

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

Yes, exactly right. One other PR left to merge, then we'll update the docs and cut 1.07.

"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.

I recently spent 4.5 years at a big bank developing identity-management tools. They were written in Perl. The first thing I did was screw up in production: http://www.schmonz.com/2014/06/01/tdd-in-context-1-keeping-m...

So I started carefully making the code testable, then gradually adding tests and refactoring under them, and gradually adopting and taking advantage of Moose, shipping every month all the while. There was never a second screwup.

(Will big banks keep choosing Perl for new projects? Yes, for a long time. It's firmly entrenched. It didn't win, but it'll probably never lose either.)

Would I choose Perl for a new project? That depends. For programmers with taste, discernment, and discipline, Perl-the-language + Perl-the-CPAN can be incredibly and sustainably productive. For other programmers, it's enough rope to quickly cut off bloodflow to your foot, which you can then use Perl to amputate.

In other words, Perl is at the high end of the risk/reward curve. If I could mitigate the risk -- say, by convincing myself that I'll always be in a position to hire great programmers or nobody -- then I'd absolutely want the reward of developing a new system in Perl.

Sure, pkgsrc has made it easy to manage third-party software on Mac OS X for over a decade. Lots of other platforms too, with root or without. Homebrew is cool, but I'm pretty happy about being able to use the same package manager everywhere I go.

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't encounter those costs. But they do exist.

Upstream developers don't know best, either. Packagers sometimes make bad decisions, just like upstream does, because we're all people. "Install our software the way we think you should" is a point of view, but not a very smart one unless it's accompanied by a willingness to be persuaded otherwise. This particular upstream developer clearly hasn't seen an OS-agnostic cross-platform package manager like pkgsrc, where one of the packager's tasks is often to make software more portable than upstream cares to bother with. To take one obvious example, we make sure libtool works on all our supported platforms, and then we make sure software with its own precious all-the-world's-a-Linux way of linking shlibs uses libtool instead. Do we try to feed back our portability fixes upstream? Of course. Does upstream always want them? Of course not. Are they wrong to not care? We sometimes think so. Are we wrong to patch their code? They sometimes think so. They have their goals, we have ours. If anyone reliably knows best about anything, it's users.