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

Discussions about the Leader and Clerk Resources on lds.org.
lajackson
Community Moderators
Posts: 11796
Joined: Mon Mar 17, 2008 10:27 pm
Location: US

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

Post by lajackson »

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.
rmrichesjr
Community Moderators
Posts: 4246
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon, USA

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

Post by rmrichesjr »

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.

Return to “Leader and Clerk Resources”