I have just released SpamCopURI 0.13. This release adds some basic query caching as well as registrar based lookups against the RBL. Instead of querying for both the 2nd and 3rd level domain we are now only querying for the 2nd OR the 3rd based on the TLD. Let me know if you see any issues with this: false positives, misses that should be hits, etc.
We are now caching the query results on a per test basis so multiple URLs to the same to domain should only get checked once per RBL.
There is also a change that fixes a compile error under Perl 5.005 reported on this list.
Open redirect resolution is still off by default. I would like to hear how this has worked out for those that have enabled it. Do you think its safe enough to enabled it by default?
The latest release can be retrieved from http://sourceforge.net/projects/spamcopuri
--eric
Eric Kolve wrote:
Open redirect resolution is still off by default. I would like to hear how this has worked out for those that have enabled it. Do you think its safe enough to enabled it by default?
Works fine for me with 0.11.
David
Hi Eric,
I have just released SpamCopURI 0.13. This release adds some basic query caching as well as registrar based lookups against the RBL. Instead of querying for both the 2nd and 3rd level domain we are now only querying for the 2nd OR the 3rd based on the TLD. Let me know if you see any issues with this: false positives, misses that should be hits, etc.
Ok, great. Installed fine, testing...
We are now caching the query results on a per test basis so multiple URLs to the same to domain should only get checked once per RBL.
Would reduce the load on the nameservers also, people, please upgrade :)
There is also a change that fixes a compile error under Perl 5.005 reported on this list.
Open redirect resolution is still off by default. I would like to hear how this has worked out for those that have enabled it. Do you think its safe enough to enabled it by default?
I didn want to use that on my servers (yet), load is too high i think to start using that for me. Wesnesday 2M messages for example.
Bye, Raymond.
On Thursday, April 22, 2004, 5:50:18 PM, Raymond Dijkxhoorn wrote:
We are now caching the query results on a per test basis so multiple URLs to the same to domain should only get checked once per RBL.
Would reduce the load on the nameservers also, people, please upgrade :)
Indeed, the name servers are getting busier today. We need to look at ways to reduce this, and single queries per test is the best start.
I have some other ideas which I will bring up on the zones mailing list.
Jeff C.
Jeff Chan wrote:
Indeed, the name servers are getting busier today. We need to look at ways to reduce this, and single queries per test is the best start.
I should be able to get some information on the NS I use for surbl tomorrow. Since it's an NS for an ISP too, I can't distinguish what is surbl and what is everything else, but I can see what the traffic change was since I dropped surbl on it.
David
On Thursday, April 22, 2004, 6:54:05 PM, David Coulson wrote:
Jeff Chan wrote:
Indeed, the name servers are getting busier today. We need to look at ways to reduce this, and single queries per test is the best start.
I should be able to get some information on the NS I use for surbl tomorrow. Since it's an NS for an ISP too, I can't distinguish what is surbl and what is everything else, but I can see what the traffic change was since I dropped surbl on it.
Traffic on one of the name servers I have visibility on doubled from yesterday to today at about 40 vs 80k bits per second. Still low overall, but the jump is noticeable.
We need to plan for scaling, for example when SA 3.0 comes out and has built in support for SURBLs.
Jeff C.
Hi!
I should be able to get some information on the NS I use for surbl tomorrow. Since it's an NS for an ISP too, I can't distinguish what is surbl and what is everything else, but I can see what the traffic change was since I dropped surbl on it.
Traffic on one of the name servers I have visibility on doubled from yesterday to today at about 40 vs 80k bits per second. Still low overall, but the jump is noticeable.
We need to plan for scaling, for example when SA 3.0 comes out and has built in support for SURBLs.
We also keep offloading by opening up rsync stuff, so some load will move out but most likelly natural grow will also pick up, especially when SA3 gets final. Luckily we still get public DNS servers also, today we hooked up zonnet.nl (Thanks!)
Bye, Raymond.
I have just released SpamCopURI 0.13. This release adds some basic query caching as well as registrar based lookups against the RBL. Instead of querying for both the 2nd and 3rd level domain we are now only querying for the 2nd OR the 3rd based on the TLD. Let me know if you see any issues with this: false positives, misses that should be hits, etc.
Wow the releases are flowing thick and fast now :-)
Guess it shows how surbl is really taking off...
We are now caching the query results on a per test basis so multiple URLs to the same to domain should only get checked once per RBL.
There is also a change that fixes a compile error under Perl 5.005 reported on this list.
Open redirect resolution is still off by default. I would like to hear how this has worked out for those that have enabled it. Do you think its safe enough to enabled it by default?
Well I turned it straight on, and so far its worked fine, I've manually verified my last days worth of spam (sigh, kind of depressing wading through your spam, but oh well :) and all the non-redirect spam url's were picked up correctly as well as the redirected ones...(although, I've only seen yahoo redirect spams so far, none of the others in your list)
I am curious what the third field for open_redirect_list_spamcop_uri is though, perhaps you could document the fields briefly so we have a better idea of how the parsing is handled and how to add custom entries if needed.
(If there was any documentation of this, I must have missed it, and I suppose you don't want to go into TOO much detail for the spammers who may be reading this list ;)
Great work...
Regards, Simon