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

From: Philip Hazel <[email-masked]>
Date: Mon, 15 Feb 1999 09:45:58 +0000 (BST)

On Fri, 12 Feb 1999, John C Klensin wrote:

>   (i) Standardized lookup of a DNS name
>   (ii) Deprecated standard lookup in a host table
>   (iii) Local coding of an IP address
>   (iv) Magic

...

> That leaves (i) and (ii).  The language of 1123 says, more or 
> less, that it a client is to claim to be (or include) a 
> conforming SMTP implementation, it must support (i).  The 
> question is whether it is useful or desirable to try to prohibit
> (ii) (or even (iii) and/or (iv) for that matter).

This is what bothers me. I kind of feel that people think of SMTP as a 
protocol for tranferring messages between two hosts - certainly I do - 
and it bothers me that the means of determining which host to send to is 
being "bundled" with the definition of the transfer protocol. I'd have
no problem with a statement of the form "A fully-conformant Internet MTA
MUST conform to the SMTP specification AND must support full DNS/MX
lookup." You could even replace "Internet" with "RFC 821bis" in there,
though I suspect people will describe it as "the SMTP RFC" nevertheless.

I predict that people will continue to talk about "using SMTP" to
transfer messages between hosts whose identities are determined in all
sorts of ways, whatever the RFC says.

> I suspect that the pragmatic answer to the second one of these 
> is that we don't have the energy to reach consensus on text.  

I fully agree with that!

> Now, are we in disagreement?  I  can't tell.

If we are, I don't think it is by very much.

Philip

-- 
Philip Hazel            University of Cambridge Computing Service,
[email-masked]      Cambridge, England. Phone: +44 1223 334714.

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Feb 1999 17:22:39 -0500

> though I suspect people will describe it as "the SMTP RFC" nevertheless.

One really can't do it that way, because there are no non-email 
documents that describe how MX resolution works.  We could, in 
principle, have decided to do a separate update to RFC974, or to
not update it.  The latter would have been a mistake, IMO, since
974 is a little tentative about some things that we had to 
update in 1123, leaving us in exactly the state that DRUMS and 
821bis were supposed to fix.  And there was very clear consensus
early in the DRUMS work that 821bis was supposed to consolodate,
at least, 821, 974, the mail transport-related sections of 1123 
and the framework of the ESTMP materials.

Moreover, an SMTP server or relay has forward-pointing addresses
delivered to it in domain name form.  How it figures out what to
do with them -- and which "next hop" host to which to open a 
connection -- is really very much part of the protocol.  I.e., 
the protocol doesn't start after the connection is opened.

So I just don't see a way to do what you are suggesting.  

> sorts of ways, whatever the RFC says.

For a relay, the answer is pretty clear.  The question, as you 
and others have suggested, is how much it is desirable to split 
out the "submission" piece.   Note that at the time 821 was 
written, this was pretty clear: we didn't specify _at all_ the 
mechanisms by which a message was transferred from an 
originating MUA to the first-hop MTA, nor what information went 
along with it.   And that MTA was required to follow _all_ of 
the rules.   Now, with split-UAs and other excuses for "dumb 
clients", we have things that aren't quite SMTP-capable (and, 
occasionally, not even quite 822-capable) generating messages 
and sending them off --for relaying and tidying up-- to "real" 
SMTP Servers using some approximation to SMTP.  

We can pretend those cases don't exist, or we can try to hold 
them to the rules.  After having been around that loop a few 
zillion times, my personal conclusion at this state is that we 
should try to specify a relatively high standard.  If a POP3 
client is only "partially conforming" to the SMTP standard when 
it sends mail, that doesn't bother me very much and may be just 
the right thing: it can't requeue messages, it can't generate 
proper NDNs, etc.  For that reason, we could go with "relays 
and destination servers MUST and originators SHOULD" language if
the WG feels that would help.  But we should, IMO, be clear on 
whether an originator is expected to have support for (and, 
presumably, under normal circumstances, to use) MX resolution on
a name given it as the local relay/ SMTP server.  Clearly it 
doesn't do that if it the user keys in an IP address.  And it 
might be sensible, in some circumstances, for the software to 
have a provision to go to A RRs only.  But we either expect MX 
resolution to be there or we don't, and I still don't have a 
clear sense of WG desires on that matter.

     john