LCR "Send a Message" - Error with attachements on recieving end.

[lajackson]

(I guess sbcglobal uses yahoo for the email service?)

Yes. The ATT family of addresses uses Yahoo. It has been quite a trip for me.

[rmrichesjr]

I attempted an email to some members which experienced the issue previously (and also sent to myself with a newly created sbcglobal email.

My old gmail email processed and viewed everything correctly.
sbcglobal viewed the attachment as corrupted and would not show it. MIME issue makes sense, but whatever was changed, did not help.
I have a raw export of the email with all headers. I'll upload it to the LCR feedback page. (service ticket GSC03252389 )

There is a current bug that corrupts PDF attachments sent from local leader accounts through the Church system. It may be the same problem as one I saw a year or three ago, but I couldn't find it in my email archives. The current problem may be invisible to a lot of recipients if their systems ignore the corruption. I sent a bug report via 'Feedback' with a request to escalate to engineering. Here are more details:

A message arrived today from my bishop with this email address in the 'From:' line: <noreply@churchofjesuschrist.org>. The PDF attachment was base64 encoded. Base64 encoding customarily wraps lines of the encoded text at a reasonable length less than 80 characters. I don't know whether any relevant MIME standards require line wrap. In today's message, each encoded line was around 8192 characters. Most of the lines had an extra null byte (0x00) and a fake-space character (0x80) appended, and some of the lines had a true space character (0x20) prepended.

I'm confident that the extra characters (null, fake-space, space) are being added on the Church's side, because the fake-space character is characteristic of Microsoft products, and all home systems use Linux. I have reason to be confident my email provider (TuffMail) also does not use Microsoft products in their systems.

[ambldsorg]

A message arrived today from my bishop with this email address in the 'From:' line: <noreply@churchofjesuschrist.org>. The PDF attachment was base64 encoded. Base64 encoding customarily wraps lines of the encoded text at a reasonable length less than 80 characters. I don't know whether any relevant MIME standards require line wrap. In today's message, each encoded line was around 8192 characters.

At 8192 characters per line, the behavior is undefined because relevant RFCs require (MUST) that lines be no longer than 998 characters. I suspect that in your case (as in mine) that the messages are getting truncated and thus corrupted.

While MIME standards don't require line wrap, RFC 5322 (internet message format) and RFC 5321 (SMTP) both require that lines not exceed 998 characters (line wrap); SMTP because it transmits messges as a series of "lines" which are limited in length. MIME works because base64 encoded messages can easily be split into lines because RFC 4648 states that RFC data which contains newlines and carriage returns can be ignored:

Such specifications may instead state, as MIME
does, that characters outside the base encoding alphabet should
simply be ignored when interpreting data ("be liberal in what you
accept"). Note that this means that any adjacent carriage return/
line feed (CRLF) characters constitute "non-alphabet characters" and
are ignored.

I would venture to guess that 99% of email sending software correctly encodes and terminates long lines of text. Most of them do so at 78 characters like the RFCs recommend, but I've seen longer.

[rmrichesjr]

Please note that the message being quoted above is from 2019, between six and seven years ago. I don't know whether the problem has been fixed or still exists.

[ambldsorg]

Please note that the message being quoted above is from 2019, between six and seven years ago. I don't know whether the problem has been fixed or still exists.

Unfortunately, some things don't change with the passage of six or seven years time; the problem still exists or I wouldn't have bothered with such an old thread. Send yourself a message from LCR with an attachment and observe that the base64 encoded data for the file is all on a single line.