|Main Archive Page > Month Archives > spamassassin-users archives|
On 2011-12-13 13:44, 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.
well, that BL would have to change - no big deal (we know who that is :)
> # 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.
> Then they just need to be publishing a combined list to do that and not
> use the other octets (i.e. return the bitwise for blocked only or at
> least no purposefully incorrect answers). The score on the rule that
> acknowledges a block should be minimal and the message on the rule would
> have to link to a generic page on SA's wiki regarding "free for some"
> services. It should NOT lead to a subscription page for a vendor. We are
> not an advertising service.
> 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.
been talking to SF about possibilities.... he has some interesting ideas
(I'm not 100% sold on them, but he makes sense) - stay tuned.