https://www.rfc-editor.org/rfc/rfc5322#section-2.1.1
The LCR system, and more specifically a component that identifies itself2.1.1. Line Length Limits
There are two limits that this specification places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.
as ESM_Email_Serivce.JavaMail, does not properly conform to the MUST
portion of the RFC. It does not use quoted-printable to format long text
lines, and it does not split base64 MIME attachments into multiple lines
that are not more than 998 characters in length.
All RFC compliant email generating systems (and certainly the most
common systems like Gmail, Hotmail, Protonmail, Outlook, Thunderbird,
etc.) all conform. Just look at the source of any email that has been
sent from one of these systems and you'll see. They either insert hard
newlines, or use quoted-printable, or sometimes encode the entire text
as base64. Certainly for the case of attachments, all systems identified
above (except LCR), will actually encode an attachment with base64 and
split the data into multiple lines of 72--78 characters long.
This may be the cause of some of the email deliverability problems that
have been reported numerous times on this forum. Even if it is not
directly the cause, I needs to be addressed. It's a perfect example of
"garbage in garbage out" which essentially means that with invalid
inputs it is unpredictable what the output will be. Such huge lines of
text (I've seen attachments that resulted in over eleven million
characters on a single line) will put strains on systems that comply
with the RFC and expect newlines to be found in no more than 1000
characters. Or some email systems may simply truncate lines that exceed
it, resulting in a messge that is incomplete.
Thanks.