1. 32
What is notqmail?

It’s not qmail and it’s not netqmail.

notqmail is a community-driven fork of qmail, the well-known Unix mail transfer agent (MTA). notqmail begins where netqmail left off: we will provide stable, compatible, small releases that do not conflict with or break your local site customization or the other software you run in your mail system. notqmail also aims higher: we are developing a qmail-derived system that is extensible, easily packaged, and increasingly applicable to a wide variety of modern needs.

the wiki

    1. 10

      The defining point of qmail was that it’s a secure mailer written by a security genius. What security-enhancing practices or tools will this project use to maintain that?

      1. 12

        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.

        1. 2

          Thank you for this question, @nickpsecurity. It’s a very important one, and now we’re giving a more thorough answer: https://github.com/notqmail/notqmail/wiki#why-should-i-trust-notqmail

      2. 8

        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.

        1. 3

          SQLite is an outstanding example of what a modern C codebase can accomplish.

          I’m actually curious about this one. In another thread, I said we shouldn’t use as examples codebases from unbelievably-good programmers since they’re probably not representative of what most people will do in the language. SQLite is incredible in its QA. What I want to know is whether people who have seen the codebases of Hipp and his contributors think they’re several cuts above the rest to the point that their brains are driving the quality, that it’s mostly their process (esp testing), or some combo.

          The question is whether we can use SQLite as an example of what a random group of experienced programmers with some dedication could accomplish in C code or if it mostly derives from its core contributors. If the former, then what a “modern C codebase can accomplish” in the general case. If the latter, then it’s not unless you have world-renown talent with QA focus.

        2. [Comment removed by author]

      3. 6

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

        1. 5

          We’ve got an import of the netqmail tree, and I’ve collected variously some of the patches that have been published against it in to branches:

          Notably missing here is the John M. Simpson’s DKIM patch, as it’s staged on top of his combined patchset and I haven’t pulled out the bits necessary to get it to apply to standalone netqmail. Certainly also there are patches available that implement the same features as this set, or solve different problems. I wouldn’t call this work here complete.

          Not everything here will go in to notqmail–it’s that much of qmail’s patches have been prepared by individual contributors and there has been relatively little work organizing, curating, or integrating it.

      4. 4

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

      5. 3

        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.

        1. 4

          To be clear, notqmail doesn’t have TLS support yet either. As of today, we’re a handful of commits ahead of netqmail 1.06, and have not yet published our initial notqmail 1.07 release. TLS will happen sometime at least a few releases after that, when we’ve provided sufficient extension points for TLS to be implemented outside qmail core code.

    2. 9

      qmail has been dead for quite some long time, and there’s quite a lot of catch-up to do. Now that we have Postfix, OpenSMTPD, and probably a few other MTAs that seem pretty high-quality to me, I’m left wondering … what’s the point in reviving it? What does qmail fundamentally do better or different than the alternatives (genuine question)?

      (Sidenote: my impression of most of djb’s software has always been that he mostly just wrote it to prove the point that you can write a secure/better MTA, DNS, etc, and after that point was proven, he kind of lost interest and moved on to other things.)

      1. 7

        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.

      2. 4

        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.

        1. 4

          P.S.: But Postfix and OpenSMTPD are really good too!

    3. 9

      Will notqmail change qmail’s accept-then-bounce behavior, or at least give the user the option to do so? I’m talking about the fact that qmail-smtpd doesn’t check that the recipient of a message actually exists, and then another component (qmail-send, I think) sends a bounce back to the sender if the message can’t be delivered. This means innocent bystanders get bounces for spam that they didn’t actually send. And this is one reason I haven’t used qmail in the past 9 years or so, though I used to be a big fan.

      1. 9

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

        1. 5

          Just filed Configurable validation of SMTP recipients. @mwcampbell, does the proposed solution address your concerns?

      2. 9

        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.

      3. 2

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

    4. 7

      notqmail is a few weeks old, and we’ve been putting the finishing touches on our 1.07 release. Our early focus is on platform fixes and packaging, as users overwhelming expect software to be available as a precompiled binary or otherwise available in the distribution mechanism provided by their operating system or platform. This release supports the DESTDIR environment variable and removes the requirement for the qmail system accounts to exist at build time, permitting a binary package to be prepared without requiring root access. The build works on case-insensitive filesystems (Mac OS X) and platforms that have fully deprecated utmp in favor of utmpx (FreeBSD).

      After this release we’ll focus on fine-grained support for FHS and platform-specific install layout–systematically removing barriers to building and packaging. At the same time, we’ll continue making correctness fixes and adding features–In the fullness of patches that are available for qmail, many of them touch the same code. qmail-smtpd most particularly. We’ll be taking the work started in netqmail with QMAILQUEUE and making an extension interface so these features can be used without requiring them to be merged in to the codebase. This lets us use the security design qmail already has, adapted for the demonstrated problems existing patches solve for.

      If any of you are interested in testing, please claim a distribution and try the build+package instructions. I’m happy to make testing equipment available to you, if you need it.

      I’ve really enjoyed working with my co-contributors schmonz (@schmonz on Lobsters), DerDakon, and mbhangui. I look forward to our first release.

      1. 3

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

        1. 5

          I’ve been in touch with – and gotten encouragement from – a few. If we’re really lucky, maybe after a few notqmail releases they’ll decide it’s worth the time and energy to join us. We’d be very happy to have them, of course, and also very unsurprised if their lives have taken them in other directions.

        2. 4

          The last netqmail release was November 30th 2007, upon djb placing qmail-1.03 in the public domain. That is over a decade ago. It’s a reasonably small community, the set of contributors to qmail, and I believe some of the almost dozen folk involved in netqmail-1.06 are aware of notqmail. I am happy to work with any of them who are still interested in the project, but that interest has not been demonstrated by any changes, patches, releases, or even news in over a decade.

    5. 4

      Oh I do hope this finally lands DKIM support in a way that is palatable. That would be super, and one of the only things I’ve ever longed for after running qmail in prod for 12 years.

      1. 4

        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.

    6. 3

      Update: as folks here have surely seen, last month Qualys reported exploits against qmail 1.03. We fixed them somewhat thoroughly in notqmail 1.08, and for 1.09 we’re aiming to build with zero compiler warnings. This will let us ratchet up the warning level and add more static analysis tools. 1.08’s source tree also includes our first few unit tests, and when coverage improves a bit more we can start getting benefit from valgrind.

    7. 3

      We’ve shipped our first release! Lobste.rs post here.