On Saturday, September 18, 2004, 11:27:05 PM, Frank Ellermann wrote:
Jeff Chan wrote:
We can have an infinite number of lists in multi
There are many ways to say "7 bits ought to be enough for everybody", but "infinite" is a bit exaggerated. ;-)
Or it's a new octal system, 0, 1, 2, 3, 4, 5, 6, 7, INF
Yes there is some cost: 1 bit and a few bytes of text. It's pretty minor though. And the number of lookups doesn't increase.
Remember that the PJ records are already in multi, as part of WS
That's cheating. If the WS bit is set I'd expect a WS entry, with the WS policy and whitelisting instructions.
Well one of the problems with WS is that it has multiple data sources in it, so it's hard to tell exactly where any given record came from.
Sure, at the moment there are no different whitelisting instructions for the MULTI sets, but that's not obvious. And sooner or later it will change.
Actually ws, ob, sc, ab, and ph all have different whitelisting instructions already, if the updates go back to the original source, which is preferrable. The whitelisting procedure is described on the lists page:
http://www.surbl.org/lists.html
I actually wanted the JW data to be separate in the beginning because it was a distinctly different and new data source with different a inclusion process, different spamtrap feeds, etc.
If it's really very different, then it's also good enough for its own MULTI bit. But a different set of spamtraps is no real difference. A different policy for inclusions, exclusions, or whitelisting is interesting.
Yes, it's different spam traps, and different policies for inclusion, etc.
FPs only hurt WS and make it less useful to people.
People expecting no FPs at all should try the empty list, works like a charm. Of course it won't identify any spam.
Bye, Frank
Well that's not really a reasonable alternative.
We should try to maximize spam detection and minimize FPs. Both functions need to be optimized simultaneously.
Jeff C.