Subject: [Emailcore] "Beginning of the ..." in RFC 5321

From: John C Klensin <[email-masked]>
Date: Sun, 14 Feb 2021 20:07:11 -0500

Hi.

I just noticed that the first paragraph of Section 4.4 of RFC
5321 (and 5321bis) contains the phrase "at the beginning of the
message content" while the fifth full paragraph of that section
(starting "When the delivery SMTP server makes the "final
delivery...") uses "at the beginning of the mail data...".

That is correct given Section 2.3.9, which explicitly says that
"message content" and "mail data" are used interchangeably (and
hence that they are equivalent).  It occurs to me that a causal
reader, seeing the two in the same section, might assume that
they were different, that "message content" referred to the
material after the message header fields, and then get badly
confused.

The "minimal changes" principle requires not looking for places
to change.  On that principle, this is probably best left alone.
However, if someone sees enough possibility of confusion to
justify changing 4.4 and the several other places where "message
content" appears and then adjusting 2.3.9, this would be a good
time to ask that a ticket be opened.

One of the places that might be changed is the sixth paragraph
of Section 2.4 (starting "8-bit message content
transmission..."), which is arguably not completely clear that
8BITMIME does not allow non-ASCII characters in header fields.
If anyone is uncomfortable about that (whether we get rid of
"message content" terminology or not), again, ask that a ticket
be opened and, ideally, suggest text.  FWIW, if we wanted to
make a comment about SMTPUTF8, that paragraph would probably be
the right place to put it because doing so would make the
distinction perfectly clear.

   john
   (picking nits before someone else gets to them)

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Feb 2021 12:49:43 +0100

> delivery...") uses "at the beginning of the mail data...".

I think both terms are very clear.  "Mail data" obviously refers to the DATA 
command, while "message content" is the perfect companion of terms like 
"message envelope", "message header", and "message body".

> material after the message header fields, and then get badly

Section 2.3.9 seems to imply that the message content has to consist of a 
header and a body.  That becomes contradictory with having "carefully avoided 
imposing any requirement that an MTA (or SMTP sender or receiver) inspect and 
evaluate, or even know how to parse, message headers", as you wrote[*].  If 
that principle is useful, it should be reaffirmed here.

The last paragraph of Section 2.3.1 is confusing.  I propose changing it:

OLD:
    The SMTP content is sent in the SMTP DATA protocol unit and has two
    parts: the header section and the body.  If the content conforms to
    other contemporary standards, the header section consists of a
    collection of header fields, each consisting of a header name, a
    colon, and data, structured as in the message format specification
    (RFC 5322 [11]); the body, if structured, is defined according to
    MIME (RFC 2045 [24]).  The content is textual in nature, expressed
    using the US-ASCII repertoire [2].  Although SMTP extensions (such as
    "8BITMIME", RFC 6152 [47]) may relax this restriction for the content
    body, the content header fields are always encoded using the US-ASCII
    repertoire.  Two MIME extensions (RFC 2047 [25] and RFC 2231 [28])
    define an algorithm for representing header values outside the US-
    ASCII repertoire, while still encoding them using the US-ASCII
    repertoire.

NEW:
    The SMTP content, also known as message content or mail data, is sent
    in the SMTP DATA protocol unit and usually has two parts: the header
    and the body.

[*]
https://mailarchive.ietf.org/arch/msg/emailcore/RgPrJD7X9vtlxyIUZ6bfQ-_31F0/

> time to ask that a ticket be opened.

I think that text is good as is.

> distinction perfectly clear.

Yes please!  Given that the spec mentions 8BITMIME, mentioning also SMTPUTF8 is 
absolutely deserved.  Also in the examples D.1 - D.4.

Best
Ale
--