spamassassin-users December 2011 archive
Main Archive Page > Month Archives  > spamassassin-users archives
spamassassin-users: Re: DNS list inclusion policy (was Re: DNSWL

Re: DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

From: Kevin A. McGrail <KMcGrail_at_nospam>
Date: Tue Dec 13 2011 - 19:50:40 GMT
To: "David F. Skoll" <dfs@roaringpenguin.com>

On 12/13/2011 2:00 PM, David F. Skoll wrote:
> Hi,
>
> Is there a formal policy for including (or excluding) DNS-based lists
> from SpamAssassin's default rules? I think that SpamAssassin should
> not enable any DNS-based list by default unless the list owners have a
> clear policy that the list is free to use by SpamAssassin users,
> regardless of query volume [*], commercial vs. non-commercial use,
> etc. and a promise not to change the policy without reasonable (say,
> six months) notice.
>
> I realize this means practically no DNS lists will qualify to be
> enabled by default. I believe SA should ship all the rules for
> various DNS lists and have clear instructions (maybe even a tool for
> newbies that runs automatically from the makefile) to enable them.
> But I'm not sure it should serve as a marketing tool for DNSBL
> operators who want to charge money.
>
> (/me dons flame-proof suit...)
>
> Regards,
>
> David.
>
> [*] DNSBLs that force you to use a (free) rsync service if your query volume
> is too high are OK.
You are a brave person!

There is formal consensus from the PMC that work for most installations
is adequate for default inclusion once the merits of the BL are shown
combined with discussion if the infrastructure can withstand the query
onslaught.

Beyond that, we have the "new" issue of responding with purposefully
wrong answers which is a no-no for default inclusion. However, this
issue is NOT new. This issue was discussed by the PMC when URIBL was
being considered for inclusion:
"NOTE: URIBL fails with false positives once a threshold is exceeded.
  This will not be acceptable for a default enabled SA test." and the
response: UPDATE FROM DALLAS: We don't return positive to anymore. We
moved our heavy hitter blocking
to the top level, so blocked users will timeout trying to reach our
mirrors.".

But consensus for the PMC is clear, that free for some licensing with
query volumes being acceptable.

 From my notes, a daily limit and ok for non-commercial use has been
acceptable to SA to consider for default enabling. Of course, we've had
a LOT of discussions on this matter and Spamhaus, for example, changed
their query and SMTP limits based on discussions with SA.

So I know we try and be fair but flexible so we are not closed to new
BLs. I also personally try and support BLs by offering nameserver
resources.

In the end, your idea of an easier way for admins to review rules/BL for
inclusion/removal has good merit. I've had similar ideas with at least
making a list of rules that are disabled for these type of reasons more
in the forefront. The biggest con I can see is that rules and releases
are purposefully separated. If masscheck could be augmented, having
LOTS of different sa-update channels might be a good idea but that won't
enable the plugins.

Now what's more interesting is that I took on the crazy idea of writing
a policy for RBL inclusion. Let me formalize my notes and see if I can
post something today about that. It'll be really for the PMC to decide
but user/dev/rbl operator input is always good.

Regards,
KAM