RFC Errata
RFC 2046, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", November 1996
Note: This RFC has been updated by RFC 2646, RFC 3798, RFC 5147, RFC 6657, RFC 8098
Source of RFC: 822ext (app)
Errata ID: 6776
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Brian Antos
Date Reported: 2021-12-05
Section 5.1.1 says:
NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.
It should say:
NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary. The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.
Notes:
Recommend re-introducing the wording from the original RFC (1341) regarding preceding CRLF and the first delimiter line. Current RFC is ambiguous about handling the initial line without it.