On Wednesday, December 8, 2004, 8:15:28 AM, David Hooton wrote:

The floor in offering a DNS based whitelist is that it encourages people to place a negative score on it. The problem with this is that spammers can poison messages with whitelisted domains, thereby bypassing the power of the SURBL

Agreed, that's another possible misuse of whitelists if they existed in RBL form.

The concept of "Whitelist" in the SURBL world is more of an "Exclusion List" as in "we exclude these domains from being listed" rather than we consider the presence of these domains in an email to be a good sign of ham.

Which is how we use them throughout SURBLs. There is no whitening of messages due to whitelist inclusion, only non-checking of whitelisted domains.

That was a deliberate design decision IIRC. It seems to be revisited every so often, along with other design decisions, most of which I hope are mostly right. None of these decisions were made in a vacuum, we discussed most of them collaboratively and openly. Some of them were made when the project was just Eric Kolve and me, and some were later, but even two heads are better than one. :-)

An excluded domain is therefore ignored in all data and not allocated a score positively or negatively, so trying to poison a message with whitelisted domains is therefore pointless.

Yep.

I think we either need to look at a DNS version of uridnsbl_skip_domain with long TTL's or we should look at releasing a .cf file. I personally think the more proper implementation may be the DNS based version in order to avoid BigEvil type situations.

The the solution we came up for SA 3 with of a small, hard-coded exclusion list seems to fit the data well and be somewhat optimal in terms of performance.

An advantage of a separate local whitelist .cf might be for local programs to be able to output and maintain their own list, as Chris initially suggested. But I get back to the point that whitehats are pretty stable, and a hard coded list which anyone can edit or update locally in their existing 25_uribl.cf fits the data pretty well.

Jeff C.