On Sunday, January 30, 2005, 4:34:07 AM, Raymond Dijkxhoorn wrote:

[When SA 3.1?]

...

...

Real soon now.

...

OK, let's ask Raymond and Joe to remove the JP data from WS before your final pre-3.1 mass check. Should we do that now?

...

...

...

One of the things we planned for it was to move JP data out of WS on the SURBL lists.

...

...

So, WS includes all of JP? Or, are JP entries individually considered and added manually over time to WS? Or, is the problem something else?

Please let us know what we should do, cutting out we should announce, the actual removal is just altering one export script...

I've created a bugzilla 4114 to request a separate JP rule in the default config for 3.1. When that is added we should remove the JP data from WS.

SA devs please give us a heads up when the JP rule is added and that will trigger our changes on the SURBL data side.

Cheers,

Jeff C.

Thanks, I closed the ticket for the JP rule.

BTW Any ideas when the last mass check for 3.1 might happen?

We'd want to take the JP data out of WS before then.

Jeff C.

Hi!

When this change occurs will the jp data be available as a separate list like jp.surbl.org or will it only be included in the multi?

It will only be available in multi, why ?

Bye, Raymond.

Hi!

Unfortuantly right now Declude does not support bitmasking so we end up having to do a bunch of workarounds when using the multi list.

Its not like this should come as a surprise, this 'change' was talked over before SA3 hit the streets and was also ment to be moved into 3.1 like we are now talking over. Wonder why this wasnt picked up earlier by the Declude people.

Are those workarounds hard or will it mean people with Declude have to stop using JP datasets... ?

Bye, Raymond.

On Sunday, January 30, 2005, 9:17:20 AM, Darrell (support@invariantsystems.com) wrote:

Jeff,

When this change occurs will the jp data be available as a separate list like jp.surbl.org or will it only be included in the multi?

Darrell

We are very likely not making any more separate lists, and jp will not be a separate list. Therefore all SURBL applications should be written to use bitmasking.

Jeff C. -- "If it appears in hams, then don't list it."

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Daniel Quinlan writes:

Raymond Dijkxhoorn raymond@prolocation.net writes:

...

Please let us know what we should do, cutting out we should announce, the actual removal is just altering one export script...

Considering that SA hasn't shipped with JP yet and that those hosts are already caught in WS (which predates JP), I'd announce that you're making the change in a week and then make the change.

btw, I think requiring people to upgrade ASAP isn't necessarily a great idea; we can avoid it by setting up a new BL for "WS minus JP". then 3.1.0 can look up

- JP - WS_minus_JP

and existing clients can look up

- WS (which includes JP as before)

and upgrade at their leisure...

- --j.

On Sunday, January 30, 2005, 5:14:38 PM, Raymond Dijkxhoorn wrote:

Hi!

...

...

Considering that SA hasn't shipped with JP yet and that those hosts are already caught in WS (which predates JP), I'd announce that you're making the change in a week and then make the change.

...

btw, I think requiring people to upgrade ASAP isn't necessarily a great idea; we can avoid it by setting up a new BL for "WS minus JP". then 3.1.0 can look up

• JP
• WS_minus_JP

and existing clients can look up

• WS (which includes JP as before)

and upgrade at their leisure...

What about:

The seperate zonefile will contain both (WS+JP)

The multi list, since those seem to can use multi anyway, has the seperated sources.

Bye, Raymond.

I'm opposed to creating new lists like this.

Besides, if we're going to ask people to add rules to their 3.0.x, we can just ask them to add:

urirhssub URIBL_JP_SURBL multi.surbl.org. A 64 body URIBL_JP_SURBL eval:check_uridnsbl('URIBL_JP_SURBL') describe URIBL_JP_SURBL Has URI in JP at http://www.surbl.org/lists.html tflags URIBL_JP_SURBL net

score URIBL_JP_SURBL 4.0

Right? ;-)

Jeff C.

On Sunday, January 30, 2005, 7:28:42 PM, Jeff Chan wrote:

OK I propose that we announce that the JP data will come out of WS say 7 January and ask anyone lacking a separate JP rule to add one. Example 3.0.x and 2.63/4 rules are on the SURBL Quick Start.

How does this sound to everyone?

OK Raymond says he's ok with removing JP from WS and letting people know they should add a JP rule or upgrade to SA 3.1.

How does everyone else feel about it?

Jeff C. -- "If it appears in hams, then don't list it."

In message 1636720158.20050130192842@surbl.org, Jeff Chan writes:

OK I propose that we announce that the JP data will come out of WS say 7 January and ask anyone lacking a separate JP rule to add one. Example 3.0.x and 2.63/4 rules are on the SURBL Quick Start.

How does this sound to everyone?

Quit hogging that time machine, I want a go too!

Kidding aside, I assume you mean either February or March?

//Christer

Hi!

...

What about:

...

The seperate zonefile will contain both (WS+JP)

...

The multi list, since those seem to can use multi anyway, has the seperated sources.

I'm opposed to creating new lists like this.

Besides, if we're going to ask people to add rules to their 3.0.x, we can just ask them to add:

urirhssub URIBL_JP_SURBL multi.surbl.org. A 64 body URIBL_JP_SURBL eval:check_uridnsbl('URIBL_JP_SURBL') describe URIBL_JP_SURBL Has URI in JP at http://www.surbl.org/lists.html tflags URIBL_JP_SURBL net

score URIBL_JP_SURBL 4.0

Thats how i am allready running JP since 3.x... so yes.

Bye, Raymond.

Justin Mason jm@jmason.org writes:

btw, I think requiring people to upgrade ASAP isn't necessarily a great idea; we can avoid it by setting up a new BL for "WS minus JP". then 3.1.0 can look up

Gah!!! I think you might be confused about this. There's no issue as far as I can tell. JP is the new blacklist and it includes WS, the old blacklist. The new blacklist should never have included WS (#include-style, incidental overlap is okay, of course).

No longer importing WS into JP has no negative effect on any of these users:

- people with pre-JP versions: don't have JP anyway - people with pre-JP versions who added JP on their own: will still have both JP and WS - people running SVN HEAD or anything else that included JP already: will still have WS!

No new blacklist needed.

Warning is merely a courtesy for any oddballs who are only using JP.

Daniel

On Sunday, January 30, 2005, 8:03:37 PM, Daniel Quinlan wrote:

Oh crap. It's *me* that's confused and I'm sure I'll get 5 replies from people who don't read all their mail before sending replies telling me that. Anyway, disregard my last message.

Adding JP to WS was clearly a horrible idea to begin with. However, wasting a bit on this is silly (and I think that's what I'm reacting to here), especially considering that Henry and I have been discussing a revamp of the SURBL rules where source would not matter and the number of bits set would matter -- we'd have to special case this.

Not to worry, I had to remove my foot from my mouth before I could speak too. ;-)

I think we have all the cases covered. After we remove JP from WS, anyone lacking a separate JP rule and not upgrading to 3.1 can simply add a JP rule, as we've advised from the beginning of JP. It's just that such a change did not get into the 3.0 release.

Jeff C.