RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5322, "Internet Message Format", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 3400
Status: Rejected
Type: Editorial

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.

Report New Errata