In September 1996, I tried sending Jackson e-mail to point out some of his errors and to request that he check his statements. His response: ``I'm sorry, I'm not interested in having this discussion with you.'' Later he complained in public that ``Every time I've said anything about Qmail somewhere the author has mailed me to complain,'' and concluded from this that I was ``dogmatic and aggressive''! So much for trying to settle things quietly.
Jackson: ``qmail doesn't deliver things immediately - it always waits for a queue run.'' Facts: qmail delivers every message immediately. It doesn't even have a ``queue run'' concept.
Jackson: ``[qmail does not] allow me to inspect the outbound mail queue without becoming root.'' Facts: As stated in the qmail-qread man page, the outbound mail queue can be inspected by uid qmails and gid qmail. Sysadmins who want to allow more access can run a qmail-qread server, though for security I recommend keeping the queue private.
Jackson: ``Exim has been tested on a number of large and very large sites, and seems to outperform Sendmail. Smail, PP and Qmail are a long way behind.'' Facts (as of December 1996, when I wrote this page): qmail is doing over 400000 deliveries per day on listserv.acsu.buffalo.edu, the #2 LISTSERV host. (sendmail couldn't handle the load.) The largest Exim host is doing a mere 50000 deliveries per day.
Jackson: ``bug in qmail ... When qmail is doing outbound SMTP it will issue a DATA command for a message even if it hasn't had any successful RCPTs.'' Facts: There's nothing wrong with sending the DATA---it is required for PIPELINING clients (see RFC 1854), and qmail's maildir2smtp will do it when PIPELINING is in effect. This is not a bug. Anyway, Jackson is incorrect: the default qmail-remote behavior starting in 0.91 has been to quit immediately if all the RCPTs fail.
Jackson: ``Even worse, it seems that sometimes when the receiving MTA says "5xx don't be bloody stupid" qmail acts as if it had got "go ahead" and sends the message text anyway.'' Facts: qmail-remote quits immediately on any 4 or 5 reply. You can convince yourself of this in sixty seconds, even if you've never seen the qmail source before: message text is sent at line 314 of qmail-remote.c; line 310 calls quit() if code is 400 or above; quit() calls zerodie(), which calls _exit().
Jackson: ``[smail provides] more reliable delivery.'' Facts: A bug in BIND 4.9.4 caused massive DNS cache corruption throughout the Internet. Thousands of mail messages around the Internet were bounced as a result. This had nothing to do with any particular mailer. Presumably Jackson received a bounce from qmail and, ignorant of the BIND problem, jumped to the conclusion that qmail is not ``reliable.'' Needless to say, Jackson never made any effort to determine what actually happened.
Jackson: ``Vague bounce messages.'' Facts: qmail's bounce messages have always been vastly more informative than (e.g.) sendmail's. For example, sendmail's error message for an ambiguous MX is ``local configuration error.'' qmail's error message in the same situation: ``Sorry. Although I'm listed as a best-preference MX or A for that host, it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)''
Jackson: ``Problematic licensing situation.'' Facts (as of 1996): I'm not permitting distribution of test versions of qmail, since I don't want to be stuck dealing with them forever. Version 1.00 will be freely distributable.
Jackson: ``qmail's sendmail command line emulation is broken.'' Facts: There's a pathetic story, and a fundamental principle, behind this one.
Fundamental principle first. Addresses can't simply be copied into RFC 822 address lists. Some addresses have to be quoted. Addresses with names attached have to be encoded carefully. Conversely, addresses can't be copied directly out of address lists; they have to be decoded.
RFC 822 address list decoding is not easy! qmail, like MMDF, goes to a lot of work to handle it correctly. sendmail does not. sendmail violates RFC 822 (and RFC 821): it assumes that address decoding is a simple matter of copying.
Pathetic story next. Jackson wrote some mail-handling software. He was too lazy to even look at RFC 822, let alone implement it. His address handling consists of naive copying. This violates RFC 822, section 3.4.4, but it matches sendmail's assumption.
When Jackson started using qmail, he had trouble. It didn't take him long to isolate the problem: he fed the line ``To: @primer.i-connect.net:iwj@master.debian.org'' into qmail's sendmail wrapper, and qmail-inject refused it.
Now, anyone familiar with RFC 822 knows that Jackson should have put angle brackets around the address. Colons have a completely different use outside brackets. qmail-inject rejects misplaced colons rather than risking a bad guess.
But Jackson didn't bother to check RFC 822. He reported a ``qmail bug'': ``qmail's /usr/lib/sendmail will not allow me to send a message containing an RFC822 route-addr (source route) in the To field. This is a bug... it's quite a bad bug and should be fixed ASAP.'' Meanwhile, he asserted behind my back that qmail's RFC 822 header parsing is ``very ropey,'' that qmail has ``outright bugs,'' and that qmail's ``implementation quality is poor.'' He didn't bother to correct himself after I pointed out his mistake.
Back to ``qmail's sendmail command line emulation is broken'': qmail's sendmail wrapper is, of course, not a complete clone. It doesn't have sendmail's security holes, speed problems, and reliability problems, and it doesn't emulate sendmail's violations of RFC 822. It's just a quick way to make qmail work with a bunch of existing MUAs. If it doesn't work with Jackson's crappy software, the solution is to fix Jackson's crappy software.
Jackson: ``Poor /usr/lib/sendmail emulation, as a matter of policy!'' Facts: Here Jackson is referring to quoting again. The ``policy'' I'm adhering to is RFC 822. See above.