Hello all,
Damn. This is going to sound like a troll. And I don't know how to
avoid that short of not asking the question.
I keep hearing rumblings about how Dan plays fast and loose with the
RFCs in qmail and his other programs. All I know is I'm a happy qmail
(and djbdns and publicfile and ezmlm+idx) user. It all works for me.
I do a Google search and it seems I have to go back a very long ways
(mostly to mailing list postings dated in 1999) to find much griping
about this. For the most part, I don't see any specific complaints
about Qmail not being RFC-compliant, just articles of faith that it
isn't. Forgive me for finding these stunningly unimpressive.
There is something about an SMTP SIZE command.
I found Evan Champion ([EMAIL PROTECTED]) saying, "Interesting how
when qmail doesn't meet one set of "standards", it is an awful MTA,
but when it is one of the rare few that meets another set (immensely
more important IMHO), it is shrugged off as inconsequential."
Continuing on, I find Greg Andrews ([EMAIL PROTECTED]) who seems to have
reduced one claim of RFC non-compliance to an Outlook Express bug at
http://www.cm.nu/~shane/lists/comp.mail.sendmail/2001-01/0301.html
At http://www.tks.buffalo.edu/usg/Public/Qmail/qmail-upgrade.0.html, I
find:
6. Unlike sendmail, qmail-inject doesn't replace host
names with canonical names. Example: qmail-inject
won't change [EMAIL PROTECTED] in your
header to [EMAIL PROTECTED] The send-
mail documentation claims that qmail-inject's behavior
is illegal under RFC 822 and RFC 1123; that claim is
based on a questionable interpretation of an ambiguous
phrase in RFC 822. Besides, do you want to have host-
names changed behind your back?
In http://www.gnus.org/list-archives/ding/199912/msg00745.html ,
Stainless Steel Rat <[EMAIL PROTECTED]> writes, "Rewriting
headers of an RFC 822 message for canonicity is a good thing. But if
a message is not an RFC 822 message, qmail-inject has absolutely no
grounds for turning it into an RFC 822 message. And even then,
rewriting To and Cc is a Really Bad Idea because it can and eventually
will cause mail not to be delivered properly (see my response to Kai's
message for some details)."
Next, I find
http://list.nessus.org/listarch-nessus/1999-05/msg00096.html , which
seems more like a rant than anything else. The start of the thread
there sheds little light for me. It has something to do with qmail
replying with a 250 message, appearing to allow relaying, when in
fact it doesn't deliver the message. (Is this somehow related to the
ORBS nuttiness?)
There are some interesting notes at
http://vader.kootenay.net/qmail/misc/THOUGHTS.html The stuff that's
clearly identified as having to do with RFCs looks like it's okay.
But I don't know enough about the RFCs to see if anything else there
is related.
Robert Banz ([EMAIL PROTECTED]) says, "the author [DJB] has been
known to 'scoff' at the thought of RFC compliance (from Lisa '98)" in
http://linux.umbc.edu/lug-mailing-list/1999-04/msg00096.html , but
again, this isn't specific, at all.
Michael H. Warfield ( [EMAIL PROTECTED] ) wrote in
http://mlarchive.ima.com/linux-net/1999/3174.html , "qmail:obtuse
code, difficult to debug, requires special utilities to work on spool
files, binary data in spool files, spool file names linked to inode
numbers, random brain farts, poor error recovery, some non-compliance
to RFC's, obstinant author who refuses to recognize when he has a bug
(from personal experience)." Again, no specifics relating to RFCs.
So, I give up. I'm guessing other MTA's have at least as many real,
documented issues with RFC compliance as qmail. And I only see a
couple things that might be important. Am I wrong? What's the deal?
--
David Benfell
[EMAIL PROTECTED]
---
Resume available at http://www.parts-unknown.org/resume.html
PGP signature
