Announcing Notqmail

https://schmonz.com/2019/08/20/announcing-notqmail/

by cpeterso • 7 years ago

160 72 7 years ago

I have to wonder how much work is going to be required to bring qmail up to a modern standard. There's no doubt that the author is an extremely intelligent programmer with a deep focus on security. In the intervening period Postfix has really gained in popularity, and is shipped pre-configured out of the box on some major Linux distributions. It is the default MTA for Fedora/Redhat etc for some years now.

I wanted to like qmail, it was definitely an improvement over the complicated disaster that is Sendmail, however, it always seemed to require patches to get it to do things that Postfix could already do out of the box. In addition I didn't like the dependency on the inetd replacement thing (daemontools?). It just felt so un-ergonomic.

In addition, the Maildir mailbox format (while very cool in its own right) usually required third-party software to be patched manually, for example WU-IMAP.

A day or two before the September 11 attacks, the UNIX time_t value rolled over to 1 billion, and went from 9 digits long to 10 digits long. The moment this happened, a comparison function in the WU-IMAP maildir patches failed, and our IMAP server started sorting and displaying all our emails out of order.

After scratching our heads and poring over the source code for a couple of hours, a co-worker and I found the problem and submitted a patch to the maintainer.

Funnily enough, the imap-maildir page still references this event even today (it probably hasn't been updated in years):

http://www.davideous.com/imap-maildir/

Under the section "10-digit unix date rollover problem". But it drive home to me as a fairly young sysadmin at the time of the dangers (at least for the inexperienced) of using third-party patches just in order to enable a non-standard mailbox format (eg. Maildir).

codetrotter• 7 years ago

From the page you linked:

Did your installation stop sorting messages correctly on 9 Sep 2001 01:46:40 GMT? Find the fix to the 10-digit unix date rollover problem in the important updates section below.

Reading that I imagined someone running those patches on their mail server for two decades before suddenly realizing one day in 2019 that for the past 18 years their messages have been ordered incorrectly, ha ha.

schmonz14• 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.

nineteen9992• 7 years ago

I wish you the best of luck with the project, I hope you are able to achieve all your goals.

dsr_• 7 years ago

I used qmail for about ten years. It was remarkably good from a sysadmin's perspective:

- the config system mostly used the name of a directory where lots of software would use a filename (qmail.ini => /var/qmail/conf), the name of a file where other software would use a variable name, and the contents of the file as the value of the variable. This is really, really easy to read and write without writing a parsing library.

- separate executables do separate jobs, with well-documented interfaces between them. Oh, and if a part didn't need root, it didn't run as root, and if a part didn't need to be the same user as another, it didn't share users. While it was easiest to replace something at the edge of the graph, it was entirely possible to replace middle jobs as well.

- qmail was the original design home of Maildir. I approve of various Maildir++ implementations (nesting folders is useful) and you could add support for them by replacing your delivery agent.

- qmail expected to be controlled by daemontools, a supervision system that has inspired/been blatantly copied and improved upon as runit, perp, s6, and nosh. (I have a suspicion that nosh is what most critics of systemd is really looking for.)

- fast.

- nearly bug-free.

What qmail gave up in exchange for all this: modern features and required antifeatures... which, it appears, notqmail is going to implement. Huzzah!

sneak• 7 years ago

the config system mostly used the name of a directory where lots of software would use a filename (qmail.ini => /var/qmail/conf), the name of a file where other software would use a variable name, and the contents of the file as the value of the variable. This is really, really easy to read and write without writing a parsing library.

this djb-ism has seriously affected a lot of the ways i unix, to date. envdir is such a great idea.

nailer• 7 years ago

djb needs his own distro. He's written his own init, has thoughts about package management, config management, etc. He probably doesn't need his own kernel but a BSD or Linux kernel with DJB controlling userland would be interesting.

linsomniac2• 7 years ago

I liked a lot of things about qmail, but I found it annoying as a sysadmin, like in the 1.07 days, because you had to do all this patching. I eventually wrote a script that would take all the sources and patches that one needed to run a reasonable mail server, and turn them into an RPM that could be installed, because I couldn't just provide the patched, resulting RPMs.

There were a lot of great things about qmail. I really liked the envdir and how secure it was. But eventually I found the attitude behind it very tiring and switched to Postfix, which is a really great program.

schmonz14• 7 years ago

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.

ahje2• 7 years ago

The question is if notqmail isn't a bit too late. I'm maintaining a qmail setup for a customer and the amount of duct tape we've put on that thing is rather ridiculous. As it is now, I'd rather replace the whole thing with a regular Postfix/Dovecot setup and be done with it.

throw0101a• 7 years ago

As it is now, I'd rather replace the whole thing with a regular Postfix/Dovecot setup and be done with it.

Any reason why you don't (can't?)?

