Re: 2821bis chapter 2

[John C Klensin <[e-mail]>]

--On Saturday, 03 September, 2005 00:46 +0200 Frank Ellermann
<[e-mail]> wrote:

> 
> Hi, here's a list of my first observations in 2821bis (-00):
> 
> * 2.3 (terminology) [no new issue]
> 
> I prefer the usual style of 2119 keywords with a reference.

The definitions of those terms are different in 2821 than in the
2119 usage, with 2821 following 1123 and related traditions.
The difference is significant.  Please review the DRUMS archives
if you are interested.

> * 2.3.1 (deprectation of SOML SAML SEND) [no new issue]
> 
> s/RCPT TO/MAIL FROM/ - the three S??? FROM commands are an
> alternative of MAIL FROM in STD 10, not RCPT TO.

I wonder how that slipped by.  Fixed.

> * 2.3.4 (numerical addresses)
> 
> 2821 said "discourged", now it's SHOULD NOT (better).  STD 10
> had an obsolete idea of host numbers #<integer> in addition
> to domain literals.

A leftover from pre-IP days, or at least prior to the
distinction between a network part and a local host part of an
IP address.

  IMHO that paragraph needs more clean-up:
> 
> | Hosts are known by names (see the next section); they SHOULD
> | NOT be identified by <address-literals> (see section 4.1.2).
> | Other forms of numerical addresses are deprecated and MUST
> | NOT be used.

I've put the forward pointer in.  DRUMS pretty much decided to
avoid cluttering the 2821 text detailing prohibitions and the
#<integer> form is prohibited in A.6.4.  So, unless others feel
strongly about this, I'm going to leave that last sentence out.

> 2.3.8 Originator [no new issue]
> 
> ?  An "originating" system (sometimes called an SMTP
> originator) ? introduces mail into the Internet or, more
> generally, into a ? transport service environment.
> 
> That's a very tricky statement.  Internet mail is not limited
> to SMTP, and SMTP is (in theory) not limited to the Internet.
> How about this:
> 
> | An "originating" system (sometimes called an SMTP originator)
> | introduces mail into the transport service environment
> defined | by this document, i.e. SMTP in the Internet.

The tricky wording was intentional, given the gateway/relay
family of issues.  It may well be too subtle, but the suggested
replacement text, IMO, narrows things too much.  Comments and
suggestions from others solicited.

