Jeff Chan wrote:
(35 + 35 + 21 + 7 + 1 = 99, is that correct ?)
It is, 128 -1 -7 -( 6+5+4+3+2+1 ) = 99. Where -1 is "not no bit", -7 is "not only one bit", and the rest "not two bits".
Actually it may be necessary to create some new lists, partly depending on whether the application can combine individual lists by itself.
Yes, bit 0 could replace only one "new list", not several.
But as long as you can express the condition for the "new list" by a single boolean expression of the 7 multi bits, one bit is good enough. Excl. the special case "no bits", because that would result in 127.0.0.1.
And I just realized a major flaw in my suggestion to try 127.0.0.84 as a single list
84 = 64+16+4 (you said JP+OB+WS, I don't check it). Let's say that you want any combo where these 3 bits are set.
Then you have 3 fixed bits, and 4 free bits (at the moment only 3 free bits, but you may want to add the 7th bit later). 2 ** 4 = 16, you need 16 result codes to identify all combos with JP+OB+WS:
84,86, 92,94, 116,118, 124,126, (= 8 without the 7th bit, for the remaining 8 combos just add 128, from 212 to 254)
it will NOT have any JP + OB + WS + SC
That's 86 = 84 + 2.
That kind of combination needs to be done by creating a new list on the data side, or special processing in the application.
Or by adding bit 0 on your side for THE one "optimal rule": 85,87, 93,95, 117,119, 125,127 (= same 8, now bit 0 is set)
I will create some temporary test lists in the second or third octet of multi to test on corpora instead.
Yes, post a real complex boolean expression, it's fun stuff, SURBL would set a new standard (impressing ISIPP and OPM ;-)
But don't touch the zeros in 127.0.0.? without warning, it would break my poor http://purl.net/xyzzy/src/rxwhois.cmd :
| if SockGetHostByName( arg(1) || arg(2), 'P.' ) then do | if abbrev( P.ADDR, '127.0.0.' ) | abbrev( P.ADDR, '127.1.0.' ) | then say arg(3) '(' || substr( P.ADDR, 9 ) || '):' arg(2) | else say 'erroneous result' P.ADDR 'for' arg(1) || arg(2) | return 1 | end /* 127.1.0.1 .. 127.1.0.7 for .opm.blitzed.org(1+2+4) */ | return 0 Bye, Frank
On Saturday, November 13, 2004, 4:37:26 PM, Frank Ellermann wrote:
Jeff Chan wrote:
That kind of combination needs to be done by creating a new list on the data side, or special processing in the application.
Or by adding bit 0 on your side for THE one "optimal rule": 85,87, 93,95, 117,119, 125,127 (= same 8, now bit 0 is set)
But that's more than one list (i.e. more than one number...). We probably need a given combination to be a single list, for maximum compatibility.
But don't touch the zeros in 127.0.0.? without warning, it would break my poor http://purl.net/xyzzy/src/rxwhois.cmd :
| if SockGetHostByName( arg(1) || arg(2), 'P.' ) then do | if abbrev( P.ADDR, '127.0.0.' ) | abbrev( P.ADDR, '127.1.0.' ) | then say arg(3) '(' || substr( P.ADDR, 9 ) || '):' arg(2) | else say 'erroneous result' P.ADDR 'for' arg(1) || arg(2) | return 1 | end /* 127.1.0.1 .. 127.1.0.7 for .opm.blitzed.org(1+2+4) */ | return 0 Bye, Frank
I have a feeling changing the second and third octets could break several programs. But that's where the next lists need to go....
Jeff C. -- "If it appears in hams, then don't list it."
Jeff Chan wrote:
Or by adding bit 0 on your side for THE one "optimal rule": 85,87, 93,95, 117,119, 125,127 (= same 8, now bit 0 is set)
But that's more than one list (i.e. more than one number...). We probably need a given combination to be a single list, for maximum compatibility.
I don't have a tool to identify "odd IPs", I just see it <gd&r> If SA can't do this Apache would die from a roaring RIDICULUS.
You could of course create a new list *.combo.surbl.org, and (ab)use bit 0 in multi.surl.org as THE "combo bit". Same idea as for all other individual lists.
I have a feeling changing the second and third octets could break several programs.
It's not too bad with rxwhois, nobody uses it to delete mails, and actually it would be only a bogus error message if you do this. Breaking serious "multi" applications would be bad.
But that's where the next lists need to go....
You don't need "multi" for testing, you could use the future "combo" list for temporary test results 127.?.?.?. Bye, Frank
On Saturday, November 13, 2004, 6:02:34 PM, Frank Ellermann wrote:
You could of course create a new list *.combo.surbl.org, and (ab)use bit 0 in multi.surl.org as THE "combo bit". Same idea as for all other individual lists.
True. (FWIW it's the 1 bit, i.e. carrying values 0 and 1; a zero bit would carry no value.)
I have a feeling changing the second and third octets could break several programs.
It's not too bad with rxwhois, nobody uses it to delete mails, and actually it would be only a bogus error message if you do this. Breaking serious "multi" applications would be bad.
But that's where the next lists need to go....
You don't need "multi" for testing, you could use the future "combo" list for temporary test results 127.?.?.?. Bye, Frank
Setting up and tearing down separate test lists involves some overhead. And eventually multi will need to expand beyond the last octet.
Jeff C. -- "If it appears in hams, then don't list it."
Jeff Chan wrote:
FWIW it's the 1 bit, i.e. carrying values 0 and 1; a zero bit would carry no value.
That confusion was started by me in this thread, sorry. In real life bits are always counted from zero (least significant) to seven (most significant) in a byte:
Bit 0 = 2 ** 0 = 1 Bit 1 = 2 ** 1 = 2 (SC) [...] Bit 6 = 2 ** 6 = 64 (JP) Bit 7 = 2 ** 7 = 128.
Setting up and tearing down separate test lists involves some overhead. And eventually multi will need to expand beyond the last octet.
I'll believe it when I see it (the expansion of "multi" ;-)
Don't do strange things with stuff used in production, you don't want to cause erroneous mail deletions.
Bye, Frank
On Saturday, November 13, 2004, 7:45:51 PM, Frank Ellermann wrote:
Jeff Chan wrote:
Setting up and tearing down separate test lists involves some overhead. And eventually multi will need to expand beyond the last octet.
I'll believe it when I see it (the expansion of "multi" ;-)
Well in addition to the combined lists we have another 3 we could test or deploy:
1. DNS queries that match SBL 2. DNS queries that match XBL 3. trap data from Terry Sullivan, which is a bit faster than our other sources
Don't do strange things with stuff used in production, you don't want to cause erroneous mail deletions.
Eventually we will need more than 7 bits.
How does anyone feel about:
1. Propose a separate test list for trying new lists but that should not be used for production servers.
2. Ask application writers like SpamAssassin and others to check or modify their code to be able to handle bits in the other octets, i.e. 127.0.1.X, 127.64.X.X, etc. Should we let them know ahead of time that their code should be able to handle these cases without breaking?
Comments?
Jeff C. -- "If it appears in hams, then don't list it."
-
Frank Ellermann -
Jeff Chan