FROM: Dave Sill
DATE: 09/04/2002 12:40:34
SUBJECT: RE: Help me to Protect qmail - Part III
Alberto J. Azevedo <<EMAIL: PROTECTED>> wrote:
>The problem this time is this: another guy, (thats two now) send to
>the list this web page and my jaw is on the floor.
Matthias Andree is a well-known qmail-hater/Postfix-lover. However,
this "Qmail bugs" page is probably pretty convincing to those who
don't know the facts, so, for the record, I think we should address
his comments. I'll take a stab at it...anyone else who wants to can
chime in, of course.
1.1. qmail-smtpd memory exhaustion attacks (unfixed for almost five
DJB and Venema take different approaches to resource limitation. DJB
prefers to use general resource limitation tools like
softlimit. Venema prefers to build resource limitation into each and
every program that uses resources. Therefore, DJB doesn't consider
this a bug, but Venema and Venemoids like Andree do. The fact is
that an LWQ-style installation using softlimit on the qmail-smtpd
processes is not vulnerable to these attacks.
1.2. qmail-smtpd bounce flood
qmail-smtpd can't bounce messages to invalid recipients during the
SMTP session, it has to accept everything and return a bounce
if/when delivery fails. Determining the validity of a local
recipient during the SMTP session would require qmail-smtpd to
duplicate the functionality of qmail-local *and* to have
qmail-local's access to home directories. Even then, in many cases,
qmail-smtpd would be unable to determine conclusively whether an
address is valid or not--consider the case where
~alias/.qmail-default exists or a virtual domain has a
Besides being hard to do, validating recipients during the SMTP
session makes it trivial for spammers to determine which addresses
are deliverable. A spammer can quickly run through a dictionary of
possible recipients and the MTA will obligingly validate them. The
standard fix to this problem, tarpitting, is kludgy and adds
unnecessary complexity to the SMTP daemon.
Yes, return addresses can be forged, but that's a weakness inherent
2.1. Bounce message contents are not crashproof
Yes, if the system crashes at the wrong moment a bounce message
could be lost. Big deal. Many MTAs don't even preserve the entire
original message in a bounce.
3.1. Deliberate RFC-1652 "8BITMIME" violation
Yes, qmail always sends 8-bit data. Yes, this is theoretically a
problem. In reality, it's not a problem. Go ahead and search the
archives if you don't believe me.
3.2. RFC-2821 (SMTP) violation (Mail Routing)
The RFC requires an MTA to try at least two MX's if a message is
undeliverable to the first MX. qmail only tries alternative MXs when
the first MX is unreachable. If the first MX accepts the connection
and refuses the message, qmail doesn't try to deliver via a backup
MX. This is a good thing, in practice, because primary MXs are
almost always authorative for a domain. The behavior the RFC
requires could (and does) result in spam being delivered through
3.3. Potential for Violation of RFC-2045 (MIME) and Lack of RFC-1894
(Delivery Status Notifications) support
DSN is a huge, complex mechanism for what should be a simple
process. qmail implements a simple bounce mechanism, trading
conformity for simplicity, reliability, and security.
4.1. Local resource hogging
Andree's benchmarks were designed to make qmail look bad, and they
did. qmail does do lots of synchronous I/O--that's necessary to
provide the reliability that qmail guarantees. But independent
benchmarks show that qmail is faster than Postfix, Sendmail, and
Exim. See: http://www.kyoto.wide.ad.jp/mta/eval1/eindex.html
4.2. Qmail is not softupdates aware
Softupdates improves filesystem performance at the cost of data
reliability. Softupdates guarantees a consistent filesystem, but it
doesn't guarantee that everything written to disk is actually
written to disk. qmail requires a filesystem that doesn't lie about
whether data was actually written to disk.
4.3. Bandwidth hogging
Yes, qmail "hogs" bandwidth in order to simplify the delivery
process (and make qmail itself smaller, more reliable, and more
secure) and deliver mail faster. As any solution to a complex
engineering problem, qmail makes trade-offs and compromises. No MTA
can simultaneously minimize bandwidth and maximize delivery
rate. DJB chose to maximize delivery rate.
4.4. No client-side ESMTP PIPELINING
Correct. qmail could possibly benefit from client-side ESMTP
PIPELINING, though it's not clear that the benefits outweigh the
4.5 Delayed bounces (also waste of bandwidth and spam-friendly)
4.6. Parallel delivery of qmail-remote sets back
One person has reported a problem. As Andree says, further research
needs to be done in this area before any conclusion can be drawn,
but the lack of problem reports on the qmail list indicates that
this is a rare and/or minor problem.
4.7 Mail sent from "anonymous", particularly by daemons.
This behavior is clearly intentional, and the workaround is simple
5.1. Security guarantee
$500 might be ridiculously small, but many people pored over Knuth's
TeX code for a chance at his $1 bug bounties. Many people would like
nothing better than to find a security bug in qmail just because
they dislike DJB.
Venema didn't win the prize because (1) he didn't find a bug in
qmail, and (2) DoS issues were explicitly excluded.
6.1. Copy bounces to postmaster
So qmail doesn't have a "copy bounces to postmaster" feature. So
what? Not only have I never wanted such a feature, I don't remember
ever seeing anyone ask for it. (It could, of course, be implemented
easily in qmail without patching.)