> At the end of 2.3.8:
> 
>   [[Note in draft/Placeholder: There has been a request to
> expand this
> 
> Yes, something about gateways acting as SMTP originator.  They
> should not invent a Return-Path to the mail-originator, unless
> they are also the MX and / or it's clearly in the best interest
> of the mail originator.

This is tricky, and, again, more discussion is requested.  I
would suggest that, if the gateway cannot determine a reverse
path (not the header Return-Path, which can be supplied only by
the delivery MTA), then either (i) it has no business injecting
the mail into the SMTP environment or (ii) it is acting, not as
a gateway, but as a submission server.  The fact that the mail
originated on another system, in a different format or protocol,
is almost irrelevant to a submission server, it presumably has,
and follows, its own sender-authorized rules about how to set
the reverse path.   Or perhaps I don't understand what you are
suggesting at all, since there is no way to initiate a mail
transaction without a MAIL command, and there is no valid syntax
for a MAIL command that doesn't contain a reverse-path.

 
> * 2.3.9 typo:  s/2979 [18]/2045 [19]/ but keep 2979 in 2.3.8

Gack.  Fixed.

> * 2.4 (minor nits) [no new issue]
> 
> ? In some commands and replies, arguments MUST follow the verb
> | In some commands and replies, arguments follow the verb

Rephrased.

> ? This is NOT true of a mailbox local-part.
> | This is generally not true of a mailbox local-part.
> 
> The 1024 exceptions are specified elsewhere in the text.  Or
> kill this sentence, the same idea is repeated often enough in
> the text.

Sentence killed.
 
> ? A few SMTP servers, in violation of this specification (and
> RFC 821) ? require that command verbs be encoded by clients in
> upper case. ? Implementations MAY wish to employ this encoding
> to accommodate those ? servers.
> 
> Please remove this, non-conforming servers are out of scope.

Opinions from others solicited, but this is an important
interoperability constraint in the real world and, if I recall,
DRUMS discussed the issue at some lengths. 

> ? receiving SMTP servers MAY clear the high-order bit or reject
> | receiving SMTP servers SHOULD reject
> 
> Good enough to please stupid MUAs.  2821 was way too "liberal".
> We're probably not interested in strange effects for 0x80 etc.

> ? Delivery SMTP systems MAY reject ("bounce") such messages
> | Delivery SMTP systems MAY reject such messages
> 
> Please let's reserve "bounce" for "bounce messages" (NDNs),
> i.e. the client.  If an MDA creates a bounce after the MX
> accepted the crap, then it's almost certainly net abuse.

I'm not quite sure what you are getting at here, partially
because, in the 2821 model, there is no such entity as an MDA.
Note that "bounce" is used again in 3.4 (first bullet after
"Alternately"). And remember that the "subsequent failure" text
in 3.3 and much of section 6 is tied up with the explicit
permission for an receiving MTA to accept all of the RCPT
commands and delivery addresses, accept the message body itself
(DATA...354...CRLF.CRLF... 250) and then bounce (sic) the
message by sending back mail with a null reverse path.

> ? Eight-bit message content transmission MAY be requested
> [...]
> ? encoding; servers MAY reject such messages.
> 
> For obscure reasons the very same concept is often repeated
> several times (and in the same section).  Please delete this
> paragraph, making the text longer by repetitions doesn't help.

The "obscure reasons" are too much slicing, dicing, and pasting.
Your general observation is certainly true, and I'd appreciate
more pointers to redundant text that can be replaced by
cross-references or removed entirely.  But I'm not sure I see
the redundancy here:

	Paragraph 6 of Section 2.4 ("Commands and replies are
	composed...") say that unextended mail transactions must
	not send 8bit information at all.  It could use a
	forward reference to paragraph  7, which I have
	inserted.   Given other work now going on (see, e.g.,
	draft-klensin-emailaddr-i18n-03, the expired
	draft-hoffman-utf8headers-00, or draft-lee-jet-ima-00),
	it might even be wise to modify the initial sentence in
	that paragraph to make the "unless extended" distinction
	clear there too.
	
	Paragraph 7 ("Eight-bit message content
	transmission...") then talks about the specific 8BITMIME
	extension.  If one were a purist, one could argue for
	removing that because it really is and extension and not
	an base SMTP problem.  But its use is recommended, it is
	widely supported today, and it does imply changes to the
	transport environment, so leaving it in seems
	appropriate.

> ? The metalinguistic notation used in this document corresponds
> [...]
> ? are surrounded by pointed brackets (e.g., <CRLF>) for
> clarity.
> 
> That paragraph should be section 1.3, not the end of chapter 2
> near page 17,  With pointers to 2234bis and 2119 in chapter 1
> all explanations of CRLF, CR, LF, MUST, MAY, etc. in chapter 2
> could be eliminated.

I agree that it would be better to move that text.  Let me see
what I can do with it.  See above for the 2119 issue.

> What I really wanted was to create some kind of "collected
> ABNF" for 2821bis, so I better stop my nit-picking here at the
> end of chapter 2 (jumping to the ABNF in chapter 4 in another
> article).

Ok.  But note that, given the ABNF errors that have been found
in 2821 (and in 2822) after careful checking by multiple people,
you should expect to encounter some resistance to any sweeping
changes or sets of equivalent productions.  If they clarify
things enough they may be worth making, but the clarification
advantages have to be balanced against the risk of making new
sets of errors.

> Generally:  The default SMTP use today is "spam", abuse, and
> spam-related messages (bogus bounces etc.).  Therefore the
> default action in any case of doubt MUST be "reject a.s.a.p.".

Frank, I don't know how, or if, either of us is going to
persuade the other, but I'm operating under three assumptions
with this draft and will continue to do so unless the ADs or
some appropriately-chartered WG tells me otherwise.  Those
assumptions are:

	(i) The goal of this revision effort is to clean up
	errors and bad text to the extent necessary to move
	2821bis forward to Draft Standard.  This is not a
	"revise SMTP" or "change mail philosophy" effort.
	
	(ii) The ground rules for this effort are the same as
	those for DRUMS, i.e., clarification and consolidations
	of the base specifications and documentation of
	contemporary practice consistent with those
	specifications, not insertion of new features or ways of
	doing things.

Those two assumptions are obviously closely related to each
other. The third very nearly follows from the other two, but is
a statement about philosophy:

(iii) Whether via extensions or other add-ons, changes in
operational practices, or changes in laws and consequent
enforcement, we will get the spam and abuse situations under
control.  When we do, we will still want a mail system that is
optimized for the efficient and reliable delivery of email.
Such a system tries to deliver messages and reliably report what
cannot be delivered.   It is designed around very high
expectations that a legitimate user, even an anonymous one,
sending interpersonal mail to a legitimate user or mailbox, will
see that mail delivered, and delivered quickly.  It does not
look for excuses to discard messages because they do not conform
to one rule or another.  Changing the base SMTP specification in
significant ways to accommodate the short-term battle against
spam or other forms of abuse in ways that violate those
assumptions is pathological because, on one hand, it gives us a
damaged mail structure forever. Conversely, if the hypothesis
that we will get the present situation under control is false,
SMTP modifications are not going to be sufficient: we will need
a permission-based, or rigid-authority-based, mail system and
SMTP will die regardless of what tuning-level changes are made
to it.

regards,
    john