Suricata

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.

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>`