You’re right, that’s why we’re here: thanks to DJB, the code has properties that are worth preserving.

Like @alynpost says, none of us can do what DJB did. One mitigating factor here is, we’re not trying to do what DJB did. He had to write qmail from scratch; we have the advantage of existing designs, interfaces, implementations, and decades of running in production.

Other mitigations, as @alynpost also says, include modern development techniques and tooling.

The biggest mitigations we have, in my opinion, are:

1. Working in public
2. Shipping frequent small releases

“Working in public” means we’re thinking out loud, showing our work, reacting to reviewer feedback, and making our decision-making process as explicit as possible.

“Shipping frequent small releases” means

• Our previous release will always have been fairly recent, so we’ll remember how to do it carefully
• Our next release is always fairly soon, so we’ll design and review a little extra carefully
• Any given release contains relatively few changes, so our users can probably vet them a little extra carefully

None of us can hold in mind all simultaneous details the way it seems DJB must have. As a community, though, we might manage to make very few terrible mistakes that survive for long.

In the early part of the project here, we’ve been making correctness fixes to the existing codebase: adding missing dependencies to make targets, header files to compilation units, and parameters to functions. Each of these was found by us variously and independently doing code modernization (from K&R to C89/C90) or by using tools, warnings, or errors that haven’t previously been applied to this codebase.

djb is, as you say, a security genius. Unparalleled–I do not think this or any team will meet or exceed that standard working in the same manner he did. The codebase is coming on 20 years old, however, and includes features that never saw wide deployment (QMQP, the quick mail queuing protocol), behaviors that are archaic (redeclaring system functions, including build-time detection of type sizes like gid_t), and expensive design decisions (build host/build time requirement for qmail system account uid/gid to match deployment environment) that can all be improved in light of the intervening years. We’ve even got djb’s own reflection on the same, Some thoughts on security after ten years of qmail 1.0.

SQLite is an outstanding example of what a modern C codebase can accomplish. Regression testing, code coverage, undefined behavior checking, and other off-the-shelf tooling can catch mistakes that a genius wouldn’t make. The security design of qmail is as good as it was when first published. We’ll continue to benefit from that while making qmail applicable to serving email on the modern Internet.

Another defining point of qmail is that the author won’t accept patches. Obviously this is a reaction to that.

@alynpost @schmonz @josuah @gerikson

A few more Lobsters working on it increases the potential a bit. Excellent answers, too, both to my questions and the others. This looks promising. I hope you get the extra contributors once they see it’s something you’re committed to. Although yall might have read it, I’ll throw in the security strategy (pdf) of Qmail in case anyone interested in contributing is wondering what some of the comments are talking about.

Dan Bernstein does carefully designed and simple interfaces that can be implemented on today’s and tomorrow’s POSIX systems.

It is possible to follow the same design patterns, avoiding to be cleverer than needed, which would probably end in obfuscated, bug-prone code.

For instance, Qmail lacks built-in TLS support.

Some patches added TLS support through linking to Open/Libressl. Instead, notqmail uses ucspi client to implement TLS in a separate address space by an independent program. – from wiki

Likewise, early DJB code does not looks like the most recent, such as for the substdio_*() functions that he later replaced by the buffer_*() library.

There is a sense in which qmail is not dead–I have for years run a private fork for my own mail system. I am not alone in doing so, there are other extant qmail deployments. In the time I’ve run qmail I’ve also provided support in #qmail on Freenode. It’s a sleepy channel, but we get problem reports from folk regarding their mail systems and help fix them.

For years prior to running qmail I studied it. It is a pleasurable codebase to read and work on, despite being idiosyncratic. It’s design has influenced a lot of my stack, particularly the use of exec-chaining and program composition. I’m familiar with it, find I can reason about it’s behavior, and I have so far solved every problem with it I’ve been presented with.

That said, maintaining a private fork is a burden and I would like to publish my work. The process of doing so has and will continue to improve my own contributions to qmail, and I hope to continue seeing and benefiting from others doing the same–there is a lot of catching up to do, and qmail has at times been it’s own worst enemy.

It is nevertheless approachable, debuggable, extensible, and reliable. We like working on it, and I would like to see qmail in toto a living project.

Better and worst are sure affected by opinion and general vision on computing on each an any.

Qmail advantages are just this: another take on a mailer daemon, with multiple independent binaries acting together achieving the complex task of “email”.

• There are qmail-smtpd that listen from the network and write to the mail queue. These are independent of the transport: they work with TCP, with TLS, with SSH (if you want to submit from a laptop to your mail server for instance).
• There is qmail-send, that watches the queue and send the email at the appropriate places.
• There is qmail-local that puts mail to local maildirs.
• There is qmail-remote that submits mail.

Each task is handled by plugging another program, so you do not have any dynamic modules (plugin.so) and do not need to debate with the author or change the existing code to add a feature. That is probably why qmail is said to “age well”. This along with very few bugs in the code base.

Thanks for the reminder to explicitly include SMTP recipient validation in our list of planned features; I’ve added it. On the release roadmap, you’ll see “extension API for qmail-smtpd” (qmail-spp) slated for a few releases from now. The SMTP recipient-validation programs in my rejectutils run under qmail-spp (or the RCPTCHECK patch) in any combination and order configured by the sysadmin. Needless to say, I plan to submit rejectutils for inclusion in notqmail. :-)

That behavior, when abused, is called backscatter. It is a frustrating problem in qmail, both because the software is fatally susceptible to it out of the box and because correcting the problem grates against qmail’s design. Specifically, you need to know in your SMTP session whether the mailbox you are accepting delivery for exists, and qmail-smtpd is not only not designed to know that, it may be running on a different host that the user account with the mailbox, or your system may be using any number of mechanisms (Unix users, the qmail-users mechanism, the plethora of routing and delivery methods including virtualdomains) that need to essentially be pulled forward in to qmail-smtpd–in the worst case bringing your entire system with it.

One example of how this is solved today is Erwin Hoffmann’s recipient extension. With stock qmail you can use a default rule to deliver mail to /dev/null and fail to generate any bounces–itself certainly unsatisfying but no worse than the disease.

I cannot say in what manner notqmail will resolve this issue–only that we’ll do so consistent with qmail’s other features or with extensions that integrate well with each other.

Runtime-configurable SMTP recipient validation will likely be in the next release, reusing existing code as mentioned in my previous comment.

Are you in touch with the netqmail people? The correctness fixes seem to be in line with the goals of that project.

I’ve always envisioned providing enough interfaces such that DKIM could be implemented as Unix filters. I believe this is exactly how mbhangui implemented DKIM in his IndiMail fork. When the time comes, that’s probably how we’ll go about it in notqmail.