Project

General

Profile

Bug #5316

Updated by Shivani Bhardwaj over 2 years ago

*Issue* 
 An edge case where <CRLF> came in fragmented for a line was not handled. This resulted in <CR> being treated as regular data byte and not as a part of the line end sequence. This particularly led to issues when base64 encoded data was processed by MIME and it could not handle the <CR> char as it relied on only receiving correct data from SMTP parser making file sizes different and inconsistent. parser. 

 *Context* 
 As per RFC 2821 (SMTP), 
   a. Bare `CR` and `LF` have a long history of problems w mail implementations and applications. 
   b. An ideal SMTP client MUST NOT transmit `CR` and `LF` chars except when they are intended as line terminators and then also as `<CRLF>` sequence ONLY. 
   c. We should tolerate trailing `SP` before the terminating `<CRLF>`

Back