Subject: Editing changes/status 821bis, draft 10

From: John C Klensin <[email-masked]>
Date: Fri, 26 Feb 1999 10:51:43 -0500

i.

draft-ietf-drums-smtpupd-10.txt has just gone to the I-D editor.
It contains the changes for which consensus and clarity could be
distilled from the comments on the list.  Omission of something
implies that there still did not appear to be a clear consensus
about what should be done or that it simply got lost in the
[considerable] noise of a (perhaps unintentional) denial of
service attack on the WG and its mailing list.

The most controversial of the discussions apparently hinged
around a misunderstanding of what 821bis intended to say about a
reduced-functionality (or reduced-environment) client sending
all outgoing traffic to a single relay.  There was never any
intention to prohibit this behavior; the question was whether it
was covered by, or relevant to, the standard specification.  On
the grounds that things about which many people have become
confused (here, whether the "relay everything to..." behavior is
prohibited) ought to be clarified, new text has been added to
the document (important part included below).  That text should 
be treated as a strawman --alternative wording would be 
welcomed-- but is based on the following assumptions:

  * As soon as we say things like "reduced functionality", or
     "restricted environment", or "dumb client", it is reasonable
	 to have such clients be treated as partially conforming,
	 rather than fully conforming, to the Internet SMTP
	 specification. 

  * The requirement that MX records be used to resolve names is
    inherent in Internet uses of SMTP and has been since before
	1123 (and is specified there).  Non-Internet uses of SMTP
	are not relevant to, or covered by, this document.  It seems
	to me, following some of the discussion on the list, that it
	would be entirely appropriate to modify the Submission
	protocol to permit other forms of name resolution but that
	permitting arbitrary SMTP clients to make unpredictable
	choices about name interpretation would weaken the
	infrastructure and reduce interoperability.

  * The notion of using a single relay for everything is bound,
    especially in these days of spam controls, to an agreement
	between the "dumb" client and the relay server.  (That
	relationship is exactly why the specification didn't
	previously say anything about this). I've deliberately left
	the nature of such an agreement unspecified, but
	customer->ISP and corporate-network-user-> corporate-relay
	are clearly examples of them.  Perhaps "you have an SMTP
	server and didn't prohibit me from relaying through it" is
	another such case.    Anyone who thinks it needs further
	clarification should suggest some text. 

As part of this, I've changed "DNS lookup is performed" to "DNS
lookup MUST be performed" at the beginning of section 5.  This
is, I believe, consistent with WG discussions as well as 1123,
and makes the text hold together better.  In the 3.7 text
(below), I've left the requirement at a SHOULD for these

originating clients.  Happy to be talked out of that.

-----------------

Section X.1.10 (the change list) of the document now contains:

   X.1.10. Substantive changes between draft-ietf-drums-smtpupd-09.txt
   and draft-ietf-drums-smtpupd-10.txt.

   (i) A large series of typos, most of them caught by Philip Hazel,
   corrected. 

   (ii) Residual problems with references to mailboxes, forward, and
   reverse paths in 4.1.1.2 and 4.1.1.3 corrected and some text, I hope,
   clarified.

   (iii) Text added to 4.2.5 to talk about 5yz errors after DATA.  This
   text should be checked carefully -- it is a proposal and may or may
   not reflect WG consensus.

   (iv) Upper bound on "seconds" has been changed to 60 (not 61), per
   list discussion.  Years are still four-digits and will stay that way
   unless the list discussion converges on something else.  The increase
   to 60 seconds includes an explicit note about leap seconds.

   (v) Text has been inserted to reflect the Orlando consensus about "QUIT",
   i.e., the client MUST send a QUIT command and SHOULD wait for the results
   before closing the connection.  Servers are still not permitted to close
   without receiving a QUIT and sending a 221 response (except, of course,
   under the usual "unavoidable circumstances", in which case they should get
   off a 451 if that is feasible).

   (vi) The EHLO response specification has been changed back to reflect
   non-advertisement of VRFY and some text implying that VRFY was optional to
   support has been removed (WG consensus seemed to be moving in that
   direction at one point, and the editor reacted prematurely).  This makes
   the text compatible with RFC1869 and restores VRFY to its RFC1123 status.

   (vii) The text in section 5 has been clarified with regard to what a relay
   that receives a message because of its designation as an MX can do and 3.7
   has been slightly modified to point to it.

   (viii) New text has been added to 3.7 to clarify the use of "SMTP server"
   relays in "dumb" originating clients.  See below.

   (viii) Small wording changes inserted into 4.1.4 (e.g., insertion of ", if
   possible," into the first sentence of the fifth paragraph to eliminate the
   apparent conflict with the second sentence).

-------------------------

New 3.7 text (strawman):

	 A relay SMTP server may be encountered in one additional
	 circumstance: by private agreement between an originating
	 client SMTP and an associated SMTP relay, the client MAY be
	 configured to send all mail to that relay for further
	 processing.  In conformance with this specification and
	 other Internet Standards and guidelines, the relay SMTP
	 SHOULD be configured into a client of this type by name
	 (rather than by IP address), and the name SHOULD be
	 processed as described in section 5.  Clients of this sort
	 will rarely be fully-conformant to this specification
	 since, in most cases, the use of a single relay for all
	 outgoing mail traffic is used as an alternative to such
	 requirements as the one to retry mail delivery on
	 connection failures.

Also added to 3.7 to clarify another argument-producer:
 
	 It is important to note that MX records can point to SMTP
	 servers which act as gateways into other environments, not
	 just SMTP relays and final delivery systems; see sections
	 3.8 and 5.

---

From: [email-masked] (Kai Henningsen)
Date: 01 Mar 1999 20:27:00 +0200

[email-masked] (John C Klensin)  wrote on 26.02.99 in <[email-masked]>:

> 	 processed as described in section 5.

It is not clear to me that ISPs actually *want* clients to do MX  
processing on outgoing SMTP server names, instead of simply using A  
records.

In fact, this means that if these servers are not to be used for incoming  
mail at all - a reasonable construct for larger ISPs - then the ISP has to  
do split DNS, where his customers see different MX records than the rest  
of the world does (so that mail addressed to these servers from the  
outside will not actually go to these servers, but to the incoming SMTP  
servers instead).

What do other people think?

MfG Kai

---

From: Robert Elz <[email-masked]>
Date: Tue, 02 Mar 1999 16:22:06 +1100

Date:        01 Mar 1999 20:27:00 +0200
    From:        [email-masked] (Kai Henningsen)
    Message-ID:  <[email-masked]>

  | It is not clear to me that ISPs actually *want* clients to do MX  
  | processing on outgoing SMTP server names, instead of simply using A  
  | records.

I'd suspect this is true - I'd also say that they don't want their clients
using SMTP at all in many cases.  What they want is for the client's mail
to be dropped in their mail relay for them to deliver (some may even allow
the mail to be dropped by various schemes, including uucp, etc).

That one of the dropping schemes is a protocol whose elements look quite
a bit like SMTP does not make it be SMTP.

For SMTP, MX should be mandatory.   For cients talking to their ISP's
mail relay, MX should be avoided in general (and so should calling what they're
using SMTP).

kre

---

From: Philip Hazel <[email-masked]>
Date: Tue, 2 Mar 1999 08:41:43 +0000 (BST)

> mail relay, MX should be avoided in general (and so should calling what they're

I've said this before: I believe that there is absolutely no way you 
will get people *not* to call what they're using SMTP. Human language is 
like that. The term is in common usage, and once that happens, you can't 
claw it back. 

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