Wietse Venema, kicking off a mud-slinging campaign to promote his own MTA, claimed in June 1997 that qmail ``made [systems] vulnerable to memory exhaustion attacks.''
False. The truth is that those systems were vulnerable before they were running qmail.
Venema then repeatedly tried to insinuate that qmail-smtpd is the only UNIX network service that dynamically allocates memory up to rlimits or physical limits.
False. For example, sendmail, bind, and inetd can each be easily convinced by network input to use all available memory.
After tacitly admitting that many such programs exist, Venema claimed that arbitrary memory allocation is ``CONSIDERED A BUG.''
False. This problem was dealt with in the kernel many years ago: UNIX systems have configurable, easy-to-use per-process memory rlimits. The system administrator has tremendous power to allocate his resources.
Apparently Venema thinks it's better design to include separate code in every application to impose configurable artificial limits on every dynamically allocated structure for network data. I think that this is remarkably bad engineering.
The bottom line is that well-managed systems are not damaged by memory exhaustion attacks, whether or not they are running qmail.
Update, proving my point about bad engineering: Someone discovered in November 2001 that Venema had failed to put an artificial limit on Postfix's dynamically allocated SMTP session log. Consequently, on a badly managed system without resource limits, an attacker could trivially convince Postfix's smtpd to use all available memory. Did Venema post ``exploits'' and try to have entries added to vulnerability databases? Did he admit that his approach was vastly more complicated and error-prone than system resource limits? Nope.
Venema claimed in August 1997 that this was a security advantage for his MTA.
False. qmail's environment variables are easy to use safely, and have no effect on programs that don't use them.
False. As explained in detail in qmail-1*/FAQ, question 5.5, qmail lets the sysadmin pass network messages through the same rewriting facilities as local messages.
False. If qmail is unable to deliver a message, no matter what the reason is, it bounces the message back to the sender.
Venema later changed his claim: ``qmail rejects the entire message when it has a problem parsing a sender or recipient address.''
False. qmail makes no attempt to parse the contents of a message unless it is asked to rewrite the header. If you're running qmail, and someone sends you a completely non-822-compliant message, qmail will happily deliver it.
Venema claims that this ``is bound to fail'' and that qmail ``becomes wedged'' and crashes with a large backlog.
False. Venema has forgotten that the number of messages is limited by queue disk inodes. The maximum memory use is so small that, even on a machine with very little memory but enough disk space for a gigantic queue, Venema's fantasy simply cannot occur. (This issue is, of course, not new; it has been analyzed in the documentation in every qmail release.)
Example: One machine built up a queue of more than one hundred thousand messages during a two-day network outage. qmail handled the backlog successfully.
False. qmail can do deliveries to /var/spool/mail with the same delivery program that sendmail uses, and it supports .forward files through the dot-forward program. Users can take advantage of .qmail files and ezmlm and so on, but users who don't know about the new features won't notice the change.