Can we figure out why this was sent to graymail?

[virtualmike]

Hi, everybody,

I'm subscribed to the Android Apps Weekly newsletter by the Android Authority.

It has been identified as spam by the Sonic fitters in the past, so I added *@*.androidauthority.com the the WelcomeList for the mailbox (and I've confirmed it's there).

Today's issue sent to graymail again. Here are the headers:

Code: Select all

Return-Path: <delivery_20240511150618.35349884.29915@mx.sailthru.com>
Received: from d.mx.sonic.net (spam-proxy.sjc.sonic.net [157.131.0.49])
	by c.local-delivery.sonic.net (8.16.1/8.16.1) with ESMTP id 44BJ6L3P3292020
	for <{my_mailbox}@lds.sonic.net>; Sat, 11 May 2024 12:06:21 -0700
Received: from pmta237-5.sailthru.com (pmta237-5.sailthru.com [192.64.237.5])
	by d.mx.sonic.net (8.14.7/8.14.7) with ESMTP id 44BJ6Jwm172158
	(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT)
	for <dlyauthrtyrdr@{my_domain}>; Sat, 11 May 2024 12:06:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; s=sailthru; d=androidauthority.com;
 h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe;
 i=hello@androidauthority.com;
 bh=Yr6d6VsFRwt5SyBSPr8nASF7o2N2uk1J5jV+90+7rCU=;
 b=q2/Nz/wOtnoUqDB0nwUHJ3CkatkKM0rrClHacaGFlDejoc2DGsxwmIC36jkwbDwi0yzsISQw9po2
   PDfp3P/tv39XgAYAD7dc6h+4wvdYCGhWXHycpJrhbvFwvkYi9y3VF0l4o4w8kjcDPBak2ZqmLcWI
   er0KHoLf4YjmJ1y8Lb8=
Received: from aws1-mta-relay4.sailthru.cloud (10.55.93.134) by pmta39.sailthru.com id h7v0qk3791sn for <dlyauthrtyrdr@{my_domain}>; Sat, 11 May 2024 14:06:18 -0500 (envelope-from <delivery_20240511150618.35349884.29915@mx.sailthru.com>)
Date: Sat, 11 May 2024 15:06:18 -0400 (EDT)
From: Apps Weekly <hello@androidauthority.com>
To: dlyauthrtyrdr@{my_domain}
Message-ID: <20240511150618.35349884.29915@sailthru.com>
Subject: 5 Android apps you shouldn't miss this week and all the latest app
 news - Android Apps Weekly
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_17405939_593210355.1715454378862"
Precedence: bulk
x-job: 9070-35349884-20240511
X-Feedback-ID: 9070:35349884:campaign:sailthru
X-TM-ID: 20240511150618.35349884.29915
X-Info: Message sent by sailthru.com customer Android Authority
X-Info: We do not permit unsolicited commercial email
X-Info: Please report abuse by forwarding complete headers to
X-Info: abuse@sailthru.com
X-Mailer: sailthru.com
X-JMailer: aws-campaign-mailer-28.sailthru.cloud
X-Unsubscribe-Web: https://link.androidauthority.com/oc/624fab4a70f1e505b9057a43l1o58.n2z/86777f38
List-Unsubscribe: <https://link.androidauthority.com/oc/624fab4a70f1e505b9057a43l1o58.n2z/86777f38>,<mailto:unsubscribe_20240511150618.35349884.29915@mx.sailthru.com>
X-rpcampaign: stnkw35349884
X-Orthrus: rip=192.64.237.5 rhost=pmta237-5.sailthru.com tar=0 grey=no co=US os=Linux/2.2.x-3.x/1 spf=pass dkim=pass

The graymail analysis states:

Code: Select all

