Mailing List Archive

Is HAS_X_OUTGOING_SPAM_STAT a useful indicator?
We run cPanel servers and scan every outbound message with SA in order
to reduce the amount of garbage that comes through website contact forms.

However, in a default cPanel configuration, HAS_X_OUTGOING_SPAM_STAT
scores a whopping 2.3. I'm not sure what the distribution default is but
that's enough to move a lot of messages to spam, simply because the
sender was scanning messages. Sure spammers are going to be putting that
header in, but as far as I can tell, that's an argument for always
scoring the rule at a hard zero. I can see how it might be useful in a
meta with some other indicators, but as it stands, it's penalizing both
the guys trying to stop spam at the source and the spammers and that
seems counterproductive.

--
For SpamAsassin Users List
Re: Is HAS_X_OUTGOING_SPAM_STAT a useful indicator? [ In reply to ]
On 25 Apr 2021, at 18:40, Alan wrote:

> We run cPanel servers and scan every outbound message with SA in order
> to reduce the amount of garbage that comes through website contact
> forms.

That's good.

> However, in a default cPanel configuration, HAS_X_OUTGOING_SPAM_STAT
> scores a whopping 2.3. I'm not sure what the distribution default is

Today's dynamically-determined score in the default rules channel is
2.298 for systems with network and bayes scoring enabled, so it looks
like cPanel is likely to be using default scores.

> but that's enough to move a lot of messages to spam, simply because
> the sender was scanning messages.

Is it actually doing that to known legitimate mail? Can you share
headers? It would be good to find a way to exclude false positives.

> Sure spammers are going to be putting that header in, but as far as I
> can tell, that's an argument for always scoring the rule at a hard
> zero. I can see how it might be useful in a meta with some other
> indicators, but as it stands, it's penalizing both the guys trying to
> stop spam at the source and the spammers and that seems
> counterproductive.

The rule QA system is nowhere near as smart as you... It only knows that
in the corpora of mail it used to determine whether to publish
HAS_X_OUTGOING_SPAM_STAT and what to score it, 72.6% of the mail
matching HAS_X_OUTGOING_SPAM_STAT was spam. That's for yesterday's
weekly network mass-check. See
https://ruleqa.spamassassin.org/20210424-r1889140-n/HAS_X_OUTGOING_SPAM_STAT/detail
for the arcane details.

If I recall correctly, the "X-OutGoing-Spam-Status" header which
triggers that rule (with some exemptions) is not actually used by
anything within cPanel, and a non-spam result in that header certainly
should not be trusted anywhere but the system generating it. So it may
be helpful to do the scan but to forego adding the header or to at least
make cPanel use a local name.

--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Is HAS_X_OUTGOING_SPAM_STAT a useful indicator? [ In reply to ]
On 2021-04-25 19:31, Bill Cole wrote:
> On 25 Apr 2021, at 18:40, Alan wrote:
>
>> We run cPanel servers and scan every outbound message with SA in
>> order to reduce the amount of garbage that comes through website
>> contact forms.
>
> That's good.
>
>> However, in a default cPanel configuration, HAS_X_OUTGOING_SPAM_STAT
>> scores a whopping 2.3. I'm not sure what the distribution default is
>
> Today's dynamically-determined score in the default rules channel is
> 2.298 for systems with network and bayes scoring enabled, so it looks
> like cPanel is likely to be using default scores.
>
>> but that's enough to move a lot of messages to spam, simply because
>> the sender was scanning messages.
>
> Is it actually doing that to known legitimate mail? Can you share
> headers? It would be good to find a way to exclude false positives.
>
>> Sure spammers are going to be putting that header in, but as far as I
>> can tell, that's an argument for always scoring the rule at a hard
>> zero. I can see how it might be useful in a meta with some other
>> indicators, but as it stands, it's penalizing both the guys trying to
>> stop spam at the source and the spammers and that seems
>> counterproductive.
>
> The rule QA system is nowhere near as smart as you... It only knows
> that in the corpora of mail it used to determine whether to publish
> HAS_X_OUTGOING_SPAM_STAT and what to score it, 72.6% of the mail
> matching HAS_X_OUTGOING_SPAM_STAT was spam. That's for yesterday's
> weekly network mass-check. See
> https://ruleqa.spamassassin.org/20210424-r1889140-n/HAS_X_OUTGOING_SPAM_STAT/detail
> for the arcane details.
>
> If I recall correctly, the "X-OutGoing-Spam-Status" header which
> triggers that rule (with some exemptions) is not actually used by
> anything within cPanel, and a non-spam result in that header certainly
> should not be trusted anywhere but the system generating it. So it may
> be helpful to do the scan but to forego adding the header or to at
> least make cPanel use a local name.
>
I've posted to a 13 month old thread on the cPanel forums that was left
at "we'll update you", asking for an update. I can't see any useful
purpose to having that header in there.

