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

From: John C Klensin <[email-masked]>
Date: Thu, 11 Feb 1999 19:50:45 -0500 (Eastern Standard Time)

On Fri, 05 Feb 1999 14:04:36 -0500 Barry Leiba 
<[email-masked]> wrote:

> I need a clarification in this regard:  What is our goal?  Is it
> (1) to document existing behaviour, and, in the process, to tighten up the
> spec -- with the stipulation that any implementation that was technically 
> compliant with RFC821 will be technically compliant with RFC821bis -- or
> is it

> (2) to document what the intended and desirable behaviour is, taking existing
> behaviour into account, but accepting that implementations that met the letter,
> but not the intent, of RFC821 might not be technically compliant with RFC821bis?
> 
> I think our goal *should be* (2).  If, in fact, our goal is (1), then perhaps
> the various arguments stating, "You can't change [this] because the change would
> make [some implementation] technically non-compliant," are correct.  OTOH, if
> our goal is (2), then perhaps it's a Good Thing to say, "We know that this
>...

I was hoping that Keith, Patrik, or Chris would take this 
one, but since they apparently haven't, let me venture a 
personal opinion not "as", but from the perspective of, 
editor, someone who was still on IESG when we started 
discussing the need for DRUMS, and who participated in the 
effort that led to RFC 1123.    

The goal was (2).  In addition to the reasons you cite, 
Internet email practice has changed since 821 was written 
and even, arguably, since 1123 was completed.   To take 
what I hope are some non-controversial examples, we 
should no longer tolerate implementations that have no idea 
how to use the DNS or to do MX resolution but that are 
forced to use host tables.  Similarly, 1123 started the 
process of deprecating source routes and 821bis has taken 
further steps along that path.  But one can conform to a 
narrow reading of 821 using host tables, and must support 
source routes for compliance.

Where it seems to me that the sensitive issues about 821bis 
should reasonably lie are, again using those examples:

  -- should we try to outright prohibit clients or servers 
     that do name resolution other than through the DNS?
  -- should we simply prohibit source routing, or express 
      some preferences but retain implementation 
      flexibility since it doesn't have huge 
      interoperability implications as long as the 1123 
      rule that all names be DNS-resolvable is followed?

My reading of the current WG consensus (which I hope is 
adequately reflected in the draft) is that the answer to 
the first is "no" (not detectable on the wire and some 
non-conformant _use_ of otherwise-conformant _software_ may 
be perfectly sensible) and "preserve the flexibility".  And 
I think those positions are consistent with each other and 
with the general spirit of your option 2.

It is a plan that may leave us with some SMTP 
implementations that we consider "contemporary" and that, 
hence, conform to 821bis and support some range of current 
capabilities and some that are "legacy" or "historic" or 
"minimal" and that conform only to 821 and its intermediate 
successors through 1123.  I don't see that as particular 
harmful, although it certainly doesn't represent a perfect 
world.

>Suppose there's a program that asks, "Do you really want to wipe your
> hard drive?  (Reply 'y' or 'n'.)"  Would you be pleased 
> if that program responded to the answer 'm' by assuming 
> you meant 'y'?  I know I wouldn't.

This is, I think, a special case of the principles of 
minimizing astonishment and causing as little harm as 
possible, both of which I've always found to be useful 
principles of protocol and program design.   It would, of 
course, be even worse if an SMTP client responded to a 1yz 
code from a server by quietly wiping the hard drive: 821bis 
doesn't _prohibit_ that behavior, but that neither makes it 
desirable that a client do it and claim that it is just 
conforming to flexibilities allowed by the spec nor that 
they spec should be required to have text prohibiting the 
case.  It would just be wrong to have such an 
interpretation.

    john

---

From: Brad Knowles <[email-masked]>
Date: Fri, 12 Feb 1999 10:02:55 +0100

>     that do name resolution other than through the DNS?

    I would say that the answer to this question is "depends".

    If we're going to handle message submission by "dumb" clients as part
of this document, then yes (although I think it should be in a separate
section).

    If we're going to handle message submission in a separate document,
then I would say no -- MTAs should be at least minimally intelligent
enough to use the DNS and MX records, etc... although I don't believe
that we should expect the same of MUAs.

>      rule that all names be DNS-resolvable is followed?

    I would discourage source routing in the strongest terms possible. 
MTAs should certainly strip source routes and compare the result after
stripping, and they should be allowed (or perhaps even encouraged) to
outright refuse to accept messages with source-routed envelope addresses
if they don't implement stripping.

    Of course, they should also be explicitly allowed to refuse (either
permanently or temporarily, although I would encourage the latter in the
strongest terms possible) to accept messages that have envelope sender
addresses whose domain portion cannot be found in the DNS.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit