RFC Errata
RFC 5322, "Internet Message Format", October 2008
Note: This RFC has been updated by RFC 6854
Source of RFC: IETF - NON WORKING GROUPArea Assignment: app
Errata ID: 3400
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christoph Anton Mitterer
Date Reported: 2012-11-06
Rejected by: Pete Resnick
Date Rejected: 2012-12-10
Section 3.5. says:
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
It should say:
message = (fields / obs-fields)
[CRLF body]
body = (*(*998text CRLF) *998text) / obs-body
It is RECOMMENDED that message bodies are terminated by CRLF, though
this is in principle not necessary (this does not apply to messages
consisting only of a header section, as header fields are always CRLF
terminated).
Note however, that when transporting messages via SMTP the last lines
of message bodies MUST be terminated by CRLF as specified int
RFC 5321, section 4.1.1.4.
Notes:
Hi folks.
AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.
RFC5321 section 4.1.1.4. however states: "The mail data are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line".
So SMTP forbids, what this RFC allows.
I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.
My suggestion was to add this clarification.
Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't need the last CRLF.
--VERIFIER NOTES--
It is clearly a change from WG consensus to add any normative 2119 text regarding a terminating CRLF. (See archive of the DRUMS WG, 17-18 March 1998 in a thread with a subject of "Small Clarification to msg-fmt-04".) The CRLF is not required for the message syntax. There are things other than this that 5321 cannot transport, so is also unlikely to be in scope for 5321 as an erratum either. Perhaps a discussion of this might be useful for RFC 3030, but again, it is unlikely to be an erratum.