
Announcing Notqmail - cpeterso
https://schmonz.com/2019/08/20/announcing-notqmail/
======
dsr_
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
> _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
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.

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

~~~
sigil
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=...](https://www.cvedetails.com/vulnerability-
list.php?vendor_id=8450&product_id=14794)

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

~~~
linsomniac
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.

~~~
sigil
Fine, let’s call it 7, since postfixadmin & the debian postinst script can’t
be attributed to postfix proper.

I’m not sure this qualitatively changes the argument. CVE-2011-1720 and
CVE-2008-2936 are examples of postfix vulns no one has found, or reasonably
expects to find, in djb code.

~~~
pilif
_> CVE-2011-1720 and CVE-2008-2936 are examples of postfix vulns no one has
found, or reasonably expects to find, in djb code._

CVE-2011-1720 is related to SMTP authentication which qmail doesn't support
out-of-the box. So. Yes you're right: You don't find that vulnerability in
qmail because qmail doesn't have that feature.

Can you run an SMTP server without authentication these days? Not if you have
users using you as a relay. So I guess you have to custom patch qmail and now
you're back to _not_ running djb code in the first place.

CVE-2008-2936 I grant you. Though once we are at doing hardlinks to symlinks,
we might hit other edge-cases too, some might even affect qmail in some way.

~~~
geocar
Road warriors with Thunderbird may need SMTP authentication, but most people
do relaying with just IP authentication just fine.

~~~
rodgerd
If you think an IP address is a reliable identifier, your opinions on security
have no value.

~~~
amdavidson
While you and I agree that Parent is incorrect, let's not resort to personal
attacks.

------
intc
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](http://www.fehcom.de/sqmail/sqmail.html)

~~~
schmonz
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.

------
nineteen999
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/](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).

~~~
schmonz
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](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.

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

~~~
schmonz
Thank you!

------
genghizkhan
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?

~~~
poolpOrg
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.

~~~
genghizkhan
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.

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

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

