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.
* 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.
* 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.
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.
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.
* 2.3.9 typo: s/2979 [18]/2045 [19]/ but keep 2979 in 2.3.8
* 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
? 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.
? 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.
? 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.
? 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 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.
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).
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.".
Bye, Frank