2822upd-04 section 2.3 reads in part:
o CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body.
This makes me uneasy for several reasons:
1. it bucks the trend at liberalizing body content (e.g. 8BITMIME and BINARY
2. it (together with the disclaimer that appears further down the page)
implies that MIME messages do not conform to the IMF specification,
which is counter to the intent of MIME.
3. the use of RFC 2119 terms implies that MIME messages used with extended
SMTP transport cannot interoperate; that impugns a great deal of careful
work to ensure that ESMTP negotiation and MIME are backward-compatible.
2822upd-04 section 4.1 reads in part:
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
text is defined in section 3.5 as:
text = %d1-9 / ; Characters excluding CR
%d11 / ; and LF
Together they handle only half of what can appear in a MIME
application/octet-stream body transported via ESMTP BINARY transport, viz.
0x00-0x7f (with no CRLF restriction), but not 0x80-0xff.
obs-body (i.e. parsing requirement) really ought to include 8-bit content
(N.B. that's body, not header field, content). And the section 2.3 text
quoted above (and its companion text dealing with "line length") ought to
be elaborated upon to explicitly state that it applies only to generation
(not parsing requirements, for which it is directly contradicted by the
obs- grammar) of non-MIME, i.e. implicitly text/plain us-ascii body content.
Note that 2822upd-04 section 1.2.3 reads in part:
Section 2 lays out the general description of a message and its
constituent parts. This is an overview to help the reader understand
some of the general principles used in the later portions of this
document. Any examples in this section MUST NOT be taken as
specification of the formal syntax of any part of a message.
N.B. that says nothing about generate-only; it states (by lack of explicit
limitation) that the section 2.3 text applies to parsing as well as
Related issues appear in sections 2.1 (limited to ASCII 1-127, divided into
lines) and 2.1.1 ("line" length limits).