On Tue, 2011-12-13 at 13:52 +0100, Axb wrote: > On 2011-12-13 13:44, Kevin A. McGrail wrote: > >> 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. > At the risk of exposing my ignorance, I had a thought.
Since the entire 127/8 is reserved for loopback, nothing in the 127.0.0/24 block should be used as addresses. So, what is preventing RBLs and RWLs from using the third octet as a status indicator? It seems to me that the 4th octet can be used as at present as a query response which would by convention be a valid response if the 3rd octet is zero. OTOH if the 3rd octet was non-zero, this would indicate that the response is invalid, so this could provide an unambiguous way for the various RBLs and WLs to tell individual users to go away if they exceeded use limits, had an expired subscription, etc. This seems such an obvious solution that it must have been thought of in the past and rejected for some reason I don't understand. What did I miss? Martin > 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. >