Content analysis details:   (5.4 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
-0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from author's
                            domain
 0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 0.0 SONIC_BX_A2            No description available.
 0.0 RCVD_IN_MSPIKE_H4      RBL: Very Good reputation (+4)
                            [192.64.237.5 listed in wl.mailspike.net]
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
                            domains are different
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.0 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to
                            background
 0.7 MPART_ALT_DIFF         BODY: HTML and text parts are different
 0.1 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 4.4 SNF4SA                 Message Sniffer
 0.0 RCVD_IN_MSPIKE_WL      Mailspike good senders
 0.0 MIME_HTML_ONLY_MULTI   Multipart message only has text/html MIME parts
 
The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

Does anyone have any ideas why this message was identified as spam? ...thanks!

[apl]

Well, most of the score is this:

Code: Select all

4.4 SNF4SA                 Message Sniffer

Unlike the other scores in SpamAssassin which an individual user can modify, as far as I can tell the SNF4SA score is dynamically generated by a plug-in (Message Sniffer Antispam Plugin for SpamAssassin) that has its own internal set of rules and can't be modified or turned off on the user level.
There are other headers that give a little more detail (X-Spam-SNF-Result and X-Spam-MessageSniffer-Rules) but still don't really clarify how it all works.

[virtualmike]

Sure, I understand what the spam filters considered to determine the message was likely spam.

What I don't understand is why the spam filters took action when the address matches a wildcard in my WelcomeList. I'm under the impression that an email with a From: address in the WelcomeList should automatically be accepted.

[apl]

Oh, sorry, I missed that part.

Are you sure
*@*.androidauthority.com
matches
hello@androidauthority.com

The instructions say, somewhat vaguely:
Entries in the form ..."*@example.com", or "*@*.example.com" will all work.
but then:
Specifically, "*" and "?" are allowed, but all other metacharacters are not.

I take this to mean
*@*.example.com
will NOT match
anything@example.com
because of the extra "."

So you would want a second entry with
*@androidauthority.com
or maybe just a single entry of the form
*@*androidauthority.com

[virtualmike]

According to previous discussion in this forum, the wildcard for subdomains is supposed to work when there isn't a subdomain.

For example, I have an entry of *@*.amazon.com, and emails from <digital-no-reply@amazon.com> have "USER_IN_WELCOMELIST" in the list of tests (in the Internet headers).

But for some reason, the spam filters are not detecting that <hello@androidauthority.com> matches *@*.androidauthority.com.

[jordan.m]

According to previous discussion in this forum, the wildcard for subdomains is supposed to work when there isn't a subdomain.

For example, I have an entry of *@*.amazon.com, and emails from <digital-no-reply@amazon.com> have "USER_IN_WELCOMELIST" in the list of tests (in the Internet headers).

But for some reason, the spam filters are not detecting that <hello@androidauthority.com> matches *@*.androidauthority.com.

Hello! I'm sorry to hear you're experiencing trouble with our Welcome list feature. To help pinpoint this issue, what is the name of the receiving mailbox? If you prefer to keep the mailbox name off this thread, please DM me. From the looks of it, it doesn't appear as though you have anything set up incorrectly. That said, I am curious to know if this same issue were to occur if we add "*@androidauthority.com" to your welcome list alongside "*@*.androidauthority.com".

[virtualmike]

Thanks, Jordan. I sent the personal details to you in a DM.

In case it matters, I believe I added the sender's address to the WelcomeList using my master account, then used the "Copy Your Entries to Your Mailbox Accounts" function to "push" that entry to the mailbox where this message was received.

I'm happy to add "*@androidauthority.com" to the WelcomeList, but won't that make it harder to debug why the spam filters aren't functioning properly? (As well as the fact that I don't know if future mailings might otherwise trip the spam filters!) ...thanks!

[jordan.m]

Thank you for all the details! Since this doesn't seem to be an issue with any other "wildcards," you have set up in your welcome list, that leads me to believe this issue could be particular to the domain "androidauthority.com." If graymail were to still intercept emails while having " *@androidauthority.com " added to your welcome list, that would help isolate the issue to the domain and not a bug with the way the *@*. rule is behaving. However, before exploring that route, I went ahead and removed *@*.androidauthority.com from your welcome list and added it right back. Sometimes the simple tricks are all that are needed. (:

[virtualmike]

Thank you, Jordan. It's a weekly newsletter, so I'll know next weekend whether your change made any difference. ...cheers!

[virtualmike]

That didn't seem to make any difference, Jordan. Today's issue arrived, and while it wasn't diverted to Graymail, in the Internet headers, I see:

Code: Select all

X-Spam-Status: No, score=3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_FONT_LOW_CONTRAST,
	HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MPART_ALT_DIFF,
	RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SNF4SA,SONIC_BX_A2,SPF_HELO_NONE
	autolearn=disabled version=4.0.0

I've gone ahead and deleted *@*.androidauthority.com from the WelcomeList and added *@androidauthority.com to see if that will make a difference. If that doesn't match, then I'll try hello@androidauthority.com. ...thanks! -vm