RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 6152, "SMTP Service Extension for 8-bit MIME Transport", March 2011

Source of RFC: yam (app)

Errata ID: 5646
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: HE Zhixiang
Date Reported: 2019-03-04
Rejected by: Barry Leiba
Date Rejected: 2021-03-01

Section 3 says:

Naturally, the usual SMTP data-stuffing algorithm applies, so that a
content that contains the five-character sequence of
<CR> <LF> <DOT> <CR> <LF>
or a content that begins with the three-character sequence of
<DOT> <CR> <LF>
does not prematurely terminate the transfer of the content.

It should say:

Naturally, the usual SMTP data-stuffing algorithm applies, so that a
content that contains the five-character sequence of
<CR> <LF> <DOT> <CR> <LF>
or a content that begins with the three-character sequence of
<DOT> <CR> <LF>
would prematurely terminate the transfer of the content.

Notes:

RFC 5321, section 4.5.2:
Without some provision for data transparency, the character sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent by the user.
--VERIFIER NOTES--
The text is referring to original, unprocessed text, and is saying that the example strings will "naturally" have "the usual SMTP data stuffing algorithm" applied to them. As a result, the existence of these strings in the original data will not terminate the transfer because they will be data-stuffed and will no longer appear as termination strings.

The text is correct as written, and the suggested rewrite incorrectly negates the meaning.

Report New Errata



Advanced Search