ietf-smtp
[Top] [All Lists]

Re: 2821bis chapter 2

2005-09-03 09:01:26



--On Saturday, 03 September, 2005 00:46 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> 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

<Prev in Thread] Current Thread [Next in Thread>