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
