I don't know of a better way to bring this issue to the attention of the appropriate people, but with the new Social Distancing guidelines in place our Stake and Ward leaders have been heavily using the website emailing tools.
The problem is that through a combination of old technology and how headers are formed for the emails, the messages from leaders are already 80% of the way towards being marked as SPAM.
I use Spamassassin to analyze email that comes into my server, that is combined with Thunderbird's internal junk filtering to produce a pretty good spam filter. I run my own mail server and my email address has been floating around the Internet for > 20 years, so I get a lot of spam.
I choose to run my own server because services like Gmail are even worse at false positives and place draconian restrictions on what can be sent to and from their email boxes.
With my reasoning out of the way, let me show you what the Spamassassin report for a recent Stake Presidency email looked like:
Code: Select all
* -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at
* https://www.dnswl.org/, no trust
* [184.108.40.206 listed in list.dnswl.org]
* -0.0 SPF_PASS SPF: sender matches SPF record
* 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
* 0.0 HTML_MESSAGE BODY: HTML included in message
* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
* author's domain
* -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from
* envelope-from domain
* 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
* 1.2 INVALID_MSGID Message-Id is not valid, according to RFC 2822
* 1.5 PDS_FREEMAIL_REPLYTO_URISHRT Freemail replyto with URI
* 2.5 FREEMAIL_FORGED_REPLYTO Freemail in Reply-To, but not From
* 1.5 PDS_TINYSUBJ_URISHRT Short subject with URL shortener
The body of the email read:
Code: Select all
Dear Brothers and Sisters of the Stake,
As we take time in our homes this weekend to celebrate the sacrifice and atonement of the Lord Jesus Christ, may we be inspired to more fully understand and appreciated the Savior and the true meaning of the Easter season.
The following Church video may help in this endeavor.
We love and miss all of you, and hope to be able to meet together soon.
Sincerely, the Stake Presidenc
I will not post the headers because I don't want to identify the person who sent the message.
There are 3 problems with how the Church website sends emails and these problems can be rectified, greatly reducing the penalty while sending messages:
1. The Message-Id header is not RFC compliant, it reads:
Code: Select all
A proper RFC-2822 Message-ID header will look like this:
Code: Select all
The Message-ID is being generated by the JavaMail MUA that is sending the messages to membership, either the MUA (Mail User Agent) needs to be changed to a newer compliant Java Class, or the Message-ID needs to be explicitly set with a properly formatted header.
2. The Reply-To and the From header are not the same.
When a leader sends a message through the Church website the From header is modified to use <email@example.com> instead of their actual email address, yet the Reply-To header is set to the actual email address of the leader.
The RFC standard states that email replies should be sent based on this priority:
Error messages should be sent to the Return-Path, known as the envelope sender.
It serves no technical or practical purpose to set Reply-To to the leader's email address, but to put the Return-Path (envelope sender) in the From header of the message. This discontinuity causes Spamassassin to demerit the email message from the leader.
The fix is to set the From and Reply-To to contain the email address of the leader.
If a message is sent with no reply intended, then the From should contain <firstname.lastname@example.org>, the Return-Path should contain <email@example.com>, and the Reply-To should be omitted.
3. Attachments sent in broadcast emails are not broken up into lines of 80 characters each, they are sent as a single line.
Attachments are encoded in a text format which is called MIME encoding. It's a way of taking a file like a PDF, which contains non-printable characters (binary), and encoding it into characters which are technically printable (0-9, A-Z, etc).
The MIME encoding process takes an attachment as input and produces a long string of text as output, this long string of text should be broken up into lines that are shorter than 80 characters when embedded in an email message.
Because the MIME attachment is not broken up into lines, it is considered a characteristic commonly shared with SPAM and counts negatively towards the SPAM score.
The fix is to simply split the long MIME attachment into multiple lines with a CRLF (Carriage Return + Line Feed) delimiter between each line.
The reason why these 3 technical flaws are so critical is that it gives leader no leeway when drafting emails. The cited message simply included a short subject and a shortened YouTube URL, but because these are common traits shared with SPAM, they were enough to trigger the threshold and send the message to the junk folder.
Fixing these problems should take no more than a few hours at most and will help ensure messages from leaders make it to membership.