Just released SpamCopURI 0.20. Biggest change is support for multi.surbl.org. Let me know if you see anything strange. See the change notes below for what you need to do for your config.
0.20 Sat Jul 31 22:02:20 PDT 2004 - adding max url config param to limit number of URLs checked in an email. Usage (place into .cf file): spamcop_uri_limit 50 Default is unlimited.
- adding support for multi.surbl.org / bitmasked results. query results are cached on a per msg basis to prevent additional lookups.
Modify your configuration to look like the following for sc.surbl.org:
uri SPAMCOP_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/2') describe SPAMCOP_URI_RBL URI's domain appears in spamcop database at sc.surbl.org tflags SPAMCOP_URI_RBL net
ws.surbl.org would look like this:
uri WS_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/4') describe WS_URI_RBL URI's domain appears in ws database at ws.surbl.org tflags WS_URI_RBL net
- Removed configuration params: spamcop_uri_src and spamcop_uri_path since these should never be used anymore.
- added cleanup for hosts that come in with a dot in front of of the host (e.g. http://.spammy-site.org)
http://sourceforge.net/projects/spamcopuri/
--eric
Just wanted to mention you need to include scores with your configuration.
I accidentally omitted them from the example configuration in the changelog.
--eric
On Sat, Jul 31, 2004 at 10:49:03PM -0700, Eric Kolve wrote:
Just released SpamCopURI 0.20. Biggest change is support for multi.surbl.org. Let me know if you see anything strange. See the change notes below for what you need to do for your config.
0.20 Sat Jul 31 22:02:20 PDT 2004
adding max url config param to limit number of URLs checked in an email. Usage (place into .cf file): spamcop_uri_limit 50 Default is unlimited.
adding support for multi.surbl.org / bitmasked results. query results are cached on a per msg basis to prevent additional lookups.
Modify your configuration to look like the following for sc.surbl.org:
uri SPAMCOP_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/2') describe SPAMCOP_URI_RBL URI's domain appears in spamcop database at sc.surbl.org tflags SPAMCOP_URI_RBL net
ws.surbl.org would look like this:
uri WS_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/4') describe WS_URI_RBL URI's domain appears in ws database at ws.surbl.org tflags WS_URI_RBL net
Removed configuration params: spamcop_uri_src and spamcop_uri_path since these should never be used anymore.
added cleanup for hosts that come in with a dot in front of of the host (e.g. http://.spammy-site.org)
http://sourceforge.net/projects/spamcopuri/
--eric
Announce mailing list Announce@lists.surbl.org http://lists.surbl.org/mailman/listinfo/announce
On Saturday, July 31, 2004, 10:49:03 PM, Eric Kolve wrote:
Just released SpamCopURI 0.20. Biggest change is support for multi.surbl.org. Let me know if you see anything strange. See the change notes below for what you need to do for your config.
0.20 Sat Jul 31 22:02:20 PDT 2004
- adding max url config param to limit number of URLs checked in an email. Usage (place into .cf file): spamcop_uri_limit 50 Default is unlimited.
- adding support for multi.surbl.org / bitmasked results. query results are cached on a per msg basis to prevent additional lookups.
Modify your configuration to look like the following for sc.surbl.org:
uri SPAMCOP_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/2') describe SPAMCOP_URI_RBL URI's domain appears in spamcop database at sc.surbl.org tflags SPAMCOP_URI_RBL net
ws.surbl.org would look like this:
uri WS_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/4') describe WS_URI_RBL URI's domain appears in ws database at ws.surbl.org tflags WS_URI_RBL net
- Removed configuration params: spamcop_uri_src and spamcop_uri_path since these should never be used anymore.
- added cleanup for hosts that come in with a dot in front of of the host (e.g. http://.spammy-site.org)
--eric
Thanks Eric. A couple suggestions:
1. Please make a default limit to the number of URIs checked per message. urirhssub and urirhsbl have limits of 20 randomly chosen I believe. That may be too low, but I believe it's important to have some limit to cap DNS traffic to some reasonable level. IOW the parameter is a great idea, but we probably should set it. :-)
2. Network/Number looks like the syntax for CIDR notation; something like 127.0.0.0+2 might be less potentially confusing.
Jeff C.
On Sat, Jul 31, 2004 at 11:03:19PM -0700, Jeff Chan wrote:
On Saturday, July 31, 2004, 10:49:03 PM, Eric Kolve wrote:
Just released SpamCopURI 0.20. Biggest change is support for multi.surbl.org. Let me know if you see anything strange. See the change notes below for what you need to do for your config.
0.20 Sat Jul 31 22:02:20 PDT 2004
- adding max url config param to limit number of URLs checked in an email. Usage (place into .cf file): spamcop_uri_limit 50 Default is unlimited.
- adding support for multi.surbl.org / bitmasked results. query results are cached on a per msg basis to prevent additional lookups.
Modify your configuration to look like the following for sc.surbl.org:uri SPAMCOP_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/2') describe SPAMCOP_URI_RBL URI's domain appears in spamcop database at sc.surbl.org tflags SPAMCOP_URI_RBL netws.surbl.org would look like this:uri WS_URI_RBL eval:check_spamcop_uri_rbl('multi.surbl.org','127.0.0.0/4') describe WS_URI_RBL URI's domain appears in ws database at ws.surbl.org tflags WS_URI_RBL net
- Removed configuration params: spamcop_uri_src and spamcop_uri_path since these should never be used anymore.
- added cleanup for hosts that come in with a dot in front of of the host (e.g. http://.spammy-site.org)
--eric
Thanks Eric. A couple suggestions:
- Please make a default limit to the number of URIs checked per
message. urirhssub and urirhsbl have limits of 20 randomly chosen I believe. That may be too low, but I believe it's important to have some limit to cap DNS traffic to some reasonable level. IOW the parameter is a great idea, but we probably should set it. :-)
I agree, though I didn't really want to break the way it worked for existing users. I am fine with doing 20 random, though I would like to here from others on the list what they think it ought to be by default.
- Network/Number looks like the syntax for CIDR notation;
something like 127.0.0.0+2 might be less potentially confusing.
I was kind of worried it might cause confusion, but I figured I would just go with it... I like your syntax more and I will probably use that in the next release.
--eric
Jeff C.
Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
On Sunday, August 1, 2004, 12:06:42 AM, Eric Kolve wrote:
On Sat, Jul 31, 2004 at 11:03:19PM -0700, Jeff Chan wrote:
- Please make a default limit to the number of URIs checked per
message. urirhssub and urirhsbl have limits of 20 randomly chosen I believe. That may be too low, but I believe it's important to have some limit to cap DNS traffic to some reasonable level. IOW the parameter is a great idea, but we probably should set it. :-)
I agree, though I didn't really want to break the way it worked for existing users. I am fine with doing 20 random, though I would like to here from others on the list what they think it ought to be by default.
- Network/Number looks like the syntax for CIDR notation;
something like 127.0.0.0+2 might be less potentially confusing.
I was kind of worried it might cause confusion, but I figured I would just go with it... I like your syntax more and I will probably use that in the next release.
--eric
If I may, I'd like to suggest making the changes relatively quickly, since as we've found these things tend to take on a life of their own. Once people start doing things one way, it seems to be pretty hard to get them to change to a new way at times. :-)
In some ways it's kind of clean to copy the a similar 20 random setting that SA 3.0 is using by default, though I wouldn't mind hearing some comments from folks about this also. (I'm not convinced it's necessarily the best algorithm, just that it is one. ;-)
Jeff C.
Jeff Chan wrote:
In some ways it's kind of clean to copy the a similar 20 random setting that SA 3.0 is using by default [...]
I think a limit must be present to prevent DoS attacks on SURBL. This limit should have a built-in default setting (20 sounds reasonable to me), because many users will simply use the SpamCopURI defaults.
So, to protect SURBL from overload, I kindly and politely ask for Eric to make the changes as soon as time allows. Thank you!
I am fine with 20. Any other comments? If I here nothing else we will go with 20 random. I like that since it protects against the attack where a spammer could frontload an email with legit hidden links and present their link last.
--eric
On Sun, Aug 01, 2004 at 12:39:41PM +0200, Ralph Seichter wrote:
Jeff Chan wrote:
In some ways it's kind of clean to copy the a similar 20 random setting that SA 3.0 is using by default [...]
I think a limit must be present to prevent DoS attacks on SURBL. This limit should have a built-in default setting (20 sounds reasonable to me), because many users will simply use the SpamCopURI defaults.
So, to protect SURBL from overload, I kindly and politely ask for Eric to make the changes as soon as time allows. Thank you!
-- Mit freundlichen Grüßen / Yours sincerely Dipl. Inform. Ralph Seichter
HORUS-IT Ahornweg 10 D-57635 Oberirsen Tel +49 2686 987880 Fax +49 2686 987889 http://horus-it.de/
Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
On Sunday, August 1, 2004, 9:39:47 AM, Eric Kolve wrote:
I am fine with 20. Any other comments? If I here nothing else we will go with 20 random. I like that since it protects against the attack where a spammer could frontload an email with legit hidden links and present their link last.
I've already voted for 20 random :-) but I'd like to know if SpamCopURI is skipping empty (unclickable) anchors. IIRC we talked about this before, but I don't remember the outcome. A URI that's unclickable probably should not be checked. Not checking them also cuts down on some of the impact of the URI "chaffing" which means adding fake or distracting ones.
(Chaffing was a term I heard used Friday by Microsoft researcher Geoff Hulten at the CEAS conference; don't know if he coined it.)
Jeff C.
On Sun, 1 Aug 2004, Jeff Chan wrote:
I've already voted for 20 random :-) but I'd like to know if SpamCopURI is skipping empty (unclickable) anchors. IIRC we talked about this before, but I don't remember the outcome. A URI that's unclickable probably should not be checked. Not checking them also cuts down on some of the impact of the URI "chaffing" which means adding fake or distracting ones.
(Chaffing was a term I heard used Friday by Microsoft researcher Geoff Hulten at the CEAS conference; don't know if he coined it.)
Jeff C.
The term 'chaffing' predates Microsoft by almost half a century.
RADAR was effectivly invented during WW-II (1940-1945) as an important tool to detect enemy aircraft at night or in cloudy skys for aiming anti-aircraft guns. One of the counter-measures developed was for the aircraft to release bunches of aluminum foil streamers to create fake echos and fool the RADAR allowing the planes to evade the AA fire. The name for those foil streamers was 'chaff' so using them to evade detection was 'chaffing'.
On Sunday, August 1, 2004, 2:31:57 PM, David Funk wrote:
On Sun, 1 Aug 2004, Jeff Chan wrote:
(Chaffing was a term I heard used Friday by Microsoft researcher Geoff Hulten at the CEAS conference; don't know if he coined it.)
RADAR was effectivly invented during WW-II (1940-1945) as an important tool to detect enemy aircraft at night or in cloudy skys for aiming anti-aircraft guns. One of the counter-measures developed was for the aircraft to release bunches of aluminum foil streamers to create fake echos and fool the RADAR allowing the planes to evade the AA fire. The name for those foil streamers was 'chaff' so using them to evade detection was 'chaffing'.
Yes, I was aware of the anti-radar use, but hadn't heard the term applied to spam URIs before. :-) On the other hand I may not keep up with all the anti-spam literature.
Chaff in the radar context probably came from the stuff left over from grain harvesting after the grain is removed. Presumably the foil strips reminded of that extra stuff, which was often separated by throwing the crushed husks and grain kernels into a breeze. The kernels fall to back earth quickly and the husks float away in the wind. The empty gain husks are known as chaff and the foil strips floating in air probably were reminiscent of them. You guys in Iowa probably all use machines to separate your gain from chaff now, but in the old days it was done by tossing the stuff into the air. :-)
Jeff C.
Hi!
I am fine with 20. Any other comments? If I here nothing else we will go with 20 random. I like that since it protects against the attack where a spammer could frontload an email with legit hidden links and present their link last.
I've already voted for 20 random :-) but I'd like to know if SpamCopURI is skipping empty (unclickable) anchors. IIRC we talked about this before, but I don't remember the outcome.
Same for me, sounds ok. Anyone else? Speak up now :)
Bye, Raymond.
On Sun, 1 Aug 2004 23:48:46 +0200 (CEST), Raymond Dijkxhoorn raymond@prolocation.net wrote:
Hi!
I am fine with 20. Any other comments? If I here nothing else we will go with 20 random. I like that since it protects against the attack where a spammer could frontload an email with legit hidden links and present their link last.
I've already voted for 20 random :-) but I'd like to know if SpamCopURI is skipping empty (unclickable) anchors. IIRC we talked about this before, but I don't remember the outcome.
Same for me, sounds ok. Anyone else? Speak up now :)
I'm fine with 20, FWIW
I was just browsing at the differences between 0.19 and 0.20 and noticed this (in Conf.pm):
if (/^spamcop_uri_limit\s+(\d+)$/) { $self->{spamcop_uri_limit} = $1; next; }
wouldn't it be a little more foolproof to allow ending whitespace in the config file? or is this not customary?
Like:
if (/^spamcop_uri_limit\s+(\d+)\s*$/) { $self->{spamcop_uri_limit} = $1; next; }
Regards.
Eric... quick question...
if I'm using SpamCopURI with multi.surbl.org... and I have different checks configured (one for every sublist)... it will issue only one DNS query for a given domain, will it?
TIA
Correct. You should be able to check this by running spamassassin with debugging on.
You will see something that says a cached response is being returned for any subsequent queries for an identical domain.
--eric
On Mon, Aug 02, 2004 at 01:06:40PM -0300, Mariano Absatz wrote:
Eric... quick question...
if I'm using SpamCopURI with multi.surbl.org... and I have different checks configured (one for every sublist)... it will issue only one DNS query for a given domain, will it?
TIA
-- Mariano Absatz - El Baby el (dot) baby (AT) gmail (dot) com el (punto) baby (ARROBA:@) gmail (punto) com _______________________________________________ Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
I suppose, but this is consistent with the way they are parsing digits elsewhere in the conf, so I didn't want to do something that would break convention.
--eric
On Mon, Aug 02, 2004 at 12:54:08PM -0300, Mariano Absatz wrote:
I was just browsing at the differences between 0.19 and 0.20 and noticed this (in Conf.pm):
if (/^spamcop_uri_limit\s+(\d+)$/) { $self->{spamcop_uri_limit} = $1; next; }wouldn't it be a little more foolproof to allow ending whitespace in the config file? or is this not customary?
Like:
if (/^spamcop_uri_limit\s+(\d+)\s*$/) { $self->{spamcop_uri_limit} = $1; next; }Regards.
-- Mariano Absatz - El Baby el (dot) baby (AT) gmail (dot) com el (punto) baby (ARROBA:@) gmail (punto) com _______________________________________________ Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
Jeff Chan wrote:
If I may, I'd like to suggest making the changes relatively quickly, since as we've found these things tend to take on a life of their own. Once people start doing things one way, it seems to be pretty hard to get them to change to a new way at times. :-)
In some ways it's kind of clean to copy the a similar 20 random setting that SA 3.0 is using by default, though I wouldn't mind hearing some comments from folks about this also. (I'm not convinced it's necessarily the best algorithm, just that it is one. ;-)
Will this changes affect users running SpamCopUri v.0.20 in some way? Do we need to modify anything after Eric have made this modifications?
On Wednesday, August 4, 2004, 1:50:11 AM, Martin Martin wrote:
Jeff Chan wrote:
In some ways it's kind of clean to copy the a similar 20 random setting that SA 3.0 is using by default, though I wouldn't mind hearing some comments from folks about this also. (I'm not convinced it's necessarily the best algorithm, just that it is one. ;-)
Will this changes affect users running SpamCopUri v.0.20 in some way? Do we need to modify anything after Eric have made this modifications?
It depends on whether he makes his changes backwards compatible. I suppose he could support both notations:
127.0.0.0/2
and
127.0.0.0+2
to mean the same thing if he wanted to.
Setting a default limit on the maximum number of URIs checked should not cause any significant compatibility problems.
Certainly I'm encouraging a speedy update so everyone can use the new settings soon. :-)
Jeff C.
Eric Kolve wrote:
Just released SpamCopURI 0.20. Biggest change is support for multi.surbl.org. Let me know if you see anything strange. See the change notes below for what you need to do for your config.
0.20 Sat Jul 31 22:02:20 PDT 2004
adding max url config param to limit number of URLs checked in an email. Usage (place into .cf file): spamcop_uri_limit 50 Default is unlimited.
adding support for multi.surbl.org / bitmasked results. query results are cached on a per msg basis to prevent additional lookups.
Hi Eric,
Does this mean that i can use the multi.surbl.org with SpamCopURI 0.20 and SA 2.63. Or do i need to upgrade to SA 3.XX for this to work?
I'm using SC v.0.18 at this moment, is it possible to upgrade to v.0.20 via CPAN?
Thank you!
/ Martin
On Tuesday, August 3, 2004, 4:59:50 AM, Martin Martin wrote:
Does this mean that i can use the multi.surbl.org with SpamCopURI 0.20 and SA 2.63. Or do i need to upgrade to SA 3.XX for this to work?
SpamCopURI is for use with SpamAssassin 2.63.
I'm using SC v.0.18 at this moment, is it possible to upgrade to v.0.20 via CPAN?
Not sure if Eric has had a chance to update the CPAN distrubution.
Jeff C.
On Tue, Aug 03, 2004 at 05:41:19AM -0700, Jeff Chan wrote:
On Tuesday, August 3, 2004, 4:59:50 AM, Martin Martin wrote:
Does this mean that i can use the multi.surbl.org with SpamCopURI 0.20 and SA 2.63. Or do i need to upgrade to SA 3.XX for this to work?
Yes. You can use multi.surbl.org now.
SpamCopURI is for use with SpamAssassin 2.63.
I'm using SC v.0.18 at this moment, is it possible to upgrade to v.0.20 via CPAN?
Not sure if Eric has had a chance to update the CPAN distrubution.
CPAN has been updated. Though you will need to update your spamcop_uri.cf file.
--eric
Jeff C.
Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
I noticed in the new spamcop.cf file the new format or 127.0.0.0/2 /4 etc.
Just wondering if the old way works as well?
TIA,
-Doc (D-Ninja)
I noticed in the new spamcop.cf file the new format or 127.0.0.0/2 /4 etc.
Just wondering if the old way works as well?
The new format is for querying the multi list where the results are bitmapped. Using the other lists with their old values still works. But if you're querying multiple lists, changing to multi with the bitmap will be more efficient.
Bret ----------
Send your spam to: bretmiller@wcg.org Thanks for keeping the internet spam-free!
The "127.0.0.0/4" is only intended to be used for multi.surbl.org.
--eric
On Tue, Aug 03, 2004 at 11:44:27AM -0500, Doc Schneider wrote:
I noticed in the new spamcop.cf file the new format or 127.0.0.0/2 /4 etc.
Just wondering if the old way works as well?
TIA,
-Doc (D-Ninja) _______________________________________________ Discuss mailing list Discuss@lists.surbl.org http://lists.surbl.org/mailman/listinfo/discuss
Jeff Chan wrote:
On Tuesday, August 3, 2004, 4:59:50 AM, Martin Martin wrote:
Does this mean that i can use the multi.surbl.org with SpamCopURI 0.20 and SA 2.63. Or do i need to upgrade to SA 3.XX for this to work?
SpamCopURI is for use with SpamAssassin 2.63.
Ofcourse :). Should have thought of that!
Anyway, SC 0.20 is in place with the multilist and is working great!
What can i say! SURBL is the best! :)
Keep up the good work guys!
-
Bret Miller -
David B Funk -
Doc Schneider -
Eric Kolve -
Jeff Chan -
Mariano Absatz -
Martin -
Ralph Seichter -
Raymond Dijkxhoorn