https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8193

Sidney Markowitz <sid...@sidney.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sid...@sidney.com

--- Comment #10 from Sidney Markowitz <sid...@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.

Reply via email to