Subject: RE: editing status of 821bis, draft -10.

From: "Larry Osterman (Exchange)" <[email-masked]>
Date: Tue, 16 Feb 1999 16:37:43 -0800

I knew I shouldn't have started this....  I REALLY knew I shouldn't have
started this..........

Ok, one last time, then I'll shut up.

All I'm saying is that the "maildirsmtp" program is NOT an 821bis MTA and
cannot be advertised as being an 821bis MTA.  It's fine to include it in
serialmail, and it's wonderful that lots of ISPs use it.  But it's not a
part of an internet MTA.  It may use many of the wire formats of an internet
MTA, but it is NOT an internet MTA.  And RFC821 defines what it means to be
an internet MTA.

If you want to claim to be an MTA, then you have to do ALL the things that
an MTA can do.  Not some of them, not even MOST of them, but ALL of them.  I
wasn't here when DRUMS was formed, but it's been made clear from
participants that have been here since the beginning that one of the things
that DRUMS was constituted to fix was the mismash of things that were all
claiming to be "SMTP".  There were just too many ambiguities in 821 and too
many things in 821 that were actually harmful to allow 821/822 to be the
"standard" for internet email.

So DRUMS was formed to clean up the ambiguities and harmful aspects of this
specification.  One of the things that was decided early on was that since
RFC821 described both the wire format and store&forward behaviors of
internet email, 821bis would ALSO describe the wire format and store&forward
behaviors of internet email (Please note that I wasn't involved in internet
email through most of what I describe below, so it's entirely possible I'm
getting it totally wrong, but from reading the relevant documents, I think
I'm not too far off the mark).....

This task is complicated by the fact that the store&forward functionality is
not clearly called out in RFC821, instead it's scattered throughout the text
(see the references to the 551 and 251 error codes for examples).  In 1982,
when there were only several thousand hosts on the net, it was totally
reasonable for a mailer to build up routing tables internally that
essentially provided a digraph that would show how to route mail to any
other user on the net.  That's the entire purpose of the reverse path and
source routing functionality in RFC821, and the VERFY/EXPN functionality
that everyone depreciates today.  It's not there just because Postal thought
it would be a good idea, it's there because it was the only way to send
mail.  Remember Jon was writing a document that described how to do email
back in 1982, in a world of store&forward and static routing tables.  You
can't apply todays network capabilities to the past, it just isn't relevant.
The source routing functionality (and header rewriting) was added as a
requirement of the cross-network nature of SMTP - You couldn't send mail to
a bitnet host without rewriting the header to provide an addressable return
path in the header.  It is clear with a bit of thought that this
store&forward mechanism cannot scale to come close to the scope of the
internet today, at best it works for several million hosts....

But in 1984, the internet switched to TCP/IP, and DNS was rolled out, and
the whole world changed.  With the existance of a scalable distributed
naming system, the store&forward with routing tables paradigm became
obsolete and was replaced with the DNS/MX paradigm enforced in RFC1123.  And
DRUMS has been tasked with the job of consolidating both RFC1123 and RFC821
together into a single "Internet MTA" standard (and 1123 and 822 to form a
single "Internet Message" standard).

Unfortunately there are a bunch of applications out there (like maildirsmtp)
that ignored the store&forward parts of RFC821 and just implemented the wire
format.  Now that we have a new specification that clearly specifies BOTH
behaviors, people (mostly Dan) are screaming bloody murder that your sort-of
821 applications are also being "forced" to accept all the requirements of
821bis as well including the store&forward requirements.  The problem is
that these applications weren't REALLY fully rfc821 compliant.  For example,
just out of curiosity, what does maildirsmtp do when it recieves a 551 error
code?  Does it actually forward to the other host as required by RFC821?  Or
does it treat it as a 5xx permanent failure?  I strongly suspect the latter.

It may be that the only way of appeasing the "I only care about the wire
format" camp is to split 821bis into two documents, one of which describes
the wire format, the other one which describes the store&forward mechanisms.
But that is a decision that the chair would have to make, because it
radically effects what DRUMS produces.

I suspect that with appropriate wordsmithing we may be able to split out the
wire protocol requirements from the "Internet MTA" requirements within
821bis, however I suspect that this solution may continue to perpetuate the
"I support RFC821 even though I'm not an MTA" camp, and that may not be long
term desirable.

Anyway, once again, I've blathered on far longer than I should have, sorry
about that.

-----Original Message-----
From: D. J. Bernstein [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 3:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: editing status of 821bis, draft -10.

My maildirsmtp program sends messages by SMTP from a local queue to an
address specified by the user. It's part of my serialmail package, used
by many ISPs to transmit mail to dialup hosts, and used by many dialup
hosts to transmit mail to ISPs. serialmail doesn't know anything about
MX records.

Larry Osterman (Exchange) writes:
> the author of the software must put MX
> address resolution in the software package.

So, if that requirement is part of the SMTP spec (against federal law),
then maildirsmtp is violating the SMTP spec---but you say it's no longer
violating the spec if I integrate it into the qmail package?

What if it's available as part of the qmail package, but _also_
available separately? Is the second copy violating the SMTP spec while
the first copy is complying with the SMTP spec?

What if it's still shipped separately, but requires that you install
qmail first? Does that still violate the SMTP spec?

What if it's shipped as part of the qmail package, but the installation
process lets the user discard programs that he isn't using? Does that
violate the SMTP spec?

What if maildirsmtp and qmail are both shipped as part of the system,
and each one can be installed with a single command? Does that violate
the SMTP spec because maildirsmtp can be installed without qmail? What
if qmail is installed from a CD? How about a remote CD? Floppies? What
if the qmail floppy is sold separately from the maildirsmtp floppy?

> (SHOULD is probably sufficient however).

Changing MUST to SHOULD doesn't fix a stupid requirement.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Feb 1999 05:17:54 -0000

Larry Osterman (Exchange) writes:
> And RFC821 defines what it means to be an internet MTA.

Wrong. RFC 821 defines the SMTP protocol.

It's none of your business whether an SMTP implementation is an ``MTA.''
That is a private matter, between the implementor and his users.

What you are proposing is illegal market interference. It exposes both
Microsoft and the IAB to triple damages under antitrust law. Go ask the
American Society of Mechanical Engineers why the Supreme Court forced
them to pay several million dollars to a company called Hydrolevel.

> The problem is
> code?  Does it actually forward to the other host as required by RFC821?

You are making a fool of yourself. RFC 821 does not require what you
claim; it specifically allows bouncing, which is what sane clients do.
This has no relevance to the use of smarthosts.

---Dan