You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2023/11/10 13:26:37 UTC
[Bug 8193] New: RCVD_IN_DNSWL_HI false positives
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Bug ID: 8193
Summary: RCVD_IN_DNSWL_HI false positives
Product: Spamassassin
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: RuleQA
Assignee: dev@spamassassin.apache.org
Reporter: krumboeck@universalnet.at
Target Milestone: Undefined
Hello!
When I set up several mail gateways, I noticed that a high rate of the spams
are delivered because of the Rule RCVD_IN_DNSWL_HI. The Bayes DB may even be
poisoned.
As long as the false positive rate of DNSWL.ORG is so high, the score of this
rule should be changed (proposal: -0.1)!
It currently acts as a gate for spammer.
best regards
Bernd
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #15 from Sidney Markowitz <si...@sidney.com> ---
I was mistaken about how it works: __RCVD_IN_DNSWL has to be defined the way it
is because it calls check_rbl and the other rules call check_rbl_sub
However, even though meta rules do not need a score entry, they can be disabled
by giving them a score entry of 0
Is there anything wrong with adding this line to rules/50_scores.cf?
score __RCVD_IN_DNSWL 0 # meta rule. Comment out to enable it, no score is
necessary
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #5 from Stefan <mu...@g0v.org> ---
I have wasted a several hours of my time because of this problem, and I want to
share what I discovered.
In response to Benny, it turns out there is nothing wrong with the set-up of
SpamAssassin on my server and no one was being "ignorant".
It turns out that this is ENTIRELY INTENTIONAL BEHAVIOR by dnswl.org:
https://www.dnswl.org/?p=120
Summary: Those who haven't paid (or haven't paid enough) eventually start
receiving "whitelisted" for ALL queries. In other words, false positives for
ALL spammers.
Not only that, dnswl.org does not make this at all clear on the main pages of
its website. This took a lot of digging. They also hide their pricing behind
a log-in. These are not the behaviors of a reputable or ethical organization.
I fail to understand why SpamAssassin doesn't warn users about this, why it
finds this type of behavior acceptable coming from one of its partner services,
and why it places a very high negative spam score of -5.0 on these false
positives.
At the very least, dnswl.org should simply be blocking non-paying users instead
of returning false positives, so that SpamAssassin assigns a score of 0.0
instead of -5.0 (just like they do with the various blacklists that block
queries).
Instead, SpamAssassin and dnswl.org work together to 'punish' web hosting
companies by deliberately poisoning their customers' spam filters. Punish the
peasants to teach the king a lesson.
My web hosting company's solution is: Set all dnswl.org-related scores to 0.0.
At this point I can't argue about that; dnswl.org are making themselves
irrelevant through their irresponsible behavior.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #23 from Benny Pedersen <me...@junc.eu> ---
tux ~ # dig junc.eu.dwl.dnswl.org
junc.eu.dwl.dnswl.org. 3600 IN A 127.0.5.1
tux ~ # dig dnswl.org.dwl.dnswl.org
dwl.dnswl.org. 10800 IN SOA a.dwl-ns.dnswl.org.
admins.dnswl.org. 1727185686 3600 300 432000 43200
do i need to dukoment it more ? :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #31 from Sidney Markowitz <si...@sidney.com> ---
I'm re-opening this as dnswl.org has removed their wrong results entries while
we conduct experiments on approaches that will work for them while complying
with our policies for free for most dnsbls in our default configuration.
I'm re-enabling dnswl rules and will leave this issue open until it is resolved
one way or the other.
FSL_BULK_SIG KHOP_HELO_FCRDNS can be put back in as a final step after this is
all resolved.
% svn ci -m "Bug 8193 - Re-enable DNSWL rules in rules update"
rules/25_dnswl.cf rules/50_scores.cf
Adding rules/25_dnswl.cf
Sending rules/50_scores.cf
Transmitting file data ..done
Committing transaction...
Committed revision 1921008.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #33 from Bill Cole <bi...@apache.org> ---
(In reply to Sidney Markowitz from comment #32)
> I'm considering setting in a file for rule updates
> dns_block_time 3600
> instead of leaving it set to the default 300 seconds.
+1
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #30 from John Hardin <jh...@impsec.org> ---
(In reply to John Hardin from comment #29)
> (In reply to Sidney Markowitz from comment #28)
> > Deleting rules/25_dnswl.cf
>
> There are a couple of meta rules that depend on __RCVD_IN_DNSWL that this
> probably breaks, did you run a lint after making that change?
>
> FSL_BULK_SIG
> KHOP_HELO_FCRDNS
Fixed.
Commit Modified
/home/jhardin/develop/spamassassin/svn/trunk/rulesrc/sandbox/khopesh/20_khop_experimental.cf
Commit Modified
/home/jhardin/develop/spamassassin/svn/trunk/rulesrc/sandbox/smf/30_smf_nontest.cf
Committed revision 1920889.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #22 from Sidney Markowitz <si...@sidney.com> ---
(In reply to Benny Pedersen from comment #21)
According to
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/DnsBlocklists
it will work to either set score 0 of every rule that is defined to call
eval:check_rbl on the dnsbl you want to disable, or use dns_query_restriction
deny for that domain.
Since I'm trying to come up with what we can do in rule updates to disable
default use of dnswl.org I was talking about the choice of setting the rule
scores to 0.
But now I'm looking at the third alternative, removing the rule definitions
completely. Without __RCVD_IN_DNSWL being defined there is no reason to set its
score to 0 or to configure dns_query_restriction deny dnswl.org.
I agree that if I was configuring my local files to disable some dnsbl I might
use dns_query_restriction instead.
By the way, I can't find any mention of dwl.dnswl.org in the default rules or
configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #8 from Stefan <mu...@g0v.org> ---
(In reply to Bill Cole from comment #6)
> (In reply to Stefan from comment #5)
> > I have wasted a several hours of my time because of this problem, and I want
> > to share what I discovered.
> >
> > In response to Benny, it turns out there is nothing wrong with the set-up of
> > SpamAssassin on my server and no one was being "ignorant".
>
> Well, that's not exactly true.
>
> No one should be running SA in a configuration that violates the policies of
> the 3rd-party services that it supports. I don't believe that is explicitly
> stated in any documentation, as it is a fundamental rule: it should not need
> stating.
>
> > It turns out that this is ENTIRELY INTENTIONAL BEHAVIOR by dnswl.org:
> >
> > https://www.dnswl.org/?p=120
> >
> > Summary: Those who haven't paid (or haven't paid enough) eventually start
> > receiving "whitelisted" for ALL queries. In other words, false positives
> > for ALL spammers.
>
> The available solutions to dnswl.org providing you bogus information as a
> direct consequence of your behavior all require you to behave differently.
> You can either stop querying dnswl.org or treat them like any other
> commercial service provider by paying their charges for your usage.
>
> > Not only that, dnswl.org does not make this at all clear on the main pages
> > of its website. This took a lot of digging. They also hide their pricing
> > behind a log-in. These are not the behaviors of a reputable or ethical
> > organization.
>
> Yes, despite the .org domain they appear to be a commercial operation rather
> than a charitable organization. You can expect any organization designed for
> making money rather than to serve a charitable function to sometimes be less
> kind than you would like.
>
> > I fail to understand why SpamAssassin doesn't warn users about this, why it
> > finds this type of behavior acceptable coming from one of its partner
> > services, and why it places a very high negative spam score of -5.0 on these
> > false positives.
>
> You are overestimating the strength of the relationship between the
> Spamassassin project and 3rd-party service providers.
>
> Personally, I was unaware of that policy, as it diverges from the widely
> used best practice for DNS-based lists: using distinct DNS results for
> policy violations. Knowing that they are doing so, I agree that we should
> not have their lists enabled by default. I will be raising this question
> with others in the community and the PMC.
>
> > At the very least, dnswl.org should simply be blocking non-paying users
> > instead of returning false positives, so that SpamAssassin assigns a score
> > of 0.0 instead of -5.0 (just like they do with the various blacklists that
> > block queries).
>
> That's NOT what the others do. All of the SA "BLOCKED" rules match on
> policy-specific replies. As that dnswl.org page notes, refusing queries is
> not useful because it garners no attention from those being refused and
> won't even be really visible to the worst offenders, those who refuse to
> operate their own recursive DNS resolvers and instead use free public
> resolvers.
>
> If I thought it would be welcomed in the community, I'd make all of the
> "BLOCKED" rules score significant negative (i.e. hammy) scores so people
> would fix their configs…
>
> > Instead, SpamAssassin and dnswl.org work together to 'punish' web hosting
>
> WE DO NOT WORK "TOGETHER" WITH DNSWL IN ANY WAY.
>
> The 3rd-party services referenced in SA use the same free public mechanisms
> that can be used by anyone without SA. We don't set their policies or
> actively track changes. Changing defaults for such services is done on an
> as-noticed as-needed basis without considering the preferences of the
> operator of the 3rd-party service.
>
> Devising conspiracy theories to explain filters not doing the job you expect
> them to do is not productive. Spam filters make mistakes by their nature,
> and it requires no one nefariously working together to make you sad. Really.
>
>
> > companies by deliberately poisoning their customers' spam filters. Punish
> > the peasants to teach the king a lesson.
>
> Nothing in SA exists to punish SA users at any level or teach them any sort
> of lesson as a consequence of unwise behavior.
>
> If you believe otherwise, I urge you to not use SA. No one should use what
> they believe to be Fascist software.
>
> > My web hosting company's solution is: Set all dnswl.org-related scores to
> > 0.0. At this point I can't argue about that; dnswl.org are making
> > themselves irrelevant through their irresponsible behavior.
>
> All mail servers acting as public MXs should be running their own local
> recursive DNS resolver, rather than relying on any sort of "upstream"
> provider. This is a widely recognized best practice for many reasons, not
> just the issue of one list operator engaging in hostile self-defense.
>
> Anyone using a free DNS-Based List (or other free service) as a part of
> their commercial offerings needs to be aware that even with their own
> resolvers, they are burdening the list operators and those who provide list
> secondaries with their queries. It is your moral obligation to pay for
> services that you rely upon according to the policies of the service
> provider. If your query volume is higher than a lists's limits on free use,
> you are ethically required to stop or to pay for it.
>
> Setting ALL DNSWL rules to zero is one way to assure that you don't get
> bogus results from them, because you won't query them. Other ways include
> (*in addition* to the baseline of using your own recursive resolvers)
> staying below their limit for free use or paying them for more usage.
Hi Bill,
Thank you for responding.
My web host may be penny-pinching or incompetent, I don't know. But this is no
reason for dnswl.org to silently poison innocent users' spam detection systems
and cause hours of frustration while they try to track this problem down. I
posted in response to this bug report so that others don't waste half a day on
this like I did.
SpamAssassin should add a comment along the lines of "Your web host is acting
irresponsibly so your spam scores may be inaccurate." Simple, honest, gets the
job done, many users will complain to their web hosts, web hosts will be
embarrassed into taking action.
SpamAssassin currently includes the following text, literally, in the headers
of every email it lets through due to dnswl.org's deliberately false positives
(only the IP address varies):
RBL: Sender listed at https://www.dnswl.org/,
high trust
[88.209.197.217 listed in list.dnswl.org]
Read the words and compare them to reality:
"Sender listed at https://www.dnswl.org/" -- FALSE STATEMENT
"high trust" -- FALSE STATEMENT
"88.209.197.217 listed in list.dnswl.org" -- FALSE STATEMENT
When someone states something categorically, knowing it is false, that's called
a lie.
Unfortunately, SpamAssassin does not help matters by applying a massive -5.0
point bonus to genuine spam messages because of this falsehood.
And it's all done in complete silence, leaving users spammed and confused. No
warnings, no explanations, anywhere.
> You are overestimating the strength of the relationship between
> the Spamassassin project and 3rd-party service providers.
Surely SpamAssassin personnel are not so naive that they don't know what a
major spam-fighting partner organization (dnswl.org) is doing, despite the fact
that their query responses contribute a larger spam score (-5.0) than almost
any other rule or organization? SpamCop gets only a +1.3 score, others even
less.
> That's NOT what the others do. All of the SA "BLOCKED"
> rules match on policy-specific replies.
All of the (many) "BLOCKED" rules that I have seen apply a score of 0.0,
thereby having no overall effect. Applying -5.0 effectively turns "spam" into
"probably not spam" most of the time. Massive difference.
> refusing queries is not useful because it
> garners no attention from those being refused
Like I wrote, it's punishing the peasants to teach the king a lesson. It's
unethical. If that's what these organizations choose to be, that's up to them,
nothing I can do except bring it to the public's attention.
> If I thought it would be welcomed in the community,
> I'd make all of the "BLOCKED" rules score significant negative
> (i.e. hammy) scores so people would fix their configs
I agree 100%. Make them all -5.0 so that any web host who offers SA but
doesn't pay its way learns quickly. Add in a message "Your web host is a
freeloader so this score is inaccurate" and you'd be close to divine
perfection. The point is, an explanation needs to be included for any
unexpected behavior.
What we have at the moment is a "roll the dice" situation where the spam scores
may or may not be accurate, users are unaware of this, and no one can know for
sure without extensive investigation.
> WE DO NOT WORK "TOGETHER" WITH DNSWL IN ANY WAY.
OK, let's change that to "Effectively work together, whether knowingly or not".
SpamAssassin queries the dnswl.org database, echoes their responses without
question, then massively adjusts spam scores based on their output regardless
of whether it's true or false.
> We don't set their policies or actively track changes.
Again, I find it extremely hard to believe that every single person involved
with SA was unaware that at least one major organization that they utilize is
deliberately poisoning results in order to receive payment.
> Changing defaults for such services is done on
> an as-noticed as-needed basis
If SpamAssassin has now noticed this problem, my work here is done.
> Devising conspiracy theories to explain filters not
> doing the job you expect them to do
I've presented the facts, easily accessible by anyone. Peddling conspiracy
theories? I think not.
You yourself pointed out:
- DNSWL are a commercial operation doing business as a .org
- You were unaware of their "make the customer pay by poisoning results" policy
- "it diverges from the widely used best practice for DNS-based lists"
- "we should not have their lists enabled by default"
- one list operator [DNSWL] is engaged in "hostile self-defense"
> Nothing in SA exists to punish SA users at any level
> or teach them any sort of lesson as a consequence
> of unwise behavior.
I was not referring to SA, I was referring to DNSWL. SA would be guilty only
if it was aware of this and did nothing. Again, I must say that I find it
EXTREMELY hard to believe that some nobody end user (myself) who is not an
expert in servers, Linux, Apache, email, spam, hosting, DNS (recursive or not),
whitelisting, or blacklisting, and knows absolutely nothing about the internals
of SA, would discover and highlight a problem such as this before any of the
many experts who presumably develop and operate SA daily. (Do I qualify for a
bug bounty?)
> If you believe otherwise, I urge you to not use SA.
> No one should use what they believe to be Fascist software.
Indeed, switching off SA is an easy option. But if you prefer to suggest we do
that rather than putting your house in order, that paints a rather sad picture
of the culture within SA, does it not?
> It is your moral obligation to pay for services that you
> rely upon according to the policies of the service provider.
> If your query volume is higher than a lists's limits on free use,
> you are ethically required to stop or to pay for it.
I agree 100%. I have just berated my web host and asked them what is going on;
they are taking longer than usual to respond. They need to either stop
offering SA to their users, or warn them of inaccuracy, or pay their dues.
And SpamAssassin users deserve full transparency from all involved.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #11 from Sidney Markowitz <si...@sidney.com> ---
I just noticed something that I want to add to this comment thread to correct
some misinformation:
According to the About page on dnswl.org it is not correct to characterize them
as a commercial organization out to make a profit on subscriptions.
"dnswl.org is an all-volunteer organisation. We are active in the anti-spam
community partially for personal interest and development, partially because we
have a day-job that involves some aspects of email security, spam prevention
and other professions."
I will give them the courtesy of reaching out in case they want to revise their
policy. Ultimately it is their decision how they deal with the tradeoff between
making their service available and dealing with overuse. For all I know they
may decide that the proper tradeoff is to have the rules in SpamAssassin be
disabled by default but available for manual configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Benny Pedersen <me...@junc.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |me@junc.eu
--- Comment #2 from Benny Pedersen <me...@junc.eu> ---
https://multirbl.valli.org/lookup/88.209.197.217.html follow this say me you
can reject it before content filter, why are you btw ignore "BLOCKED" ?
/etc/resolv.conf have in your server other then nameserver 127.0.0.1 why ?
dns must be resolved in same host as spamassassin runs on :)
IP address 88.209.197.217 is not whitelisted at dnswl.org.
your server ignorance is your problem to solve
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #18 from Sidney Markowitz <si...@sidney.com> ---
(In reply to Henrik Krohns from comment #17)
> Not sure if you can even score subrules.
From Mail::SpamAssassin::Conf POD
"Note that test names which begin with '__' are indirect rules used to compose
meta-match rules and can also act as prerequisites to other rules. They are not
scored or listed in the 'tests hit' reports, but assigning a score of 0 to an
indirect rule will disable it from running."
So you can't score them in the sense of the scores being actually evaluated,
but you can set them to 0 to disable. And by trying it I found that an explicit
non-zero score has the same effect you get from the default 1.0, that the rule
is enabled but the score is ignored. That becomes important if someone wants to
override the rule score being set to 0 in 50_scores.cf
>
> Isn't this whole thing made too complex? If something is not supposed to be
> in default ruleset and active, shouldn't it just be completely removed? No
> one is going to read 50_scores.cf comments anyway for instructions.
The issue I have is how to handle this using only rule updates so that it takes
effect without requiring a new release that people install. Do you think it
would be better to remove the rules/25_dnswl.cf and the DNSWL scores from
rules/50_scores.cf completely and just document how to add DNSWL rules? I guess
that's just about the same work for the sysadmin as enabling the rules when
they are listed with scores of 0, and that is a simpler change.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #21 from Benny Pedersen <me...@junc.eu> ---
# dns_block_rule RCVD_IN_VALIDITY_CERTIFIED_BLOCKED sa-trusted.bondedsender.org
dns_query_restriction deny sa-trusted.bondedsender.org
# dns_block_rule RCVD_IN_VALIDITY_SAFE_BLOCKED sa-accredit.habeas.com
dns_query_restriction deny sa-accredit.habeas.com
# dns_block_rule RCVD_IN_VALIDITY_RPBL_BLOCKED bl.score.senderscore.com
dns_query_restriction deny bl.score.senderscore.com
# dns_block_rule URIBL_ZEN_BLOCKED_OPENDNS zen.spamhaus.org
# dns_block_rule URIBL_ZEN_BLOCKED zen.spamhaus.org
# dns_block_rule SURBL_BLOCKED multi.surbl.org
dns_query_restriction deny multi.surbl.org
# dns_block_rule URIBL_BLOCKED multi.uribl.com
dns_query_restriction deny multi.uribl.com
# dns_block_rule RCVD_IN_DNSWL_BLOCKED list.dnswl.org
dns_query_restriction deny list.dnswl.org
dns_query_restriction deny dwl.dnswl.org
imho only way to disable them, setting score 0 does not always disable all :/
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #4 from Stefan <mu...@g0v.org> ---
(In reply to Benny Pedersen from comment #2)
> https://multirbl.valli.org/lookup/88.209.197.217.html follow this say me you
> can reject it before content filter, why are you btw ignore "BLOCKED" ?
>
> /etc/resolv.conf have in your server other then nameserver 127.0.0.1 why ?
>
> dns must be resolved in same host as spamassassin runs on :)
>
> IP address 88.209.197.217 is not whitelisted at dnswl.org.
>
> your server ignorance is your problem to solve
Wow, whoever you are, you respond in gibberish and try to make some kind of
"point", then suggest I am ignorant?
If you are one of the people in charge of SpamAssassin and fixing bugs, then no
wonder we are having these problems.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Henrik Krohns <ap...@hege.li> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |apache@hege.li
--- Comment #12 from Henrik Krohns <ap...@hege.li> ---
(In reply to Bill Cole from comment #9)
>
> # svn commit -m "Disable DNSWL rules as they had been doumented to have been"
> Authentication realm: <https://svn.apache.org:443> ASF Committers
> Password for 'billcole': ***************
>
> Sending 50_scores.cf
> Transmitting file data .done
> Committing transaction...
> Committed revision 1920862.
>
> The change will appear in the rules feed after the change gets through RuleQA
FYI while this might disable scoring, it still launches lookups as they are
done in the subrule:
header __RCVD_IN_DNSWL eval:check_rbl('dnswl-firsttrusted', 'list.dnswl.org.')
So now it's just using resources for nothing..
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
John Hardin <jh...@impsec.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jhardin@impsec.org
--- Comment #29 from John Hardin <jh...@impsec.org> ---
(In reply to Sidney Markowitz from comment #28)
> Deleting rules/25_dnswl.cf
There are a couple of meta rules that depend on __RCVD_IN_DNSWL that this
probably breaks, did you run a lint after making that change?
FSL_BULK_SIG
KHOP_HELO_FCRDNS
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #14 from Sidney Markowitz <si...@sidney.com> ---
What about changing __RCVD_IN_DNSWL to
meta __RCVD_IN_DNSWL (RCVD_IN_DNSWL_NONE || RCVD_IN_DNSWL_LOW ||
RCVD_IN_DNSWL_MED || RCVD_IN_DNSWL_HI)
I that enough to prevent the resource usage if all the RCVD_IN_DNSWL_* rules
are scored at 0?
(Also, as long as I am commenting again I'll point out that I was wrong about
the quota being monthly. According to https://www.dnswl.org/?page_id=110 the
limit really is 100,000 per 24 hour period as was written in the comment that
Bill changed to 10,000 monthly in the commit)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |billcole@apache.org
--- Comment #6 from Bill Cole <bi...@apache.org> ---
(In reply to Stefan from comment #5)
> I have wasted a several hours of my time because of this problem, and I want
> to share what I discovered.
>
> In response to Benny, it turns out there is nothing wrong with the set-up of
> SpamAssassin on my server and no one was being "ignorant".
Well, that's not exactly true.
No one should be running SA in a configuration that violates the policies of
the 3rd-party services that it supports. I don't believe that is explicitly
stated in any documentation, as it is a fundamental rule: it should not need
stating.
> It turns out that this is ENTIRELY INTENTIONAL BEHAVIOR by dnswl.org:
>
> https://www.dnswl.org/?p=120
>
> Summary: Those who haven't paid (or haven't paid enough) eventually start
> receiving "whitelisted" for ALL queries. In other words, false positives
> for ALL spammers.
The available solutions to dnswl.org providing you bogus information as a
direct consequence of your behavior all require you to behave differently. You
can either stop querying dnswl.org or treat them like any other commercial
service provider by paying their charges for your usage.
> Not only that, dnswl.org does not make this at all clear on the main pages
> of its website. This took a lot of digging. They also hide their pricing
> behind a log-in. These are not the behaviors of a reputable or ethical
> organization.
Yes, despite the .org domain they appear to be a commercial operation rather
than a charitable organization. You can expect any organization designed for
making money rather than to serve a charitable function to sometimes be less
kind than you would like.
> I fail to understand why SpamAssassin doesn't warn users about this, why it
> finds this type of behavior acceptable coming from one of its partner
> services, and why it places a very high negative spam score of -5.0 on these
> false positives.
You are overestimating the strength of the relationship between the
Spamassassin project and 3rd-party service providers.
Personally, I was unaware of that policy, as it diverges from the widely used
best practice for DNS-based lists: using distinct DNS results for policy
violations. Knowing that they are doing so, I agree that we should not have
their lists enabled by default. I will be raising this question with others in
the community and the PMC.
> At the very least, dnswl.org should simply be blocking non-paying users
> instead of returning false positives, so that SpamAssassin assigns a score
> of 0.0 instead of -5.0 (just like they do with the various blacklists that
> block queries).
That's NOT what the others do. All of the SA "BLOCKED" rules match on
policy-specific replies. As that dnswl.org page notes, refusing queries is not
useful because it garners no attention from those being refused and won't even
be really visible to the worst offenders, those who refuse to operate their own
recursive DNS resolvers and instead use free public resolvers.
If I thought it would be welcomed in the community, I'd make all of the
"BLOCKED" rules score significant negative (i.e. hammy) scores so people would
fix their configs…
> Instead, SpamAssassin and dnswl.org work together to 'punish' web hosting
WE DO NOT WORK "TOGETHER" WITH DNSWL IN ANY WAY.
The 3rd-party services referenced in SA use the same free public mechanisms
that can be used by anyone without SA. We don't set their policies or actively
track changes. Changing defaults for such services is done on an as-noticed
as-needed basis without considering the preferences of the operator of the
3rd-party service.
Devising conspiracy theories to explain filters not doing the job you expect
them to do is not productive. Spam filters make mistakes by their nature, and
it requires no one nefariously working together to make you sad. Really.
> companies by deliberately poisoning their customers' spam filters. Punish
> the peasants to teach the king a lesson.
Nothing in SA exists to punish SA users at any level or teach them any sort of
lesson as a consequence of unwise behavior.
If you believe otherwise, I urge you to not use SA. No one should use what they
believe to be Fascist software.
> My web hosting company's solution is: Set all dnswl.org-related scores to
> 0.0. At this point I can't argue about that; dnswl.org are making
> themselves irrelevant through their irresponsible behavior.
All mail servers acting as public MXs should be running their own local
recursive DNS resolver, rather than relying on any sort of "upstream" provider.
This is a widely recognized best practice for many reasons, not just the issue
of one list operator engaging in hostile self-defense.
Anyone using a free DNS-Based List (or other free service) as a part of their
commercial offerings needs to be aware that even with their own resolvers, they
are burdening the list operators and those who provide list secondaries with
their queries. It is your moral obligation to pay for services that you rely
upon according to the policies of the service provider. If your query volume is
higher than a lists's limits on free use, you are ethically required to stop or
to pay for it.
Setting ALL DNSWL rules to zero is one way to assure that you don't get bogus
results from them, because you won't query them. Other ways include (*in
addition* to the baseline of using your own recursive resolvers) staying below
their limit for free use or paying them for more usage.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #17 from Henrik Krohns <ap...@hege.li> ---
(In reply to Sidney Markowitz from comment #16)
> Created attachment 5966 [details]
> proposed patch with meta rules disabled too and more comments
>
> I'm attaching a patch instead of committing this because I don't usually
> touch anything that goes right into the rule updates.
>
> Could someone check this and commit it if it looks good?
>
> This adds a score 0 for the meta rule and updates the comment to more
> accurately reflect the status of dnwl.org, state the problem with false
> negatives that can occur if the admin enables the rules without proper
> configuration, and instructions on how to enable it.
Not sure if you can even score subrules.
Isn't this whole thing made too complex? If something is not supposed to be in
default ruleset and active, shouldn't it just be completely removed? No one is
going to read 50_scores.cf comments anyway for instructions.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #26 from Bill Cole <bi...@apache.org> ---
(In reply to Sidney Markowitz from comment #20)
> I'm convinced. I've updated the wiki to say that we no longer enable DNSWL
> by default. The wiki already stated that our policy is not to default enable
> any dnsbl that purposely returns wrong answers.
>
> I'll wait a bit to see if anyone jumps in with a reason to leave the rules
> in with score 0 instead deleting them, and if nobody does I'll go ahead and
> delete them.
+1
The only reason to leave them in the rules but scored at 0 would be if we were
concerned about people using local meta rules including one of the DNSWL rules.
I don't think that's a major issue. I'm not really sure if deletion or
zero-scoring would be the more helpful approach for that case.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #13 from Sidney Markowitz <si...@sidney.com> ---
(In reply to Henrik Krohns from comment #12)
> So now it's just using resources for nothing..
Is there a way to disable __RCVD_IN_DNSWL in rule updates that still allows it
to be enabled in a manual override? We of course can implement something for
the next release, but that is not nearly as good as handling it for everyone
immediately.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #16 from Sidney Markowitz <si...@sidney.com> ---
Created attachment 5966
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5966&action=edit
proposed patch with meta rules disabled too and more comments
I'm attaching a patch instead of committing this because I don't usually touch
anything that goes right into the rule updates.
Could someone check this and commit it if it looks good?
This adds a score 0 for the meta rule and updates the comment to more
accurately reflect the status of dnwl.org, state the problem with false
negatives that can occur if the admin enables the rules without proper
configuration, and instructions on how to enable it.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #24 from Sidney Markowitz <si...@sidney.com> ---
I didn't mean that dwl.dnswl.org doesn't exist, just that there are no rules
for it in the default SpamAssassin installation or in sa-update so you don't
need to disable it in a default setup.
If you are using dwl.dnswl.org it would be with rules that you have installed,
not any that come from us. Unless I somehow missed it when I looked for it.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #27 from Sidney Markowitz <si...@sidney.com> ---
After (over)thinking about it some more...
This is a major bug because it causes false negatives in some easily possible
use cases instead of warning messages without false results. What has been
committed so far stops the false negatives once sa-update is run, so the
immediate worst effects have been taken care of.
Reasons to delete the rules from rules/25_dnswl.cf and rules/5_scores.cf
* DNSWL now does not meet our explicit criteria of only supporting in the
default configuration mostly-free dnsbls that do not sent wrong results for
overuse. If we don't support them, we should not have their rules in the
default configuration.
* A site with improperly configured nameserver or high volume with no
subscription that has customized local scores for DNSWL rules but relies on the
rules being already defined will not continue to get false negatives.
Reasons to keep the rules in those files but score them at 0 to disable them
* A properly configured and if-needed paid up site that has customized local
scores for DNSWL rules but relies on the rules being already defined will
continue to work.
My conclusion is to choose the one that more avoids false negatives, which is
to delete the rules, and announce this on the users mailing list to try to
reach people who are properly configured and need to add the rules to their
local configuration.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #32 from Sidney Markowitz <si...@sidney.com> ---
I'm considering setting in a file for rule updates
dns_block_time 3600
instead of leaving it set to the default 300 seconds.
Reasons for:
* If a dnsbl does return a BLOCKED code, then it is the case that the dnsbl is
blocking the nameserver that SpamAssassin is using, and that is not likely to
change soon. Trying again 12 times in an hour is not likely to get different
results than trying again once an hour.
* However, trying more often increases the load on the dnsbl server from poorly
configured SpamAssassin installations, for example those relying on a public
access nameserver. This change will reduce the load caused by those
installations to 1/12 of what it is now.
* If the admin changes the configuration of their setup to fix the problem, it
only takes a restart of SpamAssassin to reset it if they don't want to wait an
hour.
Does anyone have any reason not to do this?
If we do this, what file is a good place to put it, given that it is not just
for dnswl, but affects all the dnsbls that have a *BLOCKED rule?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Stefan <mu...@g0v.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |muth@g0v.org
--- Comment #1 from Stefan <mu...@g0v.org> ---
I agree 100% with this. It seems that www.dnswl.org is either far too lax in
their whitelisting criteria, or they are somehow compromised. I receive emails
daily with SA headers like this:
Content analysis details: (3.0 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
[score: 1.0000]
0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
[score: 1.0000]
1.2 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
blocklist
[URIs: actionsnap.life]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.209.197.217 listed in sa-trusted.bondedsender.org]
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[88.209.197.217 listed in bl.score.senderscore.com]
-5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at https://www.dnswl.org/,
high trust
[88.209.197.217 listed in list.dnswl.org]
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: actionsnap.life]
1.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs
[URI: actionsnap.life (life)]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.1 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME
0.8 MPART_ALT_DIFF BODY: HTML and text parts are different
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
valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK
signature
0.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD
0.5 FROM_SUSPICIOUS_NTLD From abused NTLD
0.8 RDNS_NONE Delivered to internal network by a host with no
rDNS
X-Spam-Flag: NO
In this example, RCVD_IN_DNSWL_HI completely -- and wrongly -- overrides
everything else, turning a spam score of +8 into +3.
As per their instructions, I forward all such emails to my address
@@mail-in.verboten.net, but I never receive an acknowledgement and I have the
impression that no action is being taken.
In my opinion, SA needs to stop taking dnswl.org's whitelisting so seriously.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #28 from Sidney Markowitz <si...@sidney.com> ---
% svn ci -m "bug 8193 - Delete dnswl.org rules for sending wrong results for
overuse" rules/25_dnswl.cf rules/50_scores.cf
Deleting rules/25_dnswl.cf
Sending rules/50_scores.cf
Transmitting file data .done
Committing transaction...
Committed revision 1920886.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #19 from Henrik Krohns <ap...@hege.li> ---
(In reply to Sidney Markowitz from comment #18)
> The issue I have is how to handle this using only rule updates so that it
> takes effect without requiring a new release that people install. Do you
> think it would be better to remove the rules/25_dnswl.cf and the DNSWL
> scores from rules/50_scores.cf completely and just document how to add DNSWL
> rules? I guess that's just about the same work for the sysadmin as enabling
> the rules when they are listed with scores of 0, and that is a simpler
> change.
Too busy/disinterested to thoughtfully comment right now, but my 2 cents:
- If DNSWL is decided to be removed from SA rules, then only thing needed is to
remove it from rules, and maybe a courtesy announce to users list
- It's not SA problem to instruct on how to use third party lists. That third
party should provide instructions, as in this case does:
https://www.dnswl.org/?page_id=15#spamassassin (maybe needs some rewording)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Bill Cole <bi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Bill Cole <bi...@apache.org> ---
When I looked at the score configuration file, I found this comment:
# DNSWL is a commercial service that requires payment for servers over
100K queries daily.
# Unfortunately, they will return true answers for DNS servers they
consider abusive so
# SA Admins must enable these rules manually.
And yet the scores that followed were non-zero. So apparently there was an
intent to disable them by default that was not done properly. The limit has
also been reduced to 1/300th of its past value, deemed in 2011 to be low enough
to disable these by default.
In that context, it was absolutely reasonable to correct the mistake made in
2011 and REALLY disable them.
# svn commit -m "Disable DNSWL rules as they had been doumented to have been"
Authentication realm: <https://svn.apache.org:443> ASF Committers
Password for 'billcole': ***************
Sending 50_scores.cf
Transmitting file data .done
Committing transaction...
Committed revision 1920862.
The change will appear in the rules feed after the change gets through RuleQA
--
You are receiving this mail because:
You are the assignee for the bug.
Re: [Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by Matthias Leisi <ma...@leisi.net>.
Von meinem iPhone gesendet
> Am 24.09.2024 um 00:51 schrieb Michael Peddemors <mi...@linuxmagic.com>:
>
> And this should go for any list that defaults to 'list everything' to encourage signing up.. of course, all RBL checks should look for explicit return codes, not just a response.. before using the data result in any way.. whether SA or other tools.
The default „block“ action is the blocked response. However way over 90% of „overusers“ continue to query nevertheless, even after months or years.
— Matthias, for the dnswl.org project
Re: [Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by Michael Peddemors <mi...@linuxmagic.com>.
+1
And this should go for any list that defaults to 'list everything' to
encourage signing up.. of course, all RBL checks should look for
explicit return codes, not just a response.. before using the data
result in any way.. whether SA or other tools.
On 2024-09-23 13:51, bugzilla-daemon@spamassassin.apache.org wrote:
> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
>
> Sidney Markowitz <si...@sidney.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |sidney@sidney.com
>
> --- Comment #10 from Sidney Markowitz <si...@sidney.com> ---
> I did some testing of the DNSWL service and want to write a comment that
> summarizes the situation, even though Bill's conclusion is the same as mine:
>
> SpamAssassin has support for a number of dnsrbl services that are free to use
> with conditions, such as requiring payment for use over some monthly limit of
> number of queries.
>
> Each of these services implement some response to a query to indicate free use
> is not available, e.g., when the limit is exceeded for the month, and
> SpamAssassin has a 0.0 x_BLOCKED rule that makes the situation clear without
> affecting the score.
>
> In my experiments, I found that the DNSWL response to a query sent through a
> big use free public nameserver like 1.1.1.1 or 8.8.8.8, which apparently are
> blocked by them for overuse, is inconsistent: It varies between a SRVFAIL or
> BLOCKED response code (both of which fail the DNS query with no response, which
> triggers no rule in SpamAssassin), the expected 127.0.0.255 RBL_BLOCKED code,
> or a bogus 127.0.10.3 which is supposed to mean "special case server category,
> high non-spam". That last one is supposed to "encourage" whoever is doing that
> query to stop using DNSWL in high volume without a paid subscription by making
> much of their email have false negatives.
>
> I was able to confirm that the DNSWL list currently contains at least one
> actual entry in that 127.0.10.3 category. If SpamAssassin treated it as an
> alias for 127.0.0.255 it could produce false positives for any mail sent from
> those ip addresses. Besides, that would be an attempt to work around their
> explicit use policies, which we should not do.
>
> Bottom line is that the RCVD_IN_DNSWL_HI and DNSWL_BLOCKED rules do not
> reliably work (i.e., have a bug) when SpamAssassin is configured to use a
> nameserver that DNSWL.ORG has categorized as exceeding their
> free-use-without-paid-subscription limits.
>
> DNSWL.ORG would have to change their intentional policy for us to be able to
> make it work. Since the bug only exists in certain configurations, we can keep
> default-disabled DNSWL rules for people to manually enable when they know that
> their SpamAssassin configuration can use the rules, i.e. they have sufficiently
> low volume through their nameserver or a paid subscription. We can revisit the
> issue if they ever change their policy.
>
> As Bill pointed out, we intended to deal with this in 2011, and it was a bug
> that we did not do that correctly. That bug is now fixed in the rule updates.
>
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
Sidney Markowitz <si...@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sidney@sidney.com
--- Comment #10 from Sidney Markowitz <si...@sidney.com> ---
I did some testing of the DNSWL service and want to write a comment that
summarizes the situation, even though Bill's conclusion is the same as mine:
SpamAssassin has support for a number of dnsrbl services that are free to use
with conditions, such as requiring payment for use over some monthly limit of
number of queries.
Each of these services implement some response to a query to indicate free use
is not available, e.g., when the limit is exceeded for the month, and
SpamAssassin has a 0.0 x_BLOCKED rule that makes the situation clear without
affecting the score.
In my experiments, I found that the DNSWL response to a query sent through a
big use free public nameserver like 1.1.1.1 or 8.8.8.8, which apparently are
blocked by them for overuse, is inconsistent: It varies between a SRVFAIL or
BLOCKED response code (both of which fail the DNS query with no response, which
triggers no rule in SpamAssassin), the expected 127.0.0.255 RBL_BLOCKED code,
or a bogus 127.0.10.3 which is supposed to mean "special case server category,
high non-spam". That last one is supposed to "encourage" whoever is doing that
query to stop using DNSWL in high volume without a paid subscription by making
much of their email have false negatives.
I was able to confirm that the DNSWL list currently contains at least one
actual entry in that 127.0.10.3 category. If SpamAssassin treated it as an
alias for 127.0.0.255 it could produce false positives for any mail sent from
those ip addresses. Besides, that would be an attempt to work around their
explicit use policies, which we should not do.
Bottom line is that the RCVD_IN_DNSWL_HI and DNSWL_BLOCKED rules do not
reliably work (i.e., have a bug) when SpamAssassin is configured to use a
nameserver that DNSWL.ORG has categorized as exceeding their
free-use-without-paid-subscription limits.
DNSWL.ORG would have to change their intentional policy for us to be able to
make it work. Since the bug only exists in certain configurations, we can keep
default-disabled DNSWL rules for people to manually enable when they know that
their SpamAssassin configuration can use the rules, i.e. they have sufficiently
low volume through their nameserver or a paid subscription. We can revisit the
issue if they ever change their policy.
As Bill pointed out, we intended to deal with this in 2011, and it was a bug
that we did not do that correctly. That bug is now fixed in the rule updates.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #3 from Benny Pedersen <me...@junc.eu> ---
(In reply to Bernd Krumböck from comment #0)
> Hello!
>
> When I set up several mail gateways, I noticed that a high rate of the spams
> are delivered because of the Rule RCVD_IN_DNSWL_HI. The Bayes DB may even be
> poisoned.
> As long as the false positive rate of DNSWL.ORG is so high, the score of
> this rule should be changed (proposal: -0.1)!
> It currently acts as a gate for spammer.
>
> best regards
> Bernd
no sample, no problem, i cant say if you get false report on dns or not,
possible same mistake as stefan did here ?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #7 from Bill Cole <bi...@apache.org> ---
(In reply to Stefan from comment #4)
> (In reply to Benny Pedersen from comment #2)
[nothing helpful
> If you are one of the people in charge of SpamAssassin and fixing bugs, then
> no wonder we are having these problems.
Benny Pedersen is neither a committer nor PMC member of the Apache SpamAssassin
project. The most complete list of contributors is at
https://svn.apache.org/repos/asf/spamassassin/trunk/CREDITS.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #25 from Benny Pedersen <me...@junc.eu> ---
it removed in spamassassin, but data is still provided from dnswl, if i
remember is right it was a AskDNS rule
for the deny line i agre it should only be there is not wanted results from
this data
imho what will happen if all plugins is default disabled ?
all pre files is still in local files, so imho better to have opt in, not as it
is now opt out, and all the problems we did not know rule changes at random :/
default rules could simple deny, unless local rules are allow for the dns
querys
or dnsbl dnswl providers should know ttl rr with low ttl will query unneded to
see soa is still not changed, lol :)
while auth dns servers only need to know soa is in sync or not
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 8193] RCVD_IN_DNSWL_HI false positives
Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193
--- Comment #20 from Sidney Markowitz <si...@sidney.com> ---
I'm convinced. I've updated the wiki to say that we no longer enable DNSWL by
default. The wiki already stated that our policy is not to default enable any
dnsbl that purposely returns wrong answers.
I'll wait a bit to see if anyone jumps in with a reason to leave the rules in
with score 0 instead deleting them, and if nobody does I'll go ahead and delete
them.
I have contacted someone at dnswl.org about this. If they choose to persist in
their policy, I'll let them know how to update their instructions with more
reasonable scores and to include RCVD_IN_DNSWL_BLOCKED
--
You are receiving this mail because:
You are the assignee for the bug.