[SURBL-Discuss] RFC: consensus list?
jeffc at surbl.org
Sat Nov 13 23:19:33 CET 2004
On Saturday, November 13, 2004, 9:23:34 AM, Frank Ellermann wrote:
> Jeff Chan wrote:
> That's probably too KISS for you, and if you'd add the not
> yet used 7th multi bit it would result in 7 over 3 (any 3
> out of 7) combinations, 99 result codes if I got it right.
> (35 + 35 + 21 + 7 + 1 = 99, is that correct ?)
> Apparently SA already supports Ryan's idea, and then you
> don't need it. But if you have more complex rules to get
> an "optimal" proper subset of all multi result codes, then
> you could (ab)use bit 0 to mark it.
> Or in other words, any odd N in 127.0.0.N would be optimal.
> And 127.0.0.1 would be still protected (= never returned).
An interesting idea. IIRC you may have suggested it earlier,
but I didn't see the value at the time. However, see below.
>> without explicitly creating new, combined lists.
> Yes, that's unnecessary. Unless you have more than one
> definition of "optimal". Bit 0 can only handle one "rule",
> i.e. any combination of AND / OR / NOT multi bits you like.
Actually it may be necessary to create some new lists,
partly depending on whether the application can combine
individual lists by itself. SpamAssassin apparently can,
sort of. Others may not be able to. Simple MTA code may
not be able to.
And I just realized a major flaw in my suggestion to try
127.0.0.84 as a single list: Combinations of specific lists
like this are exclusive. If a list has exactly JP + OB + WS
like this, then it will NOT have any JP + OB + WS + SC, or any
JP + OB + WS + AB, etc. That kind of combination needs to be
done by creating a new list on the data side, or special
processing in the application.
So disregard my earlier request for testing these intersected
lists using those numbers in urirhsbl, etc. I will create some
temporary test lists in the second or third octet of multi to
test on corpora instead.
"If it appears in hams, then don't list it."
More information about the Discuss