Re: Sendmail or Qmail ? ..
On Fri, Sep 05, 2003 at 12:54:55AM +0200, martin f krafft wrote:
Mostly good comments (I've never used postfix or exim -- comments seem
accurate from what I've heard) but I have to disagree with this:
>- qmail support includes being flamed by the author
I've subscribed to the qmail list more or less continuously since: "Wed,
21 Feb 2001 16:37:27 +0800", possibly earlier with an employer's email
account. In that time I've collected quite a few postings...
$ find Mail/qmail.old/ -type f | wc -l
23561
$ find Mail/qmail/ -type f | wc -l
866
(some might be from related lists like qmail-dist)
of those only a few are from the author...
$ rgrep -l 'From.*djb@cr.yp.to' Mail/qmail.old | wc -l
13
$ rgrep -l 'From.*djb@cr.yp.to' Mail/qmail | wc -l
2
of those only 8 appear to have been from DJB. I've included them at the
end of this message. I would characterize DJB more like a sphinx than a
flamer.
True if you are frustrated and confused and post arbitrary questions
to the qmail list, you will be squarely rebuked, quickly, by
other subscribers. In my opinion that's very different than being
chastised. On the same note, if you post carefully the facts needed to
answer your question, or just ask what they are, you will get an answer,
quickly. It doesn't really matter how difficult your question is. There
is pretty good signal to noise on the list too. I find going through the
work of properly framing my questions is often enough to answer them
myself, before I get to post.
Addressing the OP question. qmail is fast in many (not all) benchmarks,
as reliable as you can get (through power failure et al) and it has
a perfect security record. I use it because of the simplicity and
granularity of configuration, you can make it do _anything_, more easily
than other mailers I've used.
However, the configuration is unlike anything else, very different. For
that reason I would not use qmail in production before you have
at least 6 months experience with it, less if you have a simple
configuration. The components are not complicated, but if you don't
understand how they all work together, you can break your server
quickly.
// George
PS the funny license is easier to deal with than most people think. The
only time I've heard of a license issue that couldn't be resolved was
for an os that was to be distributed, to run on some 'thing' that didn't
have a /var directory and couldn't compile as part of the install. :}
Oops, I forgot the dates with the messages below, you can collate them
if you want....
$ rgrep -l 'From.*djb@cr.yp.to' Mail/qmail.old | xargs egrep -h '(^Message-ID|^Date)'
Message-ID: <20010411125509.25344.qmail@sws5.ctd.ornl.gov>
Date: Wed, 11 Apr 2001 08:55:09 -0400 (EDT)
Date: Wed, 11 Apr 2001 09:51:39 -0400
Message-ID: <20010411095139.I22741@gospelcom.net>
Date: 15 Apr 2001 19:31:35 -0000
Message-ID: <20010415193135.11508.qmail@cr.yp.to>
Date: 4 Oct 2002 19:19:51 -0000
Message-ID: <20021004191951.48321.qmail@cr.yp.to>
Date: 13 Oct 2002 08:43:09 -0000
Message-ID: <20021013084309.86576.qmail@cr.yp.to>
Date: 15 Oct 2002 22:37:36 -0000
Message-ID: <20021015223736.41114.qmail@cr.yp.to>
Date: 16 Oct 2002 01:20:41 -0000
Message-ID: <20021016012041.56263.qmail@cr.yp.to>
Date: 15 Nov 2002 09:00:51 -0000
Message-ID: <20021115090051.1269.qmail@cr.yp.to>
Date: 23 Nov 2002 03:23:03 -0000
Message-ID: <20021123032303.72148.qmail@cr.yp.to>
Date: 14 Jan 2003 02:11:17 -0000
Message-ID: <20030114021117.13262.qmail@cr.yp.to>
Date: Mon, 14 Jul 2003 17:48:49 -0700
Message-ID: <Law15-F31XBirbThA9Q000023ef@hotmail.com>
Date: 14 Jul 2003 19:59:44 -0000
Message-ID: <20030714195944.61094.qmail@cr.yp.to>
Date: 15 Jul 2003 00:05:55 -0000
Message-ID: <20030715000555.6120.qmail@cr.yp.to>
$ rgrep -l 'From.*djb@cr.yp.to' Mail/qmail | xargs egrep -h
'(^Message-ID|^Date)'
Date: Fri, 22 Aug 2003 15:31:44 +0530
Date: Fri, 22 Aug 2003 16:30:11 +0530
Message-ID: <20010415193135.11508.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: RFCs?
David Benfell writes:
> I keep hearing rumblings about how Dan plays fast and loose with the
> RFCs in qmail and his other programs.
Mud-slinging 101: Claim that the program won't work for most people.
Claim that it's a research prototype not meant for serious use. Claim
that nobody uses the program. Don't worry about the truth.
These claims are effective as long as the program is not perceived as
being popular. Readers using the program will know that you're lying,
but they aren't your target audience.
Mud-slinging 102: Claim that, while the program seems to work, it is a
disaster waiting to happen. Claim that it has interoperability problems.
Claim that it violates RFCs. Don't worry about the truth.
These claims remain fairly effective even after the program is perceived
as being popular. Members of your target audience won't have any reason
to think that you're lying: they haven't read the RFCs, and they aren't
familiar with the tiny protocol details that affect interoperability.
> Robert Banz (banz@REMOVEME.umbc.edu) says, "the author [DJB] has been
> known to 'scoff' at the thought of RFC compliance (from Lisa '98)"
I wasn't at LISA '98.
> Michael H. Warfield
See http://cr.yp.to/qmail/warfield.html.
---Dan
Message-ID: <20021004191951.48321.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: Patch to make Received lines RFC 2821 compliant
Ryan Bebeau writes:
> Received: (qmail 67819 invoked by uid 1004); 4 Oct 2002 16:16:33 -0000
> which as I read into RFC 2821 is non-compliant.
Incorrect. The general Received-line format is specified in RFC 2822,
section 3.6.7. If you read RFC 2821, section 4.4, then you'll see that
it's a requirement for _SMTP servers_ to add detailed Received lines
upon receipt.
qmail follows these rules. There are serious mistakes in RFC 2821 (see
http://cr.yp.to/smtp/klensin.html), but this isn't one of them.
> I just had a customer of my employer that was using an RFC 2821 checker
> on the Received lines of an incoming email.
Such checkers violate RFC 2821, section 3.8.2.
> The reason he was checking for compliance is apparently because
> spammers rarely make their Received lines compliant.
http://cr.yp.to/qmail/antispam.html
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20021013084309.86576.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: Handling bouncing from spammers
Matthias Andree writes:
> Scenario: Mallory will make an MX lookup on unet.net.ph, connect to
> a.mx.unet.net.ph port 25, send a MAIL FROM:
> <innocent@victim.example.com>, RCPT TO: <nonexistent.user@unet.net.ph>,
> DATA, the spam mail, then CRLF.CRLF and your qmail will happily bounce
> the spam mail to innocent@victim.example.com with just a few lines of
> QSBMF prepended. YOUR name gets involved in a bounce of a spam.
Same thing happens if the attacker directs the message to
* a mailbox that the attacker has flooded, or
* a nonexistent user at a dialup virtual domain, or
* an automated list manager, or
* various other standard bouncers.
Andree is wrong when he claims that Postfix is immune to this attack.
Refusing mail for nonexistent local users does not prevent this attack.
Nonexistent local users are not the only standard bouncers.
All of this has been pointed out many times before. What Andree is doing
here is
(1) starting from a well-known denial-of-service attack that's built
into the clumsy design of the Internet mail infrastructure;
(2) describing one special _example_ of the attack, carefully chosen
to apply to qmail and not to other MTAs; and
(3) claiming, falsely, that the _entire_ attack applies to qmail and
not to other MTAs.
This seems to be standard behavior for Postfix proponents: they can't
compete on merits, so they lie to the users. A previous example is
described in http://cr.yp.to/qmail/venema.html.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20021015223736.41114.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Crypto in court Friday
For those of you wondering when qmail is going to start protecting mail
messages against eavesdropping and forgery: I'll be in San Francisco
Friday morning in front of Judge Patel arguing that the remaining crypto
regulations are unconstitutional.
If you're interested, check out my web pages at http://export.cr.yp.to,
and join either the discussion list (export) or the announcement list
(export-announce) for more detailed information in a couple of days.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20021016012041.56263.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: Handling bouncing from spammers
Matthias Andree writes:
> that's not common for spammers
Anyone who doesn't understand the fundamental flaw in that statement
should read http://cr.yp.to/qmail/antispam.html.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20021115090051.1269.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: [FYI] tcpserver core dump under FreeBSD 4.7
Erwin Hoffmann writes:
> tcpserver should attempt to lookup the limits instead of core dump.
You misunderstand. Bugs of this type are in the operating system's C
startup functions. Those functions dump core before they even give the
tcpserver code a chance to run.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20021123032303.72148.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Gratuitous incompatibility
Russell Nelson writes:
> What makes what a bunch of Berkeley students did right, and what Linus
> did wrong?
I'll let Kernighan and Pike explain it to you:
_Change the name if you change the specification_. Our favorite (if
that is the word) example is the changing properties of the Unix echo
command ... The behavior of
% echo $PATH
now depends on which version of echo we have. If the variable happens
by accident to contain a backslash ... it may be interpreted by echo.
The difference is similar to that between the output from printf(str)
and printf("%s",str) if the string str contains a percent sign. ...
It would have caused much less trouble had the new version of echo
been given a distinct name.
As a more direct example, consider the Unix command sum, which prints
the size and a checksum of a file. It was written to verify that a
transfer of information was successful: ...
Then systems proliferated, versions mutated, and someone observed
that the checksum algorithm wasn't perfect, so sum was modified to
use a better algorithm. Someone else made the same obervation and
gave sum a different better algorithm. And so on, so that today there
are multiple versions of sum, each giving a different answer. We
copied one file to nearby machines to see what sum computed: ... Is
the file corrupted, or do we just have different versions of sum?
Maybe both. ...
For its simple task, the original sum was fine; its low-tech checksum
algorithm was adequate. ``Fixing'' it may have made it a better
program, but not by much, and certainly not enough to make the
incompatibility worthwhile. The problem is not the enhancements but
that incompatible programs have the same name. The change introduced
a versioning problem that will plague us for years.
_The Practice of Programming_ (1999), pages 207-209.
I realize that Linus was unhappy with the speed of programs like tar.
That doesn't justify his screwing up the semantics of open() et al. that
the UNIX filesystem had promised for years: namely, ``inodes are kept
consistent by synchronously deleting, adding, or changing directory
entries.'' The problem is not the enhancements but that incompatible
system calls have the same name.
Linus should have implemented open() properly, introduced a new
asyncopen(), and modified tar to use asyncopen(). Other programmers,
seeing the speed benefits of asyncopen() for many applications, would
have used it, falling back to open() on other systems. Other OS vendors
would have implemented asyncopen() to receive the same benefits.
There was never any reason for this speed improvement to produce
incompatibilities, just as there was never any reason for the checksum
improvements to produce incompatibilities. All the failures were caused
by the careless use of an existing name for a new function.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20030114021117.13262.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: courier-users@lists.sourceforge.net,
courier-maildrop@lists.sourceforge.net, sqwebmail@inter7.com,
qmail@list.cr.yp.to
Cc: courier-announce@lists.sourceforge.net
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Sam Varshavchik writes:
> This breaks Courier and Qmail.
No. qmail's maildir_scan() looks only at files with mtime < time, so it
can't move anything out of the delivery directory until the next second.
Duplicates are eliminated by the standard use of stat() in delivery.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20030714195944.61094.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: qmail THOUGHTS file comment on badmailfrom "waste of code space"
http://cr.yp.to/qmail/antispam.html
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
Message-ID: <20030715000555.6120.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: qmail@list.cr.yp.to
Subject: Re: qmail THOUGHTS file comment on badmailfrom "waste of code space"
James Craig Burley writes:
> They're like taking painkillers after breaking a bone
Painkillers work for almost the entire population. ``Spam prevention''
works for only a small part of the population.
Once again: http://cr.yp.to/qmail/antispam.html
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago
--
GEORGE GEORGALIS, System Admin/Architect cell: 646-331-2027 <IXOYE><
Security Services, Web, Mail, mailto:george@galis.org
Multimedia, DB, DNS and Metrics. http://www.galis.org/george
Reply to: