spamassassin-users December 2011 archive
Main Archive Page > Month Archives  > spamassassin-users archives
spamassassin-users: Re: DNSWL will be disabled by default as of

Re: DNSWL will be disabled by default as of tomorrow

From: Dave Warren <lists_at_nospam>
Date: Tue Dec 13 2011 - 16:46:30 GMT
To: users@spamassassin.apache.org

On 12/13/2011 5:44 AM, Kevin A. McGrail wrote:
> On 12/13/2011 2:19 AM, Dave Warren wrote:
>> On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote:
>>> No. SA should be usable out-of-the-box with best possible performance
>>> for the majority of users.
>>
>> Perhaps a better long-term solution would be to validate DNS lists
>> before using them?
>>
>> One possible implementation would be to test to ensure that 127.0.0.1
>> is not listed, and 127.0.0.2 is listed (with the testing criteria
>> being configurable, but this is a starting point that will work for
>> most lists).
>>
>> If a list is down or unresponsive for any reason, discards requests
>> or blanks their zone file, the test entry would fail and SA would
>> know to not use the list. Similarly, 127.0.0.1 should never be listed
>> for any DNSBL that I'm aware of, and so when a list moves to a
>> list-the-world configuration, this entry would spot it.
>>
> Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
> checking real quick, I've got an RBL that uses 1 on a live server now.
>
> # Last octet of A record is a bitmask:
> # x & 1 => greylist
> # x & 2 => dirty
> # x & 4 => spammer
> # x & 8 => good
>
> IMO, unfortunately again there is no standard to RBL responses though
> I think that multi/combined lists could define an octet that is a
> blocked answer combine with a simple rule.

Sorry, I might not have been entirely clear. I'm suggesting we create a
SpamAssassin syntax to say "This IP must be listed" and "This IP must
not be listed", both of which must be true for a DNSBL to service. The
specific IPs selected are just for example purposes and can be tweaked
on a per-list basis based on the list's design.

Depending on how difficult this would be to implement within
SpamAssassin, you could write the test rule such that it supplies an IP
to be tested, a SA rule name and a required score (so that, for example,
you could test bit-based lists)

If I DNSBL operator cannot publish an IP that will always be listed and
an IP that will never be listed, they simply wouldn't be candidates for
implementation in SpamAssassin; since virtually all DNSBLs have some
sort of test IPs, this probably won't be a big deal.

The point is that I'm not suggesting we herd cats and require every
DNSBL to agree upon test addresses, but rather, that we go through on a
blocklist-by-blocklist basis and use their existing test addresses.

> If the RBL is using a combined bitwise solution, that's a solution
> that would work in the existing rule structure on multiple SA platforms.
>
> Hopefully, they can also give a high TTL on the blocked query answer
> so caching is more effective but at the end of the day, this still
> means querys are coming in. So what has the RBL operator gained?
> Blocking seems to be the only thing that really achieves the goal they
> want beyond conversion to paying customers which is not SA's issue.

This system would result in one query per BL per SA restart, or per
ruleset reload or per hour or whatever, rather than one or more queries
per processed message. That's a step forward to DNSBL operators, but
more importantly, it would avoid the situation where users are
negatively impacted by BL failures.

-- Dave Warren, CEO Hire A Hit Consulting Services http://ca.linkedin.com/in/davejwarren