Re: RFCs?

[Andy Bradford]

Thus said "D. J. Bernstein" on 15 Apr 2001 19:31:35 -:

> See http://cr.yp.to/qmail/warfield.html.

Wow, I've never seen a more clueless sysadmin.[1]  It's apparent that he
doesn't understand what the problem was and decided to make qmail the
scapegoat.  What's sad is that there are people out there that would
believe what he has to say because he poses as an ``expert''.

Andy
[1] Actually I have. :-)
[---[system uptime]]
 10:01pm  up 9 days,  1:17,  4 users,  load average: 1.00, 1.00, 1.00

Re: RFCs?

[Russ Allbery]

David Benfell <[EMAIL PROTECTED]> writes:

> 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?

There are some RFCs that Dan has chosen not to implement in qmail, and the
few complaints about RFC compliance that I've seen backed up with actual
data have been about that.  The primary ones that I've seen mentioned are
DSNs and SMTP AUTH.

I understand the reasons for both of these, mind, and am not arguing that
qmail should necessarily implement them.  Not implementing those
extensions certainly doesn't make qmail a non-RFC-compliant e-mail system,
just one that doesn't implement some optional features.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: RFCs?

[D. J. Bernstein]

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 ([EMAIL PROTECTED]) 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

Re: RFCs?

[Peter van Dijk]

On Thu, Apr 12, 2001 at 11:44:10AM -0700, David Benfell wrote:
> 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

True. qmail deals with RFC821, not 822, except for qmail-inject.

>  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?

Indeed, sendmail even does this stuff behind your back on
SMTP-injected mail. I call that a bug.

> 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)."

Rewriting headers is not a good thing. Remember that :)

> 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?)

The thread talks about how qmail accepts a message for, for example,
<[EMAIL PROTECTED]> if the server is configured to accept
vuurwerk.nl. Some broken tools then consider a qmail box to be an open
relay, which is a mistake. qmail accepts the address because it was
configured that way. 'peter%dataloss.net' can very well be a valid
local username. This trick can not ever be used for relaying (except
when you configure percenthack too, but I've never done that).

> 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.

That is actually straight from the qmail docs.

> 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.

Let's see.
- obtuse code: matter of taste. I like djb's coding style. Lots of
people hate it and have trouble digesting it.
- difficult to debug: because qmail's design actually makes sense,
it's a lot easier to debug than sendmail, once you understand how it
all fits together.
- requires special utilities to work on spool files: yes, because the
spool was designed to be reliable, not to be edited by humans.
- binary data in spool files: see previous point.
- spool file names linked to inode numbers: is a design decision that
has it's benefits. I see no downsides in that.
- random brain farts: whatever :)
- poor error recovery: no idea what he means.
- some non-compliance to RFC's: not that I know of
- obstinant author who refuses to recognize when he has a bug: I know
of only one bug in qmail-1.03 (STAT in qmail-pop3d), and indeed djb hasn't
responded to that. For the rest, qmail has no known bugs.

> 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?

The deal is that people think sendmail should be considered a
reference implementation of the mail RFCs (like BIND for the DNS
RFCs). sendmail isn't (and BIND isn't), but people think that anything
that's "different" is wrong. It's not. Sendmail is wrong.

Phew. And all that on a hangover :)

Greetz, Peter.

Re: RFCs?

[Dave Sill]

Brian Reichert <[EMAIL PROTECTED]> wrote:

>On Thu, Apr 12, 2001 at 11:44:10AM -0700, David Benfell wrote:
>> 
>> 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.
>
>The only other thing I recall someone bitching about is that he
>invented a new header field 'Delivered-To', wherein the
>convention/standard (when you are inventing such things) is to
>prepend them with an 'X-', ie:  'X-Delivered'To'.

That's not a standard.

One thing DJB does thumb his nose at is the RFC821 prohibition against
transmitting 8-bit characters. Chicken Little notwithstanding, the sky
remains intact.

Standards are great but they shouldn't be followed blindly.

-Dave

Re: RFCs?

[Brian Reichert]

On Thu, Apr 12, 2001 at 11:44:10AM -0700, David Benfell wrote:
> 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.

The only other thing I recall someone bitching about is that he
invented a new header field 'Delivered-To', wherein the
convention/standard (when you are inventing such things) is to
prepend them with an 'X-', ie:  'X-Delivered'To'.

> -- 
> David Benfell
> [EMAIL PROTECTED]
> ---
> Resume available at http://www.parts-unknown.org/resume.html

-- 
Brian 'you Bastard' Reichert<[EMAIL PROTECTED]>
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA Intel architecture: the left-hand path