d1zzy• 7 years ago

Agreed. Having had the opportunity to encounter, use, setup, and then later on, read the code and learn from qmail early on in my computer career I think it helped learn about proper system design with an eye towards security. Back when qmail was released there was nothing like it, the most popular MTA at the time was Sendmail and we all know how great that was :)

qmail had a great impact on system design for many years and especially in the mail delivery area. Things like Maildir redefined how even MUAs store and use email. djbdns also provided a breath of fresh air at the time it was released, worked much faster and much more secure than something like bind.

DJB also had many other (likely even more impactful) roles in the software industry, leading the fight against the encryption software export restrictions of the 90s.

https://en.wikipedia.org/wiki/Daniel_J._Bernstein

Nux• 7 years ago

Used qmail a lot and would use it again if modernised a bit.

Vpopmail was great, too for managing users, hope it'll still work.

bifrost• 7 years ago

I haven't used Qmail since 1999 maybe, I don't miss it at all but its kinda nice that some people have modernized DJB's code.

cryptonector6• 7 years ago

Why not Postfix? I trust Wietse V. and Viktor D. a great deal, and I trust their coding abilities at least as much as if not more than DJB's for anything that isn't a cryptographic algorithm.

FYI, "I’ve learned more C, reduced build-time complexity, ..." probably isn't confidence-inspiring. I work with C a great deal and have for a very long time, and I though I'm very comfortable with C, I treat it with fear and respect -- I have found far too many security vulnerabilities just from staring at C source code to do anything else. Now, I too have "learned more C" over the years, but I wouldn't write a sentence like that as part of justification for some project written in C -- I would fear that others would wonder if I don't just know enough C to be dangerous. Perhaps one should not write "I've learned more C" as part of anything other than justification for moving to Rust.

stonogo• 7 years ago

Postfix cannot do what qmail can do. Specifically, users can create and destroy email addresses themselves with .qmail files. This is different and more powerful than Google's plus-addressing approach. There are many, many other features of qmail's implementation that Postfix cannot compete with.

Postfix is not alone in this; no other MTA/MDA can do what qmail can do.

pmoriarty• 7 years ago

It would be really useful to have an exhaustive list of all these things that qmail can do that other MTA's can't.

amaccuish3• 7 years ago

I've got a similar thing with my postfix setup though. My users can go to their account portal and apply for an alias, which when approved (to avoid taking of important names like postmaster etc.) is added to their otherMailboxes LDAP attribute. They can delete the alias themselves when they're done with it.

I'm tempted to start auto-allowing new aliases and just having a list of names that can't be used (postmaster, webmaster) etc, that some services use for domain ownership verification.

As an aside I do hope qmail offers similar limiting abilities. It wouldn't be great if a user could make themselves receive webmaster@domain.tld emails!

Tepix• 7 years ago

The standard postfix setup these days uses a DB backend and users can edit the database to create new email addresses and aliases.

schmonz14• 7 years ago

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

xvilka• 7 years ago

Yes, Rust is a perfect fit for such a project.

cryptonector6• 7 years ago

Hey! I'd not noticed you were involved. EDIT: Where are my manners. Hope you're well too!

So, yeah, qmail is fine as a starting base, but there are important things that a modern MTA/MSA needs to have:

  - MSAs need to support user authentication in
    SUBMIT (no open relays)
  - MTAs and MSAs need to support TLS
  - MTAs should -really, need to- support DANE
    for authenticating SMTP servers

There's more stuff too (delivery options, filtering, ...), but protocol-wise, the above are critical.

I'm not sure that portability is such a problem that you can't use Rust. Rust runs on all modern OSes, which is all you need to support in a new MTA/MSA. And Rust is fairly easy to get into, actually.

