[Top] [All Lists]

Re: 2821bis chapter 2

2005-09-03 09:24:49

Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

* 2.3 (terminology) [no new issue]

I prefer the usual style of 2119 keywords with a reference.

   Anything else leaves the reader wondering why 2119 reference
wasn't used. (The document is quite hard enough to read without
adding challenges like this...)

* 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.  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 tend to agree: I think we can go to "MUST NOT" for any numerical
addressing except <address-literal>; and <address-literal> deserves

   (I do not mean to say that we can require much about the names used
in HELO: I merely mean that a HELO name should introduce _some_
information (however slight) beyond the IP address we already know.)

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.

   I don't think this helps. Inevitably, the reader will stumble on
"transport service environment": better IMHO that this term be
introduced after a more familiar idea is stated.

At the end of 2.3.8:

[[Note in draft/Placeholder: There has been a request to expand this
] section, possibly into a more extensive model of Internet mail.
] Comments from others solicited.]]

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.

   IMHO, this section would be a poor place to go into such detail.
Here we should limit ourselves to what a gateway _is_ (which probably
needs a discussion of its own): not what a gateway may or may not do.

* 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

   (Frank would do well to make his intent clear _without_ the reader
needing to hunt down the text he's referencing.)

   John Klensin's draft includes the "MUST": I don't understand what
Frank dislikes about it.

? This is NOT true of a mailbox local-part.
| This is generally not true of a mailbox local-part.

   Context is even harder here: the draft is discussing the need to
preserve case in the <local-part> for the "delivery" system to
interpret. I find John Klensin' text (with the unconditional "NOT")
easier to read.

The 1024 exceptions are specified elsewhere in the text.  Or kill
this sentence, the same idea is repeated often enough in the text.

   I do agree with Frank that the whole sentence could be deleted.

? 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.

   I quite agree with Frank that what to do about non-conforming servers
should be out-of-scope for this document. Discussion of such problems
_is_ very helpful to implementors (or, more generally, to anyone working
on possible extensions), but 2821bis should be the spec, not a best-
practices document.

? receiving SMTP servers MAY clear the high-order bit or reject
| receiving SMTP servers SHOULD reject

   (This is in a discussion of what to do about non-ASCII characters.)

Good enough to please stupid MUAs.  2821 was way too "liberal".
We're probably not interested in strange effects for 0x80 etc.

   Again, we're stuck worrying about non-compliant clients and servers.
In this document, we should limit ourselves to whether a server which
receives non-ASCII characters MAY pass them on: anything beyond that
belongs in a best-practices document.

   (BTW, I don't think John Klensin's draft is clear enough on that

? 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.

   We might be better to avoid the "bounce" term altogether. In my
experience, "bounce" is _often_ misunderstood. It's easy enough to
say "reject with a 5xx error" or "generate a NDN"; and I recommend
doing so to avoid confusing the reader.

? 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.

   I find none of these "repetitions" helpful. Non-ASCII characters
violate the spec: there should be no need to say "MAY reject". If
there is any need to refer to 8BIT extension(s), I think it would
be better handled in an Appendix.

? 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 quite agree. It's _extremely_ easy to miss this statement at
the end of chapter 2.

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.".

   Though I agree with Frank here, all such discussion belongs is a
best-practices document.

   ... with one exception: IMHO we need to remove any obligation
to generate NDNs to addresses which are reasonably believed to be
unrelated to any author or sender of the email in question.

John Leslie <john(_at_)jlc(_dot_)net>

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