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

Hi All,

I send out a weekly bulletin in PDF format through the LCR "Send a Message Format".

I have received back some emails of late that the files are coming through "corrupted" or changing to .txt files full of jargon.

This is not true for all recipients but a sizable minority enough for it to be a concern.

Whilst I know want I can do to mitigate the issue (Include hyperlink to PDF in cloud instead of attachment), It would be good to troubleshoot and to fix.



Thanks,


Jack Prebble

Stake Executive Secretary

I gave up on pdf files for reason and now I just use plain text with the limited formatting available in Send a Message for my weekly ward newsletter. Most members really don't care about the format, as long as it has the basic information..

Interesting, I'm seeing this as well. I sent out ministering assignments yesterday and I've had a sizable bunch reply that they got a garbled attachment, it seemed to work fine if you don't open in "preview" mode but download and open with Adobe or other PDF reader.

Has anyone noticed that this just seems to occur with those opening attachments on their phone, specifically iphones via the apple mail app? I have an iphone but use the gmail app and can see attachments just fine.

I'm glad there are others out there experiencing the same....

We have increased the frequency of stake presidency initiated emails recently and have noticed the same problem... pdf's which are corrupted or become zero-length sized.

But there is one thing that is consistent for those that have reported the problem (3 people out of dozens).... they ALL use sbcglobal.net email addresses.

Let me query the users and find out how they are opening the emails... preview mode vs. download, and which email app (web, sbcglobal.net site, 3rd party reader, etc.)

We are also experiencing problems with pdf's not opening. It says they are corrupted.

billgubler wrote:We are also experiencing problems with pdf's not opening. It says they are corrupted.

I have verified that the previously reported issue (wrong MIME type on the message) appears to have been corrected. If you can reproduce the issue, send details to LCR feedback using the feedback link on the page.

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 )

This is still a problem, with no response or resolution to my service ticket... Is there a way to see the online status of my above service ticket?

In addition, today users in our stake with sbcglobal.net email addresses indicated they could also not open .docx files.

rootbeericecream wrote: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 )

We have a bishopric member who uses sbcglobal. He has had the same problem since the send a message tool became available. I would get a bounceback from his yahoo server (I guess sbcglobal uses yahoo for the email service?) that the message was rejected as spam when I use the send a message function. I can send the exact email to him from my gmail account and it goes through just fine. I suspect it may have something to do with the send a message tool spoofing my email address as the sender when it actually comes from the church. Spoofing the email address of the sender can be useful in this instance, but is also a tactic used by spammers. It may be that yahoo rejects any mail with a spoofed address. Our bishopric member recently changed his email address on his profile to gmail so he receives the messages now.

davesudweeks wrote:(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.

rootbeericecream wrote: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.

rmrichesjr wrote: Mon Dec 30, 2019 9:52 pm 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.

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.

rmrichesjr wrote: Sat Jan 10, 2026 12:40 pm 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.