Here's what actually seems to have happened. Warfield ran out of space on one of his disks. He was using an unreliable mailing-list program that couldn't deal with the lack of disk space. The program ended up generating a series of empty messages, which qmail dutifully began distributing to subscribers.
Warfield attempted to destroy the messages by manually removing files from qmail's queue, despite common sense and despite specific warnings in the documentation. Naturally, qmail checks for errors whenever it uses a system resource; it was unable to open the files that Warfield removed, so it logged appropriate error messages and deferred the delivery attempts until later. Eventually Warfield shut qmail down and fixed the queue.
1997-09-04: Warfield claimed that qmail was responsible for his mailing-list problems. ``On the front of reliability and recoverability, I am NOT impressed at all, just the opposite,'' he wrote. ``It's [sic] error detection and recovery, quite frankly suck. ... When it runs out of space, it commits henious [sic] random acts of terrorism. On one occasion, it ran out of space in one file system and spewed thousands of empty messages (which then looked to everybody like they came from root@systemname). I've had it run amock [sic] like this a couple of times. ... Its failure modes are pretty much catastrophic.''
This analysis is patently absurd. qmail doesn't invent message sender addresses. The only way it can send a message that appears to be from root@systemname is if some external program put such a message into the queue.
``Let's not forget the reason it went from 1.00 to 1.01,'' Warfield said in the same message. ``Someone discovered that they could create a system wide denial of service attack using QMail by opening up enough connections to run the process table into the ground.''
I have no idea where Warfield acquired these delusions. qmail 1.01 was not a security-fix release; in fact, there has never been a qmail security-fix release. The qmail system has always strictly enforced concurrency limits, and the companion tcpserver program supplies concurrency limits that are missing from inetd.
1998-10-30: Warfield tried to insinuate that the www.rootshell.com breakin was through some vulnerability in qmail.
1999-01-11: ``I've seen it commit enough random acts of terrorism not to trust it exposed to the outside world,'' Warfield wrote. ``One of the worst brain farts I saw QMail commit occured [sic] because the filesystem ran out of inodes and QMail's error recovery really sucks wind seriously. It spammed our entire mailing list with empty messages "from root" over and over again until I shut it down and fixed the filesystem problem.''
1999-01-14: ``QMail makes a lot of noise about security, but I would never use it for security reasons,'' Warfield wrote. ``I've had it brain-fart several times on system resource exhaustion (ran out of inodes on the spool file system once and it farted empty messages to all of our subscribers) and seems to have poor error detection and recovery. Managing it's [sic] queue is fraught with peril (remove the wrong message file and you will get megabytes of syslog complaints!) ... Unfortunately, the author, Dan Berstien [sic], has a reputation of being "less than responsive" and having a bit of an attitude ... Dan was flaming Weise [sic] over some initial problems with PostFix while blythly [sic] forgetting about the early problems he had with QMail (including at least one Denial of Service attack which would crash an entire system).''
For the record: There were no ``early problems'' with qmail. The design and implementation principles behind the qmail security guarantee were in the qmail code from the very beginning. Postfix wasn't written to the same standards; the ``initial problems with Postfix'' included a message destruction attack that, a year later, the Postfix author still hasn't apologized for. The ``attack'' that Warfield mentions was not a qmail problem; it was a fraudulent marketing stunt by the Postfix author.
1999-02-01: ``I've had qmail commit too many random acts of terrorism when something went "bump" that it didn't expect,'' Warfield wrote. ``(Have a queue file disappear and it floods your syslog, run out of inodes on the file system and it spams your mailing lists with empty messages from root, etc, etc, etc...)''
Again, this analysis is patently absurd. I asked Warfield to stop making false statements. I explained to him that qmail was simply passing along the empty messages it received from another program.
``It never happened it [sic] sendmail,'' Warfield wrote, ignoring the fact that his load had been steadily increasing since then.
``And, gee, how many times did you run out of inodes back then?'' I asked. ``Have you systematically tested each of your mail-related programs under stress?'' He hadn't, and apparently still hasn't.
1999-05-31: Warfield accused qmail of ``random brain farts, poor error recovery, some non-compliance to RFCs, obstinant [sic] author who refuses to recognize when he has a bug (from personal experience).''
Once again: All Warfield has to do is fill up a test disk and systematically try each program involved in his mailing list. Traces will immediately reveal which program is at fault. But Warfield clearly isn't interested in the facts.
Warfield said that he had seen qmail ``screw up on errors that resulted in slamming all of the subscribers with multiple empty messages. It's done this 3 times in the last year. ... QMail has a tendancy to misbehave far more often than sendmail.''
1999-07-30: ``Just hope it doesn't run into one of the upteen [sic] hickups [sic] or unexpected errors that makes it go dain-bramaged and flood your syslog (happen several times in the last two years - it can't recover from missing spool files) or spam your mailing lists with empty messages from root (lost track of how many times that happened),'' Warfield wrote. ``It also has problems with "author attitude". If you can't convince Berstein [sic] that he has a bug, he won't even stoop to look at it.'' Warfield blamed qmail for ``the time our majordomo got "percent hack spam bombed"'' and again accused it of ``random acts of terrorism.''
2000-02-05: ``I've seen QMail commit random acts of terrorism when it runs out of memory, disk, or inodes (disk and kernel) (any others),'' Warfield wrote. ``Its error detection and recovery really sucks. When something happens that it doesn't like, it doesn't fail gracefully, it goes nuts. We lost a message file out of the QMail spool on one occasion (reasons unknown - shit happens) and it couldn't recover. Instead it spammed our log file with over 40Meg ...''
It's interesting to note that, in previous messages, Warfield admitted that qmail's megabytes of log entries were the result of his manually screwing up the queue. In this message, however, his story is that the queue ``lost a message file'' for ``reasons unknown.'' Anyway, whichever Warfield story you believe, qmail did exactly what it was supposed to do: complained about the missing files and deferred the delivery attempts.
``All of the systems I tried to run QMail on ran into problems running out of memory, swap, inodes, and other resources, sooner or later,'' Warfield continued. ``Problems which I have never run into with any of these other MTAs. ... QMail outstrips Sendmail by orders of magnituted [sic] in delivery performance but we learned the hard way that robustness and reliability was just the opposite.''