Obfuscated headers follow. Haven't dug into it but it looks like another
FP on KAM_MXURI, I'm guessing that's because the message is coming from
my.our-domain.net and "my" is close enough to "mx", which would be
unfortunate. At least the NUMERIC_HTTP_ADDR is something I can fix.

Return-Path: <our-domain.support@our-domain.com>
Delivered-To: our-domain.support@our-domain.com
Received: from ssc010.our-domain.net
by ssc010.our-domain.net with LMTP
id KGkdFSHVhWBRCgAAk/bwIA
(envelope-from <our-domain.support@our-domain.com>)
for <our-domain.support@our-domain.com>; Sun, 25 Apr 2021 16:46:25 -0400
Return-path: <our-domain.support@our-domain.com>
Envelope-to: our-domain.support@our-domain.com
Delivery-date: Sun, 25 Apr 2021 16:46:25 -0400
Received: from our-server.our-domain.net ([100.101.102.103]:34044)
by ssc010.our-domain.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.94)
(envelope-from <our-domain.support@our-domain.com>)
id 1lale4-0002xo-LD
for our-domain.support@our-domain.com; Sun, 25 Apr 2021 16:46:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=my.our-domain.net; s=default; h=Content-Transfer-Encoding:Content-Type:
MIME-Version:Message-ID:Subject:Reply-To:From:To:Date:Sender:Cc:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=j53ixXbMXzxOWOuh7uN7dlHw0Vr6LfiGnD/j577LPKs=; b=0nJJlFR/3NPsGrwKOpTGdc+6Vu
YO7UqkOwYydYNQijRJqe0dxqUwdHt06x57tx1DhoAJC/EmM6buHejeghdXLO+K+X3Di9rQ/hU85bj
uvZnd2jvf4kn/Hg47bCEw7/3oByYNbTJ8VK2WhNTb6x3q0zsbT//ODf5t2afLOM1SqWNW65i2YR2J
OvoY+VLh6dH44zhssa0XWuDZ+JYJYKoDMYKLN5SQ9PLqu+tQo50frwLmvfULLqP5scNCir9xWvDHH
/WRF490NRwD5ljrTNxAxT6xQgTQV2KGM/ND6WnajJJpT5JeAsGP41C/YzNUOZyhX62DNB4XbYId6b
Mgj3eN4w==;
Received: from [100.101.102.103] (port=54664 helo=my.our-domain.net)
by our-server.our-domain.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94)
(envelope-from <our-domain.support@our-domain.com>)
id 1lale3-0002hS-Sp; Sun, 25 Apr 2021 16:46:24 -0400
Date: Sun, 25 Apr 2021 20:46:23 +0000
To: "First Last (Customer, Inc.)" <first-last@their-domain.com>
From: "our-domain Inc." <our-domain.support@our-domain.com>
Reply-To: "our-domain Inc." <our-domain.support@our-domain.com>
Message-ID: <rqx1wOkfk2HPwH7li3bl39DQAjYTzhuJiJOD1cfpxU@my.our-domain.net>
X-Mailer: our-domain Inc.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_rqx1wOkfk2HPwH7li3bl39DQAjYTzhuJiJOD1cfpxU"
Content-Transfer-Encoding: 8bit
X-OutGoing-Spam-Status: No, score=1.3
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - our-server.our-domain.net
X-AntiAbuse: Original Domain - our-domain.com
X-AntiAbuse: Originator/Caller UID/GID - [xx yy] / [xx yy]
X-AntiAbuse: Sender Address Domain - our-domain.com
X-Get-Message-Sender-Via: our-server.our-domain.net: authenticated_id: system-noreply@my.our-domain.net
X-Authenticated-Sender: our-server.our-domain.net: system-noreply@my.our-domain.net
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Status: Yes, score=6.7
X-Spam-Score: 67
X-Spam-Bar: ++++++
X-Spam-Report: Spam detection software, running on the system "ssc010.our-domain.net",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
root\@localhost for details.
Content preview: our-domain Hosting Services To protect against forged messages,
we are using a verification code, set by you, in every message we send. Please
check the code below against the value you set. If you have not set a verification
co [...]
Content analysis details: (6.7 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: list-manage.com]
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP
1.2 NUMERIC_HTTP_ADDR URI: Uses a numeric IP address in URL
1.5 KAM_MXURI URI: URI begins with a mail exchange prefix, i.e.
mx.[...]
0.0 NORMAL_HTTP_TO_IP URI: URI host has a public dotted-decimal IPv4
address
0.0 HTML_MESSAGE BODY: HTML included in message
0.8 MPART_ALT_DIFF BODY: HTML and text parts are different
0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME
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
2.3 HAS_X_OUTGOING_SPAM_STAT Has header claiming outbound spam scan
- why trust the results?
X-Spam-Flag: YES
Subject: ***SPAM*** New Account Information

