[SURBL-Discuss] RFC: pj.surbl.org - list from Joe Wein and Pr olocation data

Jeff Chan jeffc at surbl.org
Sun Sep 19 10:18:43 CEST 2004


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.



More information about the Discuss mailing list