You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Steve Dondley <s...@dondley.com> on 2021/04/06 15:48:46 UTC
DNSWL overriding bayes_99 and bayes_999 rules
I have emails that have been flagged as spam in the past but that are
still getting through, presumably because the servers are on some DNSWL.
Example:
X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
autolearn_force=no version=3.4.2
What's the recommended way to handle these? Do I turn on shortcircuit?
Do I bump up the score for BAYES_99, BAYES_999? Or might there be a way
to ignore DNSWL scores if they have a high bayes score?
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Benny Pedersen <me...@junc.eu>.
On 2021-04-06 21:12, Arne Jensen wrote:
> Den 06-04-2021 kl. 17:48 skrev Steve Dondley:
>> I have emails that have been flagged as spam in the past but that are
>> still getting through, presumably because the servers are on some
>> DNSWL.
>>
>> Example:
>>
>> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
>> DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
>>
>> HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
>> SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
>> autolearn_force=no version=3.4.2
>>
>> What's the recommended way to handle these? Do I turn on shortcircuit?
>> Do I bump up the score for BAYES_99, BAYES_999? Or might there be a
>> way to ignore DNSWL scores if they have a high bayes score?
>
> - Report the full message to DNSWL?
>
> - Provide more information about the message, such as e.g. the
> Received:
> headers as well, or even better: The full message in question?
spf softfail, so its forged even, why accept it in mta stage :/
bayes here says its well trained for spam, but it could be added meta to
meta BAYES_SPAM_SPF_SOFTFAIL (BAYES_999 && SPF_SOFTFAIL &&
RCVD_IN_DNSWL_HI)
and score that meta so its considered spam in end results
this will go away if reported to dnswl.org
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Arne Jensen <da...@darkdevil.dk>.
Den 06-04-2021 kl. 17:48 skrev Steve Dondley:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
> DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
> HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
> SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
> autolearn_force=no version=3.4.2
>
> What's the recommended way to handle these? Do I turn on shortcircuit?
> Do I bump up the score for BAYES_99, BAYES_999? Or might there be a
> way to ignore DNSWL scores if they have a high bayes score?
- Report the full message to DNSWL?
- Provide more information about the message, such as e.g. the Received:
headers as well, or even better: The full message in question?
--
Med venlig hilsen / Kind regards,
Arne Jensen
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Greg Troxel <gd...@lexort.com>.
RW <rw...@googlemail.com> writes:
> On Tue, 06 Apr 2021 12:03:52 -0400
> Greg Troxel wrote:
>
>
>> You can and probably should report spam to dnswl. In theory HI should
>> have essentially no spam.
>
> I thought that because I've never received a single spam with it, but in
> mass checks it's at 0.23% of spam.
Do you mean that of all the spam in in-use corporaa, 0.23% of those spam
messages trigger DNSWL_HI?
I found some old discussion and it seems there is often trouble with a
machine that receives and forwards mail, sort of jfoo@example.org
getting sent to john.foo@other.com, as a legit thing, but if other.com
doesn't put the example.org MTA in trusted_networks, it gets
complicated. Although, HI is more or less supposed to be for things
that do not have user-controlled mail, for non-controlled users.
I did a quick scan over my own mail, and found 5 DNSWL_HI and none in
spam folders. (This omits any that were MTA-rejected.) I realize
that's an anecdote, not data.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by RW <rw...@googlemail.com>.
On Tue, 06 Apr 2021 12:03:52 -0400
Greg Troxel wrote:
> You can and probably should report spam to dnswl. In theory HI should
> have essentially no spam.
I thought that because I've never received a single spam with it, but in
mass checks it's at 0.23% of spam.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Greg Troxel <gd...@lexort.com>.
Steve Dondley <s...@dondley.com> writes:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some
> DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
> DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
> HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
> SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
> autolearn_force=no version=3.4.2
>
> What's the recommended way to handle these? Do I turn on shortcircuit?
> Do I bump up the score for BAYES_99, BAYES_999? Or might there be a
> way to ignore DNSWL scores if they have a high bayes score?
First, run spamassassin -t on the raw file, so you can see all the
scores.
You can and probably should report spam to dnswl. In theory HI should
have essentially no spam. I look at spam that gets to INBOX (which
means scores < 1, as I bin into "not spam", "maybe" and "spam") and
semi-look at "maybe" spam, and I haven't been noticing spam from
DNSWL_MED or DNSWL_HI.
There may be some way to ignore DNSWL_HI for that particular domain,
basically removing it for you. I'd expect dnsbl_skip, but I have no
idea.
After that, you can think about score tweaks. Perhaps interesting about
DNSWL_HI and SPF_SOFTFAIL, but probably not actually interesting.
Certainly you can make a meta rule that looks at BAYES_999,
DATE_IN_PAST_03_06, and DNSWL_HI and if so cancels the DNSWL_HI. But,
DNSWL_HI is meant to be a presumption of non-spam, so you can also turn
down DNSWL_HI, making -5 down to -2, or even put it at -0.01 so it is
essentially advisory. I of course don't know how much of your legit
mail is being saved from high scores by DNSWL_HI.
But do report it and let us know how that goes. It's an interesting
question how that's handled.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Arne Jensen <da...@darkdevil.dk>.
Den 06-04-2021 kl. 19:23 skrev Bill Cole:
> Because DNSWL has problematic sources,
Depending on the eyes looking at it, for NONE, maybe true? - "These are
legitimate mail servers, but they may also emit spam or have other
issues from time to time."
But there shouldn't be any kind of "problematic sources" triggering e.g.
RCVD_IN_DNSWL_HI, like it appears in OP's situation.
OP does however have a similar thread, "What makes this email spam and
how do I train myself to find markers for spam so I can train
spamassassin properly?" on 28th of March, indicating RCVD_IN_DNSWL_HI,
but with none of the IP's mentioned being listed at RCVD_IN_DNSWL_HI.
If you happen to know of any of such definitive "problematic sources"
that are listed, I suggest you report them ASAP, including any kind of
evidence/proof you may have of your claims.
--
Med venlig hilsen / Kind regards,
Arne Jensen
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 6 Apr 2021, at 11:48, Steve Dondley wrote:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some
> DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
> DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
> HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
> SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
> autolearn_force=no version=3.4.2
>
> What's the recommended way to handle these? Do I turn on shortcircuit?
Certainly NOT for Bayes, since it is fairly common for Bayes to be
simply wrong on essentially random messages. I personally don't think
shortcircuit qualifies as a generally useful feature in the modern
world.
> Do I bump up the score for BAYES_99, BAYES_999? Or might there be a
> way to ignore DNSWL scores if they have a high bayes score?
Rather than constructing a meta-rule for just that case, I adjust
scores:
score RCVD_IN_DNSWL_HI -2
score BAYES_00 -1.0
score BAYES_999 0.5
Because DNSWL has problematic sources, BAYES_00 is not really a great
ham indicator, and BAYES_999 is better than the default score gives it
credit for.
YMMV!
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Benny Pedersen <me...@junc.eu>.
On 2021-04-10 17:36, Steve Dondley wrote:
> Is anyone else seeing spam getting flagged with RCVD_DNSWL_HI
> resulting in so many false positives?
report this ip to dnswl with content as provding evedence, you know
admins from dnswl.org here recently asked for this ?
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Benny Pedersen <me...@junc.eu>.
On 2021-04-10 17:51, Steve Dondley wrote:
>> I have been looking at this issue a little more. I just grepped my
>> spam folder. Out of 1000 emails I have flagged as spam, 321 have been
>> flagged with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil.
>> That's almost 1 out of 3 emails which seems pretty insane.
>
> Here are the headers from some egregious spam. It scored a whopping
> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
> SPF_SOFTFAIL,SPOOFED_FREEMAIL,SPOOFED_FREEMAIL_NO_RDNS,
> SPOOFED_FREEM_REPTO,TVD_SPACE_ENCODED,URIBL_ABUSE_SURBL,URIBL_BLOCKED
while URIBL_BLOCKED :=)
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
On 2021-04-12 03:11 AM, Matthias Leisi wrote:
> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> https://www.dnswl.org/,
> high trust
> [203.160.71.180 listed in list.dnswl.org [1]] I looked up this, and the other one, and didn't find them in dnswl. As
> others said, if you are using public DNS, stop doing that immediately.
> And, run the dnswl queries with dig or host yourself on your own machine.
Answering to this mail, I could have used any of the others.
At dnswl.org [2], we have the fair use policy of 100'000 queries per 24
hours. Those that are consistently way above this threshold (either on
an individual IP, within a block of IPs or spread over multiple blocks)
may get blocked.
„Blocked" is not straightforward in DNS - if you simply return REFUSE
status code, resolvers may retry on other nameservers, thus effectively
multiplying the (useless) traffic. To avoid this, we have a number of
strategies:
* „pass" - for those we don't want to block
* „parentblock" - we do not return the actual NS records for the
list.dnswl.org [1] zone from the parent zone; all A records in
*.list.dnswl.org [1] return 127.0.0.255 and a corresponding TXT record -
that's the default strategy for most part of those that query above the
fair use threshold.
* „refuse" - see above, rarely used
* „empty" - we return NXDOMAIN. Not currently used.
* „ignore" - we don't return anything. Not currently used.
* „returnhi" - for those that try to evade „parentblock" (eg by
directly querying list.dnswl.org [1] nameservers), or who do not take
action after long times of „parentblock" (and which also did not change
behaviour on „refuse"), we return „hi" in order to make them go away
eventually.
* We may chose to escalate from single IPs to eg v4-/24 or
v6-/48-or-larger for active evaders (eg frequently changing nameserver
IPs), and we may also use „returnhi". Interstingly, we have a surprising
high number of „returnhi" cases which have been querying us for _years_
without a change in behaviour. From time to time we change them to one
of the other strategies. It would be interesting to dig in what they are
actually thinking...
It's likely that the OP is using a nameserver where we have „returnhi".
Obviously the advice given in this threat (use a local caching resolver
who does not forward queries) is correct and will that problem magically
go away :)
-- Matthias
Ah, thank you for the explanation.
Following the advice on this list, I set up a locally running running
DNS server. Since that time, I have not seen the problem of _HI scores
in my spam emails.
Links:
------
[1] http://list.dnswl.org
[2] http://dnswl.org
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Matthias Leisi <ma...@leisi.net>.
>> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>> https://www.dnswl.org/,
>> high trust
>> [203.160.71.180 listed in list.dnswl.org]
> I looked up this, and the other one, and didn't find them in dnswl. As
> others said, if you are using public DNS, stop doing that immediately.
> And, run the dnswl queries with dig or host yourself on your own machine.
Answering to this mail, I could have used any of the others.
At dnswl.org <http://dnswl.org/>, we have the fair use policy of 100’000 queries per 24 hours. Those that are consistently way above this threshold (either on an individual IP, within a block of IPs or spread over multiple blocks) may get blocked.
„Blocked“ is not straightforward in DNS - if you simply return REFUSE status code, resolvers may retry on other nameservers, thus effectively multiplying the (useless) traffic. To avoid this, we have a number of strategies:
„pass“ - for those we don’t want to block
„parentblock“ - we do not return the actual NS records for the list.dnswl.org <http://list.dnswl.org/> zone from the parent zone; all A records in *.list.dnswl.org return 127.0.0.255 and a corresponding TXT record - that’s the default strategy for most part of those that query above the fair use threshold.
„refuse“ - see above, rarely used
„empty“ - we return NXDOMAIN. Not currently used.
„ignore“ - we don’t return anything. Not currently used.
„returnhi“ - for those that try to evade „parentblock“ (eg by directly querying list.dnswl.org <http://list.dnswl.org/> nameservers), or who do not take action after long times of „parentblock“ (and which also did not change behaviour on „refuse“), we return „hi“ in order to make them go away eventually.
We may chose to escalate from single IPs to eg v4-/24 or v6-/48-or-larger for active evaders (eg frequently changing nameserver IPs), and we may also use „returnhi“. Interstingly, we have a surprising high number of „returnhi“ cases which have been querying us for _years_ without a change in behaviour. From time to time we change them to one of the other strategies. It would be interesting to dig in what they are actually thinking…
It’s likely that the OP is using a nameserver where we have „returnhi“.
Obviously the advice given in this threat (use a local caching resolver who does not forward queries) is correct and will that problem magically go away :)
— Matthias
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Greg Troxel <gd...@lexort.com>.
Steve Dondley <s...@dondley.com> writes:
> Note: I've changed the score of RCVD_IN_DNSWL_HI hits to -2.0 from
> -5.0 until I get my misconfiguration figured out. Thanks for your
> patience.
Fair enough; that's not an unreasonable thing to do.
Probably you want to turn report_safe to 0 for doing this testing.
> Content analysis details: (23.2 points, 5.0 required)
I would expect your MTA to be configured to hard reject mail that has a
score of 23. 15 if you're cautious, 10 if you're aggressive.
> pts rule name description
> ---- ----------------------
> --------------------------------------------------
> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> https://www.dnswl.org/,
> high trust
> [203.160.71.180 listed in list.dnswl.org]
I looked up this, and the other one, and didn't find them in dnswl. As
others said, if you are using public DNS, stop doing that immediately.
And, run the dnswl queries with dig or host yourself on your own machine.
> -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
> [203.160.71.180 listed in wl.mailspike.net]
This is H2, not higher, which is consistent with DNSWL_LO or
DNSWL_NONE. (Just a comment.)
> 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL
> [203.160.71.180 listed in psbl.surriel.com]
> 3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
> [score: 1.0000]
> 0.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
> [score: 1.0000]
> 2.0 LOCAL_SPAM_TLD Domain originates a lot of spam
> 1.0 LOCAL_UNCOMMON_TLD From address is not a common TLD
> 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
> bl.spamcop.net
> [Blocked - see
> <https://www.spamcop.net/bl.shtml?203.160.71.180>]
> 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL,
> https://senderscore.org/blocklistlookup/
> [203.160.71.180 listed in
> bl.score.senderscore.com]
So the address is in some blocklists.
> Received-SPF: Softfail (mailfrom) identity=mailfrom;
> client-ip=203.160.71.180; helo=yahoo.co.jp;
> envelope-from=qy5cbma-yua06@yahoo.co.jp; receiver=<UNKNOWN>
> Received: from yahoo.co.jp (unknown [203.160.71.180])
> by email.dondley.com (Postfix) with SMTP id 842C2210C0
> for <sd...@dondley.com>; Sat, 10 Apr 2021 05:49:55 -0400 (EDT)
Note the lack of rDNS, and what is probably a spoofed HELO.
So overall SA di the right thing: 23.5 is a score for an email that is
so spammy that I have no qualms about outright rejecting it.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
> It would be helpful to post an entire actual set of headers --
> unmodified -- along with the spamassassin -t report. I can't figure
> out (from what you posted) the IP address of the server that was in
> DNSWL_HI that delivered mail to your internal/trusted network.
OK, here is the entire output of this command:
sudo -u s -- spamassassin -t -d < the_spam_email
Note: I've changed the score of RCVD_IN_DNSWL_HI hits to -2.0 from -5.0
until I get my misconfiguration figured out. Thanks for your patience.
Received: from localhost by email.dondley.com
with SpamAssassin (version 3.4.2);
Sat, 10 Apr 2021 12:41:17 -0400
From:
=?shift_jis?B?kmqCzI/bkqWKZ5HljHaJ5iBBaXAxMA==?=<qy...@yahoo.co.jp>
To: <sd...@dondley.com>
Subject: *****SPAM*****
=?shift_jis?B?g0mDk4NpgqqLgYLfgumXQojqlrOT8YLMgZqDZoNKg2CDk4GagvCBSTA5?=
Date: Sat, 10 Apr 2021 18:50:01 +0900
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
email.dondley.com
X-Spam-Flag: YES
X-Spam-Level: ***********************
X-Spam-Status: Yes, score=23.2 required=5.0 tests=BASE64_LENGTH_79_INF,
BAYES_99,BAYES_999,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,FREEMAIL_REPLYTO,
FREEMAIL_REPLYTO_END_DIGIT,FROM_MISSP_FREEMAIL,FROM_MISSP_REPLYTO,
LOCAL_SPAM_TLD,LOCAL_UNCOMMON_TLD,MISSING_MID,NML_ADSP_CUSTOM_MED,
RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,RCVD_IN_PSBL,
RCVD_IN_RP_RNBL,RCVD_IN_VALIDITY_RPBL,RDNS_NONE,SPF_HELO_SOFTFAIL,
SPF_SOFTFAIL,SPOOFED_FREEMAIL,SPOOFED_FREEMAIL_NO_RDNS,
SPOOFED_FREEM_REPTO,TVD_SPACE_ENCODED shortcircuit=no autolearn=no
autolearn_force=no version=3.4.2
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_6071D52D.C7B255FE"
This is a multi-part message in MIME format.
------------=_6071D52D.C7B255FE
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Spam detection software, running on the system "email.dondley.com",
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
the administrator of that system for details.
Content preview:
@ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª
@@@@@@@ÆEÅÌ{¬·øÊ
@@@@@@@@@@yjXåTv
Content analysis details: (23.2 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
https://www.dnswl.org/,
high trust
[203.160.71.180 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[203.160.71.180 listed in wl.mailspike.net]
2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL
[203.160.71.180 listed in psbl.surriel.com]
3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
[score: 1.0000]
0.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
[score: 1.0000]
2.0 LOCAL_SPAM_TLD Domain originates a lot of spam
1.0 LOCAL_UNCOMMON_TLD From address is not a common TLD
1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
bl.spamcop.net
[Blocked - see
<https://www.spamcop.net/bl.shtml?203.160.71.180>]
1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL,
https://senderscore.org/blocklistlookup/
[203.160.71.180 listed in
bl.score.senderscore.com]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (qy5cbma-yua06[at]yahoo.co.jp)
0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in
digit (qy5cbma-yua06[at]yahoo.co.jp)
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record
(softfail)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
0.7 SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record
(softfail)
1.5 BASE64_LENGTH_79_INF BODY: base64 encoded email part uses line
length greater than 79 characters
0.5 MISSING_MID Missing Message-Id: header
0.0 RCVD_IN_RP_RNBL RCVD_IN_RP_RNBL renamed to
RCVD_IN_VALIDITY_RPBL, please update local
rules
0.8 RDNS_NONE Delivered to internal network by a host with
no rDNS
1.0 FREEMAIL_REPLYTO Reply-To/From or Reply-To/body contain
different freemails
0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing
list
0.0 FROM_MISSP_REPLYTO From misspaced, has Reply-To
2.5 TVD_SPACE_ENCODED Space ratio & encoded subject
0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS
2.0 SPOOFED_FREEMAIL No description available.
2.0 SPOOFED_FREEM_REPTO Forged freemail sender with freemail
reply-to
0.0 FROM_MISSP_FREEMAIL From misspaced + freemail provider
------------=_6071D52D.C7B255FE
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Received-SPF: Softfail (mailfrom) identity=mailfrom;
client-ip=203.160.71.180; helo=yahoo.co.jp;
envelope-from=qy5cbma-yua06@yahoo.co.jp; receiver=<UNKNOWN>
Received: from yahoo.co.jp (unknown [203.160.71.180])
by email.dondley.com (Postfix) with SMTP id 842C2210C0
for <sd...@dondley.com>; Sat, 10 Apr 2021 05:49:55 -0400 (EDT)
To: <sd...@dondley.com>
From:
=?shift_jis?B?kmqCzI/bkqWKZ5HljHaJ5iBBaXAxMA==?=<qy...@yahoo.co.jp>
Subject:
=?shift_jis?B?g0mDk4NpgqqLgYLfgumXQojqlrOT8YLMgZqDZoNKg2CDk4GagvCBSTA5?=
MIME-Version: 1.0
Reply-To: <qy...@yahoo.co.jp>
Date: Sat, 10 Apr 2021 18:50:01 +0900
Content-Type:text/plain; charset="shift_jis"
Content-Transfer-Encoding: base64
gUCEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqDQoNCg0KgUCBQIFAgUCBQIFAgUCBmYvGikWNxY2CgsyDe4OLg4KDk5CskreM+InKgZkNCg0KgUCBQIFAgUCBQIFAgUCBQIFAgUCBmoN5g2qDWJGdkeWDVIN2g4qBmg0KDQqBQIFAgUCBQIFAgUCCYIKHgo6ChYKTgWmDQYNqg0eDWCCDToOJg1ggg3iBW4NWg2KDToFqDQoNCg0KgUCEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqgXuEqoF7hKqBe4SqDQoNCoFAgUCVvYvPk0mCyJCskGyPl5CrgqqR5YKrgqKCxoq0graC6YN5g2qDWINUg0ODWYLNMTYuNGNtiMiP4w0KDQoNCoFAgUCBQIFAgUCBQIFAgUCDZoSrg0qEq4NghKuDk4SrgUWEq4uQhKuNqoSrDQqBQIFAgUCBQIFAgUCBQIFAhKqEroSqhK6EqoSuhKqEroSqhK6EqoSuhKqErg0KDQoNCoFAgUCBQIFAgUCBQINJg5ODaYKqi4GC34Lpl0KI6pazk/GCzINKg4mDX4LJifyRog0KDQoNCg0Kj6SVaY/ajdeCzYKxgr+C54KpgueBq4GrgauBq4GrgauBq4GrDQpodHRwczovL2JpdC5seS8zcGtaOEc0DQoNCg0KDQoNCoFAgUCBQCouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkqLiqBmQ0KDQqBQIFAgUCBQJGXl7+Ws5e/gsWCqJSDgqKTvoNMg4ODk4N5gVuDk47AjnuShoFJDQoNCg0KgUCBQIFAgUCBQIFAgUCDQYNqg0eDWCCDToOJg1ggg3iBW4NWg2KDTg0KgUCBQIFAgUCBQIFAgUCBQIFAgUCPiYnxjMCS6DY0gZ
NPRkYNCg0KDQqBQIFAgUCBQIFAgUCBQIFAgUCBQJLKj+2Jv4ppMTgsOTAwiX4NCg0KgUCBQIFAgUCBQIFAgUCBQIFAgUCBq4GrgauBq4GrgauBq4GrDQoNCoFAgUCBQIFAgUCBQIFAgUCBQIFAgUA2LDk4MIl+gWmQxY2egWoNCg0KDQqBQIFAgUAqLiqBmSouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkNCg0KgUCBQIOPg1CCqoKggumBSYFIj5eQq4LMkKuKtJHRg3yDi4Ngg0mCxoN5g2qDWILJkeWCq4KzDQoNCoFAgUCBQIFAMTYuNGNtiMiP44LMg3mDaoNYg1SDQ4NZgqqIpIKzguqC6Zedl1INCg0KgUCBQI7Ags2CsYLMMTYuNGNtiMiP44LMg3mDaoNYg1SDQ4NZgqqIpIKzguqC6Zedl1KCzaWlpQ0KDQqBQI53gsiCx4LFgs2TzYKrgsmCrYKijnGLe4x6lZSCzIN8g4uDYINJkKuKtJHRgvCOaIyDgreC6Q0KgUCCzILJlUuXdoLIg1SDQ4NZgUIgDQoNCoFAg3yDi4Ngg0mCzYzjk1aTSYLIkKuKtJHRgsWCoILogUGWoopKlK2CyI/qjYeCzZP3gqqNZIKtDQqBQILIgsGCxIKigtyCt4FCIA0KDQqBQI9dgsGCxIxvjLGCzJDzgqKPl5Crgs2SyYKqgumCsYLGguCCoILpiOqV+4LFgUGMb4yxlkyVeA0KgUCPl5CrguKPb45ZjG+MsYLMgqCC6ZBsgs2T94Kqj1+C54Kpgq2CyILogUGOcYt7jPuC4IpKgq0NCoFAgsyCxYN8g4uDYINJgsyJ9Yq0gvCTvoLigreCooLGjL6C7YLqgsSCqILogUGPb45ZjOOC3IK9DQqBQILNlE6C8JLHgqSCsoLGgsmKtJN4gqqP44KqgsGCvZOZgsaMvoLtguqCxIKigumRrZDggs2CsQ0
KgUCCzIjXgsaCs4LqgsSCooLcgreBQg0KDQqBQIK7grWCxIKxgsyDfIOLg2CDSZCrirSR0YLFk76C6oLpifWKeYLNgUGCyILxgsaCZoNYg3yDYoNnDQqBQILMlvGCVYFgMTCUe4LGgrOC6oLEgqiC6IFBiOqTeJahgu2CpoLOllmC6oLnguqCyIKiguaCpILIDQqBQIn1irSC8JO+gumCxoKzguqC6Y+XkKuCzI3FjYKCzIn1irSDWIN8g2KDZ4LGgrOC6oLEgqKC3IK3gUINCg0KDQqBQIFAgUAqLiqBmSouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkqLiqBmSouKoGZKi4qgZkNCg0KDQqPpJVpj9qN14LNgrGCv4LngqmC54GrgauBq4GrgauBq4GrgasNCmh0dHBzOi8vYml0Lmx5LzNwa1o4RzQNCg0KDQoNCg0KDQoNCg0KDQoNCoOBg4uDfYNLkuKOfoLNgrGCv4LngtyCxQ0KYTFfaW5mbzAxQHlhaG9vLmNvLmpwDQoNCoGmg0GDaIOMg1iC8JWhkJSCqI6dgr+CzJX7gs2BQZVLgriShZBNg0GDaIOMg1iCzA0KgrKKbZRGgqiK6IKigqKCvYK1gtyCt4FCDQo=
------------=_6071D52D.C7B255FE--
Spam detection software, running on the system "email.dondley.com",
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
the administrator of that system for details.
Content preview:
@ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª{ª
@@@@@@@ÆEÅÌ{¬·øÊ
@@@@@@@@@@yjXåTv
Content analysis details: (23.2 points, 5.0 required)
pts rule name description
---- ----------------------
--------------------------------------------------
-2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
https://www.dnswl.org/,
high trust
[203.160.71.180 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[203.160.71.180 listed in wl.mailspike.net]
2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL
[203.160.71.180 listed in psbl.surriel.com]
3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
[score: 1.0000]
0.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
[score: 1.0000]
2.0 LOCAL_SPAM_TLD Domain originates a lot of spam
1.0 LOCAL_UNCOMMON_TLD From address is not a common TLD
1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in
bl.spamcop.net
[Blocked - see
<https://www.spamcop.net/bl.shtml?203.160.71.180>]
1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL,
https://senderscore.org/blocklistlookup/
[203.160.71.180 listed in
bl.score.senderscore.com]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (qy5cbma-yua06[at]yahoo.co.jp)
0.2 FREEMAIL_REPLYTO_END_DIGIT Reply-To freemail username ends in
digit (qy5cbma-yua06[at]yahoo.co.jp)
0.7 SPF_SOFTFAIL SPF: sender does not match SPF record
(softfail)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED
0.7 SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record
(softfail)
1.5 BASE64_LENGTH_79_INF BODY: base64 encoded email part uses line
length greater than 79 characters
0.5 MISSING_MID Missing Message-Id: header
0.0 RCVD_IN_RP_RNBL RCVD_IN_RP_RNBL renamed to
RCVD_IN_VALIDITY_RPBL, please update local
rules
0.8 RDNS_NONE Delivered to internal network by a host with
no rDNS
1.0 FREEMAIL_REPLYTO Reply-To/From or Reply-To/body contain
different freemails
0.9 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing
list
0.0 FROM_MISSP_REPLYTO From misspaced, has Reply-To
2.5 TVD_SPACE_ENCODED Space ratio & encoded subject
0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS
2.0 SPOOFED_FREEMAIL No description available.
2.0 SPOOFED_FREEM_REPTO Forged freemail sender with freemail
reply-to
0.0 FROM_MISSP_FREEMAIL From misspaced + freemail provider
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Greg Troxel <gd...@lexort.com>.
Steve Dondley <s...@dondley.com> writes:
> On 2021-04-10 12:10 PM, Greg Troxel wrote:
>> Steve Dondley <s...@dondley.com> writes:
>>
>>> Here are the headers from some egregious spam. It scored a whopping
>>> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>>>
>>> Return-Path: <qp...@yahoo.co.jp>
>>> Delivered-To: s@example.com
>>> Received: from email.example.com
>>> by email.example.com with LMTP
>>> id AnV2NSCZbmCTcQAAB604Gw
>>> (envelope-from <qp...@yahoo.co.jp>)
>>> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
>>
>> really? Those are the headers?
>
> Yes. Why do you ask? Is it unusual that this egregious example of spam
> is on DNSWL_HI?
I don't see the header added by your MTA with the IP address of the
source. And example.com is bogus; it looks like you edited things and
removed information.
>> So my advice again is:
>>
>> Run spamassassin -t on the message so you see the metadata about the
>> rules like which IP hit and the per-rule score.
>
> I've already done that on selective email messages.
It would be helpful to post an entire actual set of headers --
unmodified -- along with the spamassassin -t report. I can't figure
out (from what you posted) the IP address of the server that was in
DNSWL_HI that delivered mail to your internal/trusted network.
>> If you got spam from a sender in DNSWL_HI, report it to dnswl.org.
>> Give them a week and see if they take the IP out, or what happens,
>> and
>> tell us how it went.
>
> I plan on it but first:
>
> 1) I want to verify with this list I don't have something
> misconfigured before I report 300+ emails. From what I've read in the
> emails last week, this would be highly unusual.
It would, and if you haven't munged the headers that you posted, things
seem very very odd on your end to me.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 10 Apr 2021, at 12:19, Steve Dondley wrote:
> On 2021-04-10 12:10 PM, Greg Troxel wrote:
>> Steve Dondley <s...@dondley.com> writes:
>>
>>> Here are the headers from some egregious spam. It scored a whopping
>>> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>>>
>>> Return-Path: <qp...@yahoo.co.jp>
>>> Delivered-To: s@example.com
>>> Received: from email.example.com
>>> by email.example.com with LMTP
>>> id AnV2NSCZbmCTcQAAB604Gw
>>> (envelope-from <qp...@yahoo.co.jp>)
>>> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
>>
>> really? Those are the headers?
>
> Yes. Why do you ask? Is it unusual that this egregious example of spam
> is on DNSWL_HI?
It's not that, it's the fact that you appear to have provided the
headers of the 'wrapper' message that SA creates and re-injects when
report_safe=1 or report_safe=2 rather than the actual headers of the
original message.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>>Steve Dondley <s...@dondley.com> writes:
>>>Here are the headers from some egregious spam. It scored a whopping
>>>20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>>>
>>>Return-Path: <qp...@yahoo.co.jp>
>>>Delivered-To: s@example.com
>>>Received: from email.example.com
>>> by email.example.com with LMTP
>>> id AnV2NSCZbmCTcQAAB604Gw
>>> (envelope-from <qp...@yahoo.co.jp>)
>>> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
>On 2021-04-10 12:10 PM, Greg Troxel wrote:
>>really? Those are the headers?
On 10.04.21 12:19, Steve Dondley wrote:
>Yes. Why do you ask? Is it unusual that this egregious example of spam
>is on DNSWL_HI?
there are too few e-mail headers there, and it looks like the mail was
submitted from your machine.
We even don't see the IP that's supposed to be in dnswl.
>>So my advice again is:
>>
>> Run spamassassin -t on the message so you see the metadata about the
>> rules like which IP hit and the per-rule score.
>
>I've already done that on selective email messages.
>
>> If you got spam from a sender in DNSWL_HI, report it to dnswl.org.
>> Give them a week and see if they take the IP out, or what happens,
>>and
>> tell us how it went.
>
>I plan on it but first:
>
>1) I want to verify with this list I don't have something
>misconfigured before I report 300+ emails. From what I've read in the
>emails last week, this would be highly unusual.
>
>2) If I do have that many false positives, I need to figure out how to
>bulk report that many of them.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
On 2021-04-10 12:10 PM, Greg Troxel wrote:
> Steve Dondley <s...@dondley.com> writes:
>
>> Here are the headers from some egregious spam. It scored a whopping
>> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>>
>> Return-Path: <qp...@yahoo.co.jp>
>> Delivered-To: s@example.com
>> Received: from email.example.com
>> by email.example.com with LMTP
>> id AnV2NSCZbmCTcQAAB604Gw
>> (envelope-from <qp...@yahoo.co.jp>)
>> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
>
> really? Those are the headers?
Yes. Why do you ask? Is it unusual that this egregious example of spam
is on DNSWL_HI?
> So my advice again is:
>
> Run spamassassin -t on the message so you see the metadata about the
> rules like which IP hit and the per-rule score.
I've already done that on selective email messages.
> If you got spam from a sender in DNSWL_HI, report it to dnswl.org.
> Give them a week and see if they take the IP out, or what happens,
> and
> tell us how it went.
I plan on it but first:
1) I want to verify with this list I don't have something misconfigured
before I report 300+ emails. From what I've read in the emails last
week, this would be highly unusual.
2) If I do have that many false positives, I need to figure out how to
bulk report that many of them.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Greg Troxel <gd...@lexort.com>.
Steve Dondley <s...@dondley.com> writes:
> Here are the headers from some egregious spam. It scored a whopping
> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>
> Return-Path: <qp...@yahoo.co.jp>
> Delivered-To: s@example.com
> Received: from email.example.com
> by email.example.com with LMTP
> id AnV2NSCZbmCTcQAAB604Gw
> (envelope-from <qp...@yahoo.co.jp>)
> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
really? Those are the headers?
So my advice again is:
Run spamassassin -t on the message so you see the metadata about the
rules like which IP hit and the per-rule score.
If you got spam from a sender in DNSWL_HI, report it to dnswl.org.
Give them a week and see if they take the IP out, or what happens, and
tell us how it went.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 10 Apr 2021, at 12:55, Steve Dondley wrote:
>> You should fix URIBL_BLOCKED first.
>> You need a local, caching, non-forwarding DNS server for
>> SpamAssassin.
>
> Yeah, setting up a DNS server for SA is on my todo list. Thanks.
>
> When you say local, it doesn't have to be on the same machine as
> spamassassin, does it? I assume I can have the DNS server on a local
> network and shared between many machines.
Sure, but it is very simple to stand up a caching, non-forwarding,
local-only resolver with Unbound or the Knot Resolver (which are
designed for just that) or even BIND (which has broader applications) on
most Linux distros, on FreeBSD, or on pre-Catalina MacOS X. It becomes a
slightly more complicated task when you try to make it serve many
machines. It also may come to pass that you want to do things at the DNS
level which are only appropriate for your mail server and not your other
machines.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
> You should fix URIBL_BLOCKED first.
> You need a local, caching, non-forwarding DNS server for SpamAssassin.
Yeah, setting up a DNS server for SA is on my todo list. Thanks.
When you say local, it doesn't have to be on the same machine as
spamassassin, does it? I assume I can have the DNS server on a local
network and shared between many machines.
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by jw...@gmail.com.
Steve Dondley writes:
> From: Steve Dondley <s...@dondley.com>
> Date: Sat, 10 Apr 2021 11:51:16 -0400
>
>
> > I have been looking at this issue a little more. I just grepped my
> > spam folder. Out of 1000 emails I have flagged as spam, 321 have been
> > flagged with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil.
> > That's almost 1 out of 3 emails which seems pretty insane.
>
> Here are the headers from some egregious spam. It scored a whopping 20.8
> point despite being flagged with "RCVD_IN_DNSWL_HI."
>
> Return-Path: <qp...@yahoo.co.jp>
> Delivered-To: s@example.com
> Received: from email.example.com
> by email.example.com with LMTP
> id AnV2NSCZbmCTcQAAB604Gw
> (envelope-from <qp...@yahoo.co.jp>)
> for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
> Received: by email.example.com (Postfix, from userid 115)
> id CDD3D210E1; Thu, 8 Apr 2021 01:48:16 -0400 (EDT)
> Received: from localhost by email.example.com
> with SpamAssassin (version 3.4.2);
> Thu, 08 Apr 2021 01:48:16 -0400
> From:
> DVD Aip08 <qp...@yahoo.co.jp>
> To: <ex...@example.com>
> Subject: *****SPAM*****
> AV 07
> Date: Thu, 08 Apr 2021 14:48:09 +0900
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
> email.example.com
> X-Spam-Flag: YES
> X-Spam-Level: ********************
> X-Spam-Status: Yes, score=20.8 required=5.0 tests=BASE64_LENGTH_79_INF,
> DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,FREEMAIL_REPLYTO,
> FREEMAIL_REPLYTO_END_DIGIT,FROM_MISSP_FREEMAIL,FROM_MISSP_REPLYTO,
> MISSING_MID,NML_ADSP_CUSTOM_MED,RCVD_IN_BL_SPAMCOP_NET,
> RCVD_IN_DNSWL_HI,RCVD_IN_PSBL,RCVD_IN_RP_RNBL,RCVD_IN_SBL_CSS,
> RCVD_IN_VALIDITY_RPBL,RCVD_IN_XBL,RDNS_NONE,SPF_HELO_SOFTFAIL,
> SPF_SOFTFAIL,SPOOFED_FREEMAIL,SPOOFED_FREEMAIL_NO_RDNS,
> SPOOFED_FREEM_REPTO,TVD_SPACE_ENCODED,URIBL_ABUSE_SURBL,URIBL_BLOCKED
> shortcircuit=no autolearn=unavailable autolearn_force=no version=3.4.2
> MIME-Version: 1.0
> Content-Type: multipart/mixed; boundary="----------=_606E9920.15B94EAE"
> Message-Id: <20...@email.example.com>
>
You should fix URIBL_BLOCKED first.
You need a local, caching, non-forwarding DNS server for SpamAssassin.
I haven't noticed much of any spam hitting DNSWL HI. I suspect you
have some other configuration issue.
-jeff
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Arne Jensen <da...@darkdevil.dk>.
You do obviously have a very misconfigured system on your end.
Den 10-04-2021 kl. 17:51 skrev Steve Dondley:
>
> X-Spam-Status: Yes, score=20.8 required=5.0 tests=BASE64_LENGTH_79_INF,
> [...]
> ***RCVD_IN_DNSWL_HI***,RCVD_IN_PSBL,RCVD_IN_RP_RNBL,RCVD_IN_SBL_CSS,
> RCVD_IN_VALIDITY_RPBL,RCVD_IN_XBL,***RDNS_NONE***,SPF_HELO_SOFTFAIL,
> [...]
DNSWL does not list any IP addresses without Reverse DNS (PTR), that
also matches with the forward DNS ( see the markings above ! ).
- So maybe you should look at your set up, instead of continuing your
game of claiming false positives with DNSWL?
- Again, maybe you should put up the FULL MESSAGE, instead of only
partial / munged headers?
Maybe then, and only then, there would be much more suggestions for how
to proceed.
--
Med venlig hilsen / Kind regards,
Arne Jensen
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
> I have been looking at this issue a little more. I just grepped my
> spam folder. Out of 1000 emails I have flagged as spam, 321 have been
> flagged with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil.
> That's almost 1 out of 3 emails which seems pretty insane.
Here are the headers from some egregious spam. It scored a whopping 20.8
point despite being flagged with "RCVD_IN_DNSWL_HI."
Return-Path: <qp...@yahoo.co.jp>
Delivered-To: s@example.com
Received: from email.example.com
by email.example.com with LMTP
id AnV2NSCZbmCTcQAAB604Gw
(envelope-from <qp...@yahoo.co.jp>)
for <s...@example.com>; Thu, 08 Apr 2021 01:48:16 -0400
Received: by email.example.com (Postfix, from userid 115)
id CDD3D210E1; Thu, 8 Apr 2021 01:48:16 -0400 (EDT)
Received: from localhost by email.example.com
with SpamAssassin (version 3.4.2);
Thu, 08 Apr 2021 01:48:16 -0400
From:
=?shift_jis?B?i9aSZoLMl6BEVkSP7pXxIEFpcDA4jYY=?=<qp...@yahoo.co.jp>
To: <ex...@example.com>
Subject: *****SPAM*****
=?shift_jis?B?lrOPQ5Czi8mU6Zesj2+DVoOKgVuDWYFFg4KDVYNDg06UaonzgUWXTJa8QVaPl5dEgXmXoIOCg22JroF6MDc=?=
Date: Thu, 08 Apr 2021 14:48:09 +0900
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
email.example.com
X-Spam-Flag: YES
X-Spam-Level: ********************
X-Spam-Status: Yes, score=20.8 required=5.0 tests=BASE64_LENGTH_79_INF,
DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,FREEMAIL_REPLYTO,
FREEMAIL_REPLYTO_END_DIGIT,FROM_MISSP_FREEMAIL,FROM_MISSP_REPLYTO,
MISSING_MID,NML_ADSP_CUSTOM_MED,RCVD_IN_BL_SPAMCOP_NET,
RCVD_IN_DNSWL_HI,RCVD_IN_PSBL,RCVD_IN_RP_RNBL,RCVD_IN_SBL_CSS,
RCVD_IN_VALIDITY_RPBL,RCVD_IN_XBL,RDNS_NONE,SPF_HELO_SOFTFAIL,
SPF_SOFTFAIL,SPOOFED_FREEMAIL,SPOOFED_FREEMAIL_NO_RDNS,
SPOOFED_FREEM_REPTO,TVD_SPACE_ENCODED,URIBL_ABUSE_SURBL,URIBL_BLOCKED
shortcircuit=no autolearn=unavailable autolearn_force=no version=3.4.2
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_606E9920.15B94EAE"
Message-Id: <20...@email.example.com>
Re: DNSWL overriding bayes_99 and bayes_999 rules
Posted by Steve Dondley <s...@dondley.com>.
On 2021-04-06 11:48 AM, Steve Dondley wrote:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some
> DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
> DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
>
> HTML_IMAGE_RATIO_02,HTML_MESSAGE,RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H2,
> SPF_HELO_NONE,SPF_SOFTFAIL shortcircuit=no autolearn=no
> autolearn_force=no version=3.4.2
>
> What's the recommended way to handle these? Do I turn on shortcircuit?
> Do I bump up the score for BAYES_99, BAYES_999? Or might there be a
> way to ignore DNSWL scores if they have a high bayes score?
I have been looking at this issue a little more. I just grepped my spam
folder. Out of 1000 emails I have flagged as spam, 321 have been flagged
with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil. That's
almost 1 out of 3 emails which seems pretty insane.
Is anyone else seeing spam getting flagged with RCVD_DNSWL_HI resulting
in so many false positives?