Re: [ietf-822] [Editorial Errata Reported] RFC5322 (3400)

[Keith Moore <[e-mail]>]

IMO:

1. A message can be legal without a CRLF at the end.   However,

2. If the message doesn't end with CRLF, there's no way to transfer it 
using SMTP /DATA/ without modifying the message.   (note the emphasis on 
DATA)

3.  Similarly, any message received via SMTP DATA already has a CRLF at 
the end, so there's no ambiguity concerning the last line of a message 
when dealing with any message received using SMTP DATA.  The receiver 
has to assume that the terminating CRLF (before the '.CRLF') was part of 
the original message.

4. A message not ending in CRLF could be transmitted via other means, 
e.g. using SMTP BDAT if the MTA supports it, or any other suitable 
message transfer protocol.   More generally, use of Internet Message 
Format is not limited to SMTP.

However, if the receiving MTA then tried to relay the message to another 
MTA that didn't support BDAT, or to relay or deliver it to any 
environment (e.g. mbox format) that expected messages to consist 
entirely of terminated lines of text, results are more-or-less 
undefined.   The message could be modified to cause it to end in a 
terminated line (with or without changing the content represented by the 
message), or it could be bounced.

Note that there are corner cases where simply appending CRLF could do 
harm, e.g. a MIME message consisting of a single quoted-printable body 
part and a filename specified via the Content-Disposition header field - 
e.g. some sort of application-specific data that needed to be preserved 
end-to-end. In such a case it would make more sense to re-encode the 
message body in base64 than to simply append a CRLF.   But this seems 
out-of-scope for 5321.   If anything needs an erratum explaining this, 
it's RFC 3030.

Conclusions:

1. It seems reasonable to add an erratum to 5322 recommending that 
messages, as originated, end in CRLF, unless it is known that the 
message can be transmitted from sender-to-recipient without loss of full 
binary transparency.

(Note that there are lots of things that are perfectly valid according 
to 5322 which are unlikely to work well in practice, and which would 
probably also be recommended against if anyone took the trouble to try 
to identify them and file errata for them.)

2. It's reasonable, during mail submission only, for a submission server 
or MTA to EITHER adapt a message that doesn't end in CRLF so that it 
does, OR bounce the message, according to local policy.   But as far as 
SMTP is concerned, this is only relevant if BDAT is used to submit the 
message.   So it's really not in scope for RFC 5321.

3. When relaying mail (past the first hop), the issue comes up only when 
either BDAT or a nonstandard protocol or protocol extension are used.    
So again, it's not in scope for 5321.

4. It might be worthwhile to examine RFC 3030 for errata along these lines.

Keith

On 11/27/2012 06:02 PM, Pete Resnick wrote:
> [Bcc'ed to [e-mail]; please discuss over on [e-mail].]
>
> Folks,
>
> The following erratum was posted for 5322. I'm inclined to reject it 
> since this discussion actually took place during DRUMS (17-18 March 
> 1998 in a thread with a subject of "Small Clarification to msg-fmt-04" 
> if you are inclined to look) and the consensus outcome as far as I 
> could tell (as document editor) was that messages without a final CRLF 
> were SMTP's problem. However, 5321 (and 2821) 4.1.1.4 says:
>
>    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 (see Section 4.5.2).
>    This is the end of mail data indication.  The first <CRLF> of this
>    terminating sequence is also the <CRLF> that ends the final line of
>    the data (message text) or, if there was no mail data, ends the DATA
>    command itself (the "no mail data" case does not conform to this
>    specification since it would require that neither the trace header
>    fields required by this specification nor the message header section
>    required by RFC 5322 [4] be transmitted).  An extra <CRLF> MUST NOT
>    be added, as that would cause an empty line to be added to the
>    message.  The only exception to this rule would arise if the message
>    body were passed to the originating SMTP-sender with a final "line"
>    that did not end in <CRLF>; in that case, the originating SMTP system
>    MUST either reject the message as invalid or add <CRLF> in order to
>    have the receiving SMTP server recognize the "end of data" condition.
>
> Allowing the originating SMTP system to reject the message as invalid 
> seems in conflict with 5322 on this point. So my rejecting this 
> erratum will simply end us up with an erratum against 5321.
>
> I'm inclined to hear opinions.
>
> pr
>
>> The following errata report has been submitted for RFC5322,
>> "Internet Message Format".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=5322&eid=3400
>>
>> --------------------------------------
>> Type: Editorial
>> Reported by: Christoph Anton Mitterer<[e-mail]>
>>
>> Section: 3.5.
>>
>> Original Text
>> -------------
>>     message         =   (fields / obs-fields)
>>                         [CRLF body]
>>
>>     body            =   (*(*998text CRLF) *998text) / obs-body
>>
>>
>> Corrected Text
>> --------------
>>     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.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC5322 (draft-resnick-2822upd-06)
>> --------------------------------------
>> Title               : Internet Message Format
>> Publication Date    : October 2008
>> Author(s)           : P. Resnick, Ed.
>> Category            : DRAFT STANDARD
>> Source              : IETF - NON WORKING GROUP
>> Area                : N/A
>> Stream              : IETF
>> Verifying Party     : IESG
>