Can we figure out why this was sent to graymail?

[jordan.m]

That's unfortunate. I was hoping that would do the trick. Please keep me updated on whether or not Graymail continues to intercept mail from @androidauthority.com so I can continue to investigate.

[virtualmike]

Absolutely! I'll have an update next Saturday.

[virtualmike]

In the meantime...

Just this week, I added *@*.hasbrouck.org to my WelcomeList. Today, I received a message from <news@lists.hasbrouck.org>, and X-Spam-Status in the Internet headers says "USER_IN_WELCOMELIST."

It's definitely not the wildcard.

Pondering... the domain androidauthority.com is on the longer side. It's the longest in my WelcomeList. Is it possible that there's a limit on the length of the string to be compared? Either entries in the WelcomeList or the address extracted from the "From:" line? ...cheers!

[virtualmike]

I received the next issue of the Android Apps Weekly newsletter.

With the WelcomeList entry of *@androidauthority.com, I see this in the Internet headers:

Code: Select all

X-Spam-Status: No, score=-96.5 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,SONIC_EX_EV4,
	SPF_HELO_NONE,USER_IN_WELCOMELIST autolearn=disabled version=4.0.0

So... why does *@androidauthority.com work and *@*.androidauthority.com doesn't, even though wildcards work with other domains?

[apl]

So... why does *@androidauthority.com work and *@*.androidauthority.com doesn't,

It is probably just (as I suggested in the first place) that
*@*.androidauthority.com doesn't match hello@androidauthority.com because the latter doesn't have the "." before androidauthority.

You dismissed this, saying that in another case *@*.amazon.com matched email from digital-no-reply@amazon.com, which likewise doesn't have the subdomain and the "."
Looking into that example a little more, I suspect it is because the spamassassin welcomelist_from looks at not only the literal "From" line but also a few other headers that indicate the source of the mail.
So probably *@*.amazon.com is not actually matching the header
From: "Amazon.com" <digital-no-reply@amazon.com>
but instead the other header
Return-Path: <[LONGRANDOMSTRING]@bounces.amazon.com>
which does have the extra "."

[virtualmike]

I appreciate your attempts to help, but unless you're looking at the source code, you can only conjecture on the cause (which is all I can do).

I would doubt that the Welcomelist From entries look at other headers, as there is a separate Welcomelist From Received, which specifically inspects the "Received:" headers.

The documentation on the Welcomelist Address page states, "Used to specify addresses that send mail that is tagged incorrectly as spam." If this means it matches any address within the Internet headers, then it should be updated to reflect that. Most people don't even know what the Internet headers are. As well, I can easily see a case where a message that is really spam happens to have a Welcomelisted address somewhere in the headers, which would lead to its being delivered to the Inbox, which I'm sure is not an expected result.

As well, a "Return-Path:" simply tells the receiving mail server where to send a bounce message and is not intended to be a alternate "sender" address. Many of the newsletters I receive have Return-Paths to completely different domains (typically, the services that processes the mailing lists).

Only an engineer at Sonic will be able to determine what' exactly should be happening and what really is happening. I'm sure this isn't the most critical issue at the moment, so in the meantime, I'm providing whatever information I can to help them narrow down the possibilities.

[jordan.m]

Thank you for going through all those steps for me. This is a bizarre one, but we should be able to figure out why it is happening. I'll pass this on to our internal team and reach back out here once I have an update. Thanks once again!

[apl]

I am not looking at the source code, but I am looking at the documentation, which (although not always 100% clear) agrees with everything I have said.

On the "welcomelist_from" headers checked:

The headers checked for welcomelist addresses are as follows: if Resent-From is set, use that; otherwise check all addresses taken from the following set of headers:
Envelope-Sender
Resent-Sender
X-Envelope-From
From

In addition, the "envelope sender" data, taken from the SMTP envelope data where this is available, is looked up. See envelope_sender_header.

The entry for envelope_sender_header fields includes "Return-Path" as one of the fields it may use.
That point was kind of tangential anyway.

On the wildcard matching:

Welcomelist and blocklist addresses are now file-glob-style patterns, so friend@somewhere.com, *@isp.com, or *.domain.net will all work. Specifically, * and ? are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons. Matching is case-insensitive.

Emphasis added to the two key points.
(In reverse order) 1. ".'" is not in any way a special character.
2. Absent other information, one should expect it to work the same way glob wildcard matching works on the command line in any unix shell.

The latter is easy enough (though maybe overkill) to check by creating a filename that looks like an email address and seeing if it matches various wildcard patterns.

Code: Select all

[apl@sh:/tmp] touch hello@androidauthority.com
[apl@sh:/tmp] ls *@androidauthority.com
hello@androidauthority.com
[apl@sh:/tmp] ls *@*androidauthority.com
hello@androidauthority.com
[apl@sh:/tmp] ls *@*.androidauthority.com
ls: No match.

No match for the last one because of the extra dot, as expected.

So it appears that spamassassin's wildcard matching is working exactly as should be expected. Nothing bizarre about it.

[virtualmike]

I personally thought the domain wildcard would make more sence as "*@*example.com" but Sonic's Welcomelist page says:

Used to specify addresses that send mail that is tagged incorrectly as spam. Entries in the form "friend@example.com", "*@example.com", or "*@*.example.com" will all work. Specifically, "*" and "?" are allowed, but all other metacharacters are not.

Examples:

Welcomelist From friend@example.com
Welcomelist From friend@*.example.com
Welcomelist From *@example.com
Welcomelist From *@*.example.com

As a test, I have changed my Welcomelist entry to "*@*androidauthority.com" -- let's see how SpamAssassin likes them apples.

[virtualmike]

*@*androidauthority.com seems to work--today's issue has this in the headers:

Code: Select all

X-Spam-Status: No, score=-96.6 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,
	T_SCC_BODY_TEXT_LINE,[b]USER_IN_WELCOMELIST[/b] autolearn=disabled
	version=4.0.0

I've edited another Welcomelist entry similarly to see if that will still work. Emails arrive from <digest@subdomain.domain.com>, so I'll see on Monday if they are recognized.