peterwwillis• 7 years ago

This reads a bit like if you posted that you were going to restore your Camaro Z28 with modern parts, and someone replied, "Why not a Corvette?"

sigil3• 7 years ago

Postfix has had 9 CVEs in 20 years, a few of them quite bad. [0]

qmail has had 1 CVE in 20 years, a local DoS. [1]

I trust djb to write correct code more than almost any other human on the planet. That includes all the non-crypto code found in qmail, daemontools, dnscache, ucspi-tcp, etc. If you’ve read it, you know how almost supernaturally careful and minimal it is.

Your points about mere mortals writing C are well taken though!

[0] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

[1] https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

linsomniac2• 7 years ago

Can you revise that "9" number, because looking at it I feel like some of those are inappropriately filed against postfix.

I find it hard to pin a "postfixadmin" CVE on postfix, are we going to blame vmailmgr bugs on qmail? :-) The BSDDB one I'm on the fence about. "postfix_groups.pl" is marked as disputed. Another seems to be clearly a Debian package issue.

CVE-2011-0411 is interesting because, IIRC, qmail had no SSL/TLS abilities, and the hacks you had to put into place to enable it were abominations and likely opened up issues of their own.

yellow_postit• 7 years ago

Just a count of CVE, while interesting, I think misses calibrating by how much attention each has gotten. Given its popularity I'd assume much more security research and testing on postfix.

pilif8• 7 years ago

The moment you start patching qmail you're not running qmail any more. None of the CVE numbers are meaningful to your custom-patched qmail.

qmail was good when you could use it in its default configuration. Unfortunately, very few sites could (much less still can).

Which brings us to the question of who you trust more: The maintainers of a full-featured MTA who have maintained their software for 20 years or some person's patches to scratch their itch before moving on and never touching it again?

gypsyharlot2• 7 years ago

https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...

cryptonector6• 7 years ago

I think that blog is wrong.

Rust is not a magical language. It's just got the right features to be a C replacement, which is mostly: a simple type system (much simpler than C++'s or Java's) that has the right extensibility (traits, no inheritance) and can have an ABI that programmers can reason about due to monomorphization (no v-table dispatch).

All the borrow checker stuff amounts to: just enough pain that to avoid it you must design better APIs.

lwh• 7 years ago

We all killed SMTP when we pointed the morons with domains at gmail/apple/yahoo/o365, postfix was winning when it was ended- no reason to revisit it. All that matters for email is what Google/MS/Apple decide to dictate to us now.

intc• 7 years ago

Just wanted to add that Erwin Hoffmann has actively maintained s/qmail (and related djb tools) for quite some time. =) Please feel free to check his website:

* http://www.fehcom.de/sqmail/sqmail.html

schmonz14• 7 years ago

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.

genghizkhan3• 7 years ago

I run my own email server as well, and I've been using postfix/dovecot quite happily with zero issues. I've been contemplating opensmtpd as well, though I'm not sure where that stands when it comes to being run in production environments. Also, reconfiguring mailservers is a PITA, I'd rather stick with a setup which just works.

Could someone explain why one might want to use qmail (or this, its newest incarnation) over postfix or opensmtpd? Would I gain anything by shifting to qmail or opensmtpd?

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

genghizkhan3• 7 years ago

Thank you! I will definitely keep a weather eye on this project! :)

poolpOrg• 7 years ago

I'm an opensmtpd developer.

As far as opensmtpd is concerned, it is production ready and has been used in high volume environments sending mails to millions of recipients daily, handling multi-million queues.

The project was started in 2008 so when it comes to being run in production environments, I think we can claim that it's ready :-)

Now as for the what you would gain, I won't do proselytism, we have published a couple presentations on our website which describe how it works and some of the technical details behind it. You will also find lots of technical details on my blog where I post mostly about OpenSMTPD internals.

If you have a running Postfix, I suggest you don't shift but keep your working setup. If you intend to setup a new MX, you should definitely give a try and see how it goes for you.

genghizkhan3• 7 years ago

Thank you very much! I shall have a look. I'm thinking of moving servers and setting everything up from scratch in order to modernize all my services and remove legacy cruft. I will definitely consider opensmtpd.

Announcing Notqmail

Related Stories