"Send a Message" Function on LCR

[jtjacks]

It's not an IT issue.

It is absolutely an IT issue. Wards can help by cleaning up email addresses, etc., but Church IT has to go work with email providers, big ISPs, (etc.) to have them not view the Church as a spammer.

There was a church IT person participating in this thread (scroll up) who said he was working on the problem, but I don't know if he is still reading this.

Church IT has certainly made some progress (like allowing people to opt out of receiving emails), but there is still a lot to do (like getting wards to validate email addresses, stop using "dummy" email addresses etc), but even if all of those things get fixed, managing a big email sending system will require constant action and monitoring by church IT.

[claytonf]

I'll have to disagree that it is a local problem and that cleaning up e-mail addresses will fix things. When I use gmail to send to these hotmail and yahoo addresses nearly all of them get through and gmail notifies me if any are undeliverable, such as full inboxes.

[gregneg]

One third of our ward has yahoo or hotmail addresses. Not being able to communicate with such a large proportion of our ward is very limiting. Is there any hope for a fix?

-Clayton Fuller

I have manually copied those addreses to a designated group in my own computer Contacts/ Address book. And yea, it is a chore when there are many.

Once I have received an LCR email, I "Forward" it (after cleaning up the assorted "forward stuff), to those in my group folder.

[zaneclark]

I created a Yahoo/AOL list in Tools and use that to forward the newsletter every week.

[stevfletchcom]

I'm not sure if this is the right forum or not but I know why sometimes I don't get emails from the church, and possibly why some providers are looking at church emails as spammy.

This message is intended for the church's developers so that they can implement the proper changes in the underlying system to cause smoother delivery in these cases.

I run my own email server using the exim4 email server software. I generally get an error whenever there is an attachement but whenever an email contains any line longer than 998 octets length because it breaks the email line length limits that RFC 5322 2.1.1 specifies. See https://www.rfc-editor.org/rfc/rfc5322#section-2.1.1

Email servers like exim4 attempting to follow the standards set in the RFC listed above will reject them.
Having worked with spam scanning software before I would assume that they would look at this kind of standards breaking as suspicious, and increse the likeliehood the message would be blocked as spam.

I have one of the messages in my queue, that has been stopped because an attachment was added, but the base64 encoded attachement was sent as one long line of base64 encoded text instead of breaking it up with a new line every 76 characters. (The rfc allows 78, but many tools break at 76 by default.)

Here is an example of what the base64 encoding might look like curently when viewing the message source, then what it should look like. (Note the example below is just a text file I manually encoded using the base64 utility in many linux distributions, it didn't come from a real email but looks exactly like what I'm seeing in real emails, just much shorter.)

===========================================Encoded base64 text as single line========================================================================================================
VGhpcyBpcyBhIHRlc3QgZmlsZSB3aXRoIHNvbWUgdGV4dCB0byB0ZXN0IGJhc2UgNjQgZW5jb2RpbmcuCgoKV2hhdCBpcyBMb3JlbSBJcHN1bT8KCkxvcmVtIElwc3VtIGlzIHNpbXBseSBkdW1teSB0ZXh0IG9mIHRoZSBwcmludGluZyBhbmQgdHlwZXNldHRpbmcgaW5kdXN0cnkuIExvcmVtIElwc3VtIGhhcyBiZWVuIHRoZSBpbmR1c3RyeSdzIHN0YW5kYXJkIGR1bW15IHRleHQgZXZlciBzaW5jZSB0aGUgMTUwMHMsIHdoZW4gYW4gdW5rbm93biBwcmludGVyIHRvb2sgYSBnYWxsZXkgb2YgdHlwZSBhbmQgc2NyYW1ibGVkIGl0IHRvIG1ha2UgYSB0eXBlIHNwZWNpbWVuIGJvb2suIEl0IGhhcyBzdXJ2aXZlZCBub3Qgb25seSBmaXZlIGNlbnR1cmllcywgYnV0IGFsc28gdGhlIGxlYXAgaW50byBlbGVjdHJvbmljIHR5cGVzZXR0aW5nLCByZW1haW5pbmcgZXNzZW50aWFsbHkgdW5jaGFuZ2VkLiBJdCB3YXMgcG9wdWxhcmlzZWQgaW4gdGhlIDE5NjBzIHdpdGggdGhlIHJlbGVhc2Ugb2YgTGV0cmFzZXQgc2hlZXRzIGNvbnRhaW5pbmcgTG9yZW0gSXBzdW0gcGFzc2FnZXMsIGFuZCBtb3JlIHJlY2VudGx5IHdpdGggZGVza3RvcCBwdWJsaXNoaW5nIHNvZnR3YXJlIGxpa2UgQWxkdXMgUGFnZU1ha2VyIGluY2x1ZGluZyB2ZXJzaW9ucyBvZiBMb3JlbSBJcHN1bS4KV2h5IGRvIHdlIHVzZSBpdD8K
===========================================End encoded base64 text as single line=====================================================================================================

==============================Properly encoded base64 text with line breaks every 76 characters===========================================================================================
VGhpcyBpcyBhIHRlc3QgZmlsZSB3aXRoIHNvbWUgdGV4dCB0byB0ZXN0IGJhc2UgNjQgZW5jb2Rp
bmcuCgoKV2hhdCBpcyBMb3JlbSBJcHN1bT8KCkxvcmVtIElwc3VtIGlzIHNpbXBseSBkdW1teSB0
ZXh0IG9mIHRoZSBwcmludGluZyBhbmQgdHlwZXNldHRpbmcgaW5kdXN0cnkuIExvcmVtIElwc3Vt
IGhhcyBiZWVuIHRoZSBpbmR1c3RyeSdzIHN0YW5kYXJkIGR1bW15IHRleHQgZXZlciBzaW5jZSB0
aGUgMTUwMHMsIHdoZW4gYW4gdW5rbm93biBwcmludGVyIHRvb2sgYSBnYWxsZXkgb2YgdHlwZSBh
bmQgc2NyYW1ibGVkIGl0IHRvIG1ha2UgYSB0eXBlIHNwZWNpbWVuIGJvb2suIEl0IGhhcyBzdXJ2
aXZlZCBub3Qgb25seSBmaXZlIGNlbnR1cmllcywgYnV0IGFsc28gdGhlIGxlYXAgaW50byBlbGVj
dHJvbmljIHR5cGVzZXR0aW5nLCByZW1haW5pbmcgZXNzZW50aWFsbHkgdW5jaGFuZ2VkLiBJdCB3
YXMgcG9wdWxhcmlzZWQgaW4gdGhlIDE5NjBzIHdpdGggdGhlIHJlbGVhc2Ugb2YgTGV0cmFzZXQg
c2hlZXRzIGNvbnRhaW5pbmcgTG9yZW0gSXBzdW0gcGFzc2FnZXMsIGFuZCBtb3JlIHJlY2VudGx5
IHdpdGggZGVza3RvcCBwdWJsaXNoaW5nIHNvZnR3YXJlIGxpa2UgQWxkdXMgUGFnZU1ha2VyIGlu
Y2x1ZGluZyB2ZXJzaW9ucyBvZiBMb3JlbSBJcHN1bS4KV2h5IGRvIHdlIHVzZSBpdD8K
==============================End Properly encoded base64 text with line breaks every 76 characters========================================================================================

The developers of the LCR tool for sending emails to members should update their code to break lines every 76 characters when sending messages. They may also need to fix headers that exceed that length by folding them. See https://www.rfc-editor.org/rfc/rfc5322#section-2.2.3

e.g.
X-Some-Long-Header: Some really long header that exceeds more than 76
characters should be broken onto multiple lines as follows.

I hope this helps with other delivery issues. I know it should help with mine.

Steven Fletcher

[rmrichesjr]

I'm not sure if this is the right forum or not but I know why sometimes I don't get emails from the church, and possibly why some providers are looking at church emails as spammy.

This message is intended for the church's developers so that they can implement the proper changes in the underlying system to cause smoother delivery in these cases.

...

I hope this helps with other delivery issues. I know it should help with mine.

Steven Fletcher

Thank you for pointing out the too-long-line aspect that could be impacting delivery from send-a-message. That might account for at least some of the symptoms.

However, posting here won't likely be seen by anyone with an ability to influence or implement a solution. This is a user-to-user discussion forum. Developers and their managers probably won't see your excellent post. Please send the information via the Feedback button/link, prefixed with a request to escalate your well-researched report to engineering.

I had noticed a too-long-line issue in connection with a message some years ago, before send-a-message existed, if I remember correctly. Unfortunately for those of us who appreciate RFC compliance, I would guess that fixing this problem is not likely to be as high a priority as we would like it to be.

[stevfletchcom]

rmrichesjr,

Thank you for your reply. I've submitted a link to my post to the feedback form on the bottom of the LCR website. I would be happy to post elsewhere as well if anyone reading this knows where to send it to.

Thanks

Steven Fletcher

[rmrichesjr]

Thank you for your reply. I've submitted a link to my post to the feedback form on the bottom of the LCR website. I would be happy to post elsewhere as well if anyone reading this knows where to send it to.

I would think that a link to your post ought to work very well.

[caillines]

I think there's a chance we're going to start having issues sending to gmail addresses next year given their recent blog post https://blog.google/products/gmail/gmai ... rotection/

It looks like we'll be falling afoul of the 1-click unsubscribe requirement.

[rmrichesjr]

...

It looks like we'll be falling afoul of the 1-click unsubscribe requirement.

When I read the document, it said the 1-click unsubscribe requirement was for "commercial" messages. Whether Google considers Church messages to be "commercial" may determine whether that's a problem.