--
For SpamAsassin Users List
Re: Is HAS_X_OUTGOING_SPAM_STAT a useful indicator? [ In reply to ]
On 25 Apr 2021, at 22:26, Alan wrote:

> On 2021-04-25 19:31, Bill Cole wrote:
>> On 25 Apr 2021, at 18:40, Alan wrote:
[...]
>> If I recall correctly, the "X-OutGoing-Spam-Status" header which
>> triggers that rule (with some exemptions) is not actually used by
>> anything within cPanel, and a non-spam result in that header
>> certainly should not be trusted anywhere but the system generating
>> it. So it may be helpful to do the scan but to forego adding the
>> header or to at least make cPanel use a local name.
>>
> I've posted to a 13 month old thread on the cPanel forums that was
> left at "we'll update you", asking for an update. I can't see any
> useful purpose to having that header in there.

It is probably worth digging into the cPanel exim.conf editor (I don't
recall what they call it, but it's there somewhere at the WHM level...)
to kill the header. You may want to look through the deployed exim.conf
to make sure that it's not somehow using the header for internal
communication between different stages of handling.

> Obfuscated headers follow. Haven't dug into it but it looks like
> another FP on KAM_MXURI, I'm guessing that's because the message is
> coming from my.our-domain.net and "my" is close enough to "mx", which
> would be unfortunate.

If KAM_MXURI is hitting on 'my' then it is not from the current version
of KAM.cf. I have a vague recollection of a 'my.' URI match somewhere
being removed recently for too many FPs, but I can't find evidence of it
being here. The current version of that rule is:

uri KAM_MXURI /^(?:http:\/\/)?(mail|mx)\..{1,40}\..{1,8}/i

So, that would likely be a body URI hit, as I see no match in the
headers.

> At least the NUMERIC_HTTP_ADDR is something I can fix.

MPART_ALT_DIFF should also be fixable simply by making the text/plain
part of the message a reasonable rendering of the HTML part or by only
sending a text/plain message, which would be even safer but I find hard
to get anyone to do. I guess sending only HTML would achieve the same
thing, but, ewwww.

You also should look at your trusted_networks and internal_networks
settings. If I'm understanding this correctly through the obfuscation,
it should have hit ALL_TRUSTED. Keep in mind that trusted_networks is
machines whose MTAs you trust to not forge Received headers, it is not
necessarily machines you trust to not send spam. That won't help with
mail leaving your system, but it will give mail from your machines to
you a strong advantage.



> Return-Path: <our-domain.support@our-domain.com>
> Delivered-To: our-domain.support@our-domain.com
> Received: from ssc010.our-domain.net
> by ssc010.our-domain.net with LMTP
> id KGkdFSHVhWBRCgAAk/bwIA
> (envelope-from <our-domain.support@our-domain.com>)
> for <our-domain.support@our-domain.com>; Sun, 25 Apr 2021 16:46:25
> -0400
> Return-path: <our-domain.support@our-domain.com>
> Envelope-to: our-domain.support@our-domain.com
> Delivery-date: Sun, 25 Apr 2021 16:46:25 -0400
> Received: from our-server.our-domain.net ([100.101.102.103]:34044)
> by ssc010.our-domain.net with esmtps (TLS1.2) tls
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> (Exim 4.94)
> (envelope-from <our-domain.support@our-domain.com>)
> id 1lale4-0002xo-LD
> for our-domain.support@our-domain.com; Sun, 25 Apr 2021 16:46:25
> -0400
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=my.our-domain.net; s=default;
> h=Content-Transfer-Encoding:Content-Type:
> MIME-Version:Message-ID:Subject:Reply-To:From:To:Date:Sender:Cc:Content-ID:
> Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
> :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
> List-Subscribe:List-Post:List-Owner:List-Archive;
> bh=j53ixXbMXzxOWOuh7uN7dlHw0Vr6LfiGnD/j577LPKs=;
> b=0nJJlFR/3NPsGrwKOpTGdc+6Vu
> YO7UqkOwYydYNQijRJqe0dxqUwdHt06x57tx1DhoAJC/EmM6buHejeghdXLO+K+X3Di9rQ/hU85bj
> uvZnd2jvf4kn/Hg47bCEw7/3oByYNbTJ8VK2WhNTb6x3q0zsbT//ODf5t2afLOM1SqWNW65i2YR2J
> OvoY+VLh6dH44zhssa0XWuDZ+JYJYKoDMYKLN5SQ9PLqu+tQo50frwLmvfULLqP5scNCir9xWvDHH
> /WRF490NRwD5ljrTNxAxT6xQgTQV2KGM/ND6WnajJJpT5JeAsGP41C/YzNUOZyhX62DNB4XbYId6b
> Mgj3eN4w==;
> Received: from [100.101.102.103] (port=54664 helo=my.our-domain.net)
> by our-server.our-domain.net with esmtpsa (TLS1.2) tls
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> (Exim 4.94)
> (envelope-from <our-domain.support@our-domain.com>)
> id 1lale3-0002hS-Sp; Sun, 25 Apr 2021 16:46:24 -0400
> Date: Sun, 25 Apr 2021 20:46:23 +0000
> To: "First Last (Customer, Inc.)" <first-last@their-domain.com>
> From: "our-domain Inc." <our-domain.support@our-domain.com>
> Reply-To: "our-domain Inc." <our-domain.support@our-domain.com>
> Message-ID:
> <rqx1wOkfk2HPwH7li3bl39DQAjYTzhuJiJOD1cfpxU@my.our-domain.net>
> X-Mailer: our-domain Inc.
> MIME-Version: 1.0
> Content-Type: multipart/alternative;
> boundary="b1_rqx1wOkfk2HPwH7li3bl39DQAjYTzhuJiJOD1cfpxU"
> Content-Transfer-Encoding: 8bit
> X-OutGoing-Spam-Status: No, score=1.3
> X-AntiAbuse: This header was added to track abuse, please include it
> with any abuse report
> X-AntiAbuse: Primary Hostname - our-server.our-domain.net
> X-AntiAbuse: Original Domain - our-domain.com
> X-AntiAbuse: Originator/Caller UID/GID - [xx yy] / [xx yy]
> X-AntiAbuse: Sender Address Domain - our-domain.com
> X-Get-Message-Sender-Via: our-server.our-domain.net: authenticated_id:
> system-noreply@my.our-domain.net
> X-Authenticated-Sender: our-server.our-domain.net:
> system-noreply@my.our-domain.net
> X-Source:
> X-Source-Args:
> X-Source-Dir:
> X-Spam-Status: Yes, score=6.7
> X-Spam-Score: 67
> X-Spam-Bar: ++++++
> X-Spam-Report: Spam detection software, running on the system
> "ssc010.our-domain.net",
> has identified this incoming email as possible spam. The original
> message has been attached to this so you can view it or label
> similar future email. If you have any questions, see
> root\@localhost for details.
> Content preview: our-domain Hosting Services To protect against
> forged messages,
> we are using a verification code, set by you, in every message we
> send. Please
> check the code below against the value you set. If you have not
> set a verification
> co [...]
> Content analysis details: (6.7 points, 5.0 required)
> pts rule name description
> ---- ----------------------
> --------------------------------------------------
> 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL
> was
> blocked. See
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
> for more information.
> [URIs: list-manage.com]
> 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
> [score: 0.5000]
> -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
> -0.0 SPF_PASS SPF: sender matches SPF record
> 0.0 WEIRD_PORT URI: Uses non-standard port number for
> HTTP
> 1.2 NUMERIC_HTTP_ADDR URI: Uses a numeric IP address in URL
> 1.5 KAM_MXURI URI: URI begins with a mail exchange
> prefix, i.e.
> mx.[...]
> 0.0 NORMAL_HTTP_TO_IP URI: URI host has a public dotted-decimal
> IPv4
> address
> 0.0 HTML_MESSAGE BODY: HTML included in message
> 0.8 MPART_ALT_DIFF BODY: HTML and text parts are different
> 0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html
> MIME
> 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
> 2.3 HAS_X_OUTGOING_SPAM_STAT Has header claiming outbound spam scan
> - why trust the results?
> X-Spam-Flag: YES
> Subject: ***SPAM*** New Account Information
>
> --
> For SpamAsassin Users List


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: Is HAS_X_OUTGOING_SPAM_STAT a useful indicator? [ In reply to ]
On Sun, 25 Apr 2021, Alan wrote:

> I've posted to a 13 month old thread on the cPanel forums that was left at
> "we'll update you", asking for an update. I can't see any useful purpose to
> having that header in there.

There isn't. Why should the spam score provided by the sender be trusted
by anyone else?

If you're scanning outbound messages then use the results in your decision
whether to send the message on from your system, but don't include the
results as they aren't useful to anyone downstream and are trivially
abusable.

I've reduced the score limit to 2.0 and I'm looking for more ham
exclusions.


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Rights can only ever be individual, which means that you cannot
gain a right by joining a mob, no matter how shiny the issued
badges are, or how many of your neighbors are part of it. -- Marko
-----------------------------------------------------------------------
5 days until May Day - Remember 110 million people murdered by Communism
Re: Is HAS_X_OUTGOING_SPAM_STAT a useful indicator? [ In reply to ]
On 2021-04-26 10:07, Bill Cole wrote:
> [...]
>
> It is probably worth digging into the cPanel exim.conf editor (I don't
> recall what they call it, but it's there somewhere at the WHM
> level...) to kill the header. You may want to look through the
> deployed exim.conf to make sure that it's not somehow using the header
> for internal communication between different stages of handling.
Alas, there is but one option: scan outbound or don't. Scan it and you
get the header. If they're using it for some internal purpose, then it
should have the form x-cpanel-... and leave me out of it.
>
> So, that would likely be a body URI hit, as I see no match in the
> headers.
Indeed, that would be it. Part of the message tells them to use the mail
subdomain to set up... mail. Can't circumnavigate that one.
>
>> At least the NUMERIC_HTTP_ADDR is something I can fix.
>
> MPART_ALT_DIFF should also be fixable simply by making the text/plain
> part of the message a reasonable rendering of the HTML part or by only
> sending a text/plain message, which would be even safer but I find
> hard to get anyone to do. I guess sending only HTML would achieve the
> same thing, but, ewwww.
That's going to be so much fun it might not be worth it. The stupid
thing is actually sending a blank plain text part, which escalates ewwww
to arghhh! It's the output of a template driven system so I may be
limited in what I can do there. At this point dropping the plain text
would be an improvement. [string of pejoratives redacted]
>
> You also should look at your trusted_networks and internal_networks
> settings. If I'm understanding this correctly through the obfuscation,
> it should have hit ALL_TRUSTED. Keep in mind that trusted_networks is
> machines whose MTAs you trust to not forge Received headers, it is not
> necessarily machines you trust to not send spam. That won't help with
> mail leaving your system, but it will give mail from your machines to
> you a strong advantage.
Good idea. I'll verify that.

--
For SpamAsassin Users List