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.
Jeff C. -- "If it appears in hams, then don't list it."