You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Cirelle Enterprises <gc...@cirelle.com> on 2004/07/14 18:07:22 UTC
Re: Rules Download question
Chris,
Why aren't you running rsync for the rules.
That would cut down on bandwidth because if the rule
didn't change, no download and is much better than the wget
The current scheme actually kills off the .cf files like it did ours
as it got messed up from the download today.
we were able to restore from a backup, but your system is broken
in it's current state
Regards
Greg
----- Original Message -----
From: "Chris Santerre" <cs...@MerchantsOverseas.com>
To: "'Nichols, William'" <bn...@ci.redding.ca.us>; <sp...@incubator.apache.org>
Sent: Wednesday, July 14, 2004 11:39 AM
Subject: RE: SURBL question
| I would simply remove the old cf files and create a new one. This way if you
| run RDJ it doesn't get confused.
|
| -----Original Message-----
| From: Nichols, William [mailto:bnichols@ci.redding.ca.us]
| Sent: Wednesday, July 14, 2004 11:35 AM
| To: spamassassin-users@incubator.apache.org
| Subject: RE: SURBL question
|
|
|
| Chris,
|
|
|
| So if I installed spamcop_uri through cpan and then copied the .cf file over
| that is all I need?
|
|
|
| Thanks,
|
|
|
| Bill
|
|
|
|
| _____
|
|
| From: Chris Santerre [mailto:csanterre@MerchantsOverseas.com]
| Sent: Wednesday, July 14, 2004 8:35 AM
| To: Nichols, William; spamassassin-users@incubator.apache.org
| Subject: RE: SURBL question
|
|
|
| It does replace them all.
|
|
|
| www.surbl.org <http://www.surbl.org> has everything a young man needs to
| know about love, life, and SURBL :)
|
|
|
| --Chris (Jeff made me say it!)
|
| -----Original Message-----
| From: Nichols, William [mailto:bnichols@ci.redding.ca.us]
| Sent: Wednesday, July 14, 2004 11:22 AM
| To: spamassassin-users@incubator.apache.org
| Subject: SURBL question
|
| Ok - reading on here I think I have it - just want to make sure.
|
|
|
| When people are referring to SURBL is this spamcop_uri?
|
|
|
| Does this replace blacklist.cf, blacklist-uri.cf and bigevil (don't think
| so, want to make sure)
|
|
|
| If it doesn't replace them, what does?
|
|
|
| Thanks,
|
|
|
| Bill
|
|
Re: Rules Download question
Posted by Ryan Thompson <sp...@sasknow.com>.
Cirelle Enterprises wrote to Ryan Thompson:
> ----- Original Message -----
> From: "Ryan Thompson" <sp...@sasknow.com>
>
> | I'm 99% sure wget doesn't support that, or 304 replies (probably since
> | it has no real concept of the local filesystem :-), but it'd be pretty
> | trivial to implement with other tools/libraries not nearly as bulky as
> | rsync.
>
> whatever
>
> but the most recent changes makes the files look new everytime and
> downloads them all with a restart of SA
Yes, we know the system is broken. :-)
> and why does SA have to restart every time since (in reality) no
> changes have occurred.
Even with the current system (when it works), SA only restarts if at
least one ruleset changed. At least, that's how it's supposed to work.
> My point is why go through the complete download if you don't have to
Exactly. You suggested rsync. I suggested If-Modified-Since.
> What about FTP, that has to be more efficient than http
Nope, especially if we take advantage of HTTP's If-Modified-Since.
> God forbid if you change the download schedule and it is 22 hours and not
> 24 hours, all your cf files look like:
>
> <H1>Rate limiting in effect</H1>
> [ ... ]
> What's up with that?
Chris has acknowledged the problem (more than once in response to *you*
on-list today). Yesterday's rulesets will still work today. I'm
absolutely confident he intends to fix it. ;-)
- Ryan
--
Ryan Thompson <ry...@sasknow.com>
SaskNow Technologies - http://www.sasknow.com
901-1st Avenue North - Saskatoon, SK - S7K 1Y4
Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Rules Download question
Posted by Cirelle Enterprises <gc...@cirelle.com>.
----- Original Message -----
From: "Ryan Thompson" <sp...@sasknow.com>
| I'm 99% sure wget doesn't support that, or 304 replies (probably since
| it has no real concept of the local filesystem :-), but it'd be pretty
| trivial to implement with other tools/libraries not nearly as bulky as
| rsync.
whatever
but the most recent changes makes the files look new everytime
and downloads them all with a restart of SA
http://www.rulesemporium.com/rules/70_sare_bayes_poison_nxm.cf
http://www.rulesemporium.com/rules/70_sare_oem.cf
http://www.rulesemporium.com/rules/70_sare_random.cf
http://www.rulesemporium.com/rules/70_sare_spoof.cf
http://www.rulesemporium.com/rules/70_sare_genlsubj0.cf
http://www.rulesemporium.com/rules/70_sare_genlsubj1.cf
http://www.rulesemporium.com/rules/70_sare_genlsubj2.cf
http://www.rulesemporium.com/rules/70_sare_genlsubj3.cf
http://www.rulesemporium.com/rules/70_sare_specific.cf
http://www.rulesemporium.com/rules/71_sare_redirect_pre3.0.0.cf
http://www.rulesemporium.com/rules/72_sare_bml_post25x.cf
http://www.rulesemporium.com/rules/evilnumbers.cf
http://www.rulesemporium.com/rules/coding_html.cf
http://www.rulesemporium.com/rules/header_abuse.cf
http://www.rulesemporium.com/rules/99_sare_adult.cf
http://www.rulesemporium.com/rules/99_sare_biz_market_learn_post25x.cf
http://www.rulesemporium.com/rules/99_sare_fraud_post25x.cf
http://www.rulesemporium.com/rules/bogus-virus-warnings.cf
http://www.rulesemporium.com/rules/99_FVGT_Tripwire.cf
http://www.rulesemporium.com/rules/weeds_2.cf
http://www.rulesemporium.com/rules/88_FVGT_Bayes_Poison.cf
http://www.rulesemporium.com/rules/88_FVGT_body.cf
http://www.rulesemporium.com/rules/88_FVGT_rawbody.cf
http://www.rulesemporium.com/rules/88_FVGT_subject.cf
http://www.rulesemporium.com/rules/88_FVGT_headers.cf
http://www.rulesemporium.com/rules/88_FVGT_uri.cf
My point is why go through the complete download if you don't have to
and why does SA have to restart every time since (in reality) no changes
have occurred.
God forbid if you change the download schedule and it is 22 hours and not
24 hours, all your cf files look like:
<H1>Rate limiting in effect</H1>
Your request could not be processed because you have exceeded the maximum request rate for the requested document. This is a temporary condition; you will be permitted to submit another request in a few hours.
<BR><BR>To avoid triggering the rate limiter in future, please make less frequent requests for this document. You should not request the same document more than once every 24 hours. Please also note that continuing to re-request the document while rate limiting is in effect will further increase the amount of time before the file becomes available to you again.
What's up with that?
What about FTP, that has to be more efficient than http
Regards
Greg
----- Original Message -----
From: "Ryan Thompson" <sp...@sasknow.com>
To: "Cirelle Enterprises" <gc...@cirelle.com>
Cc: "Chris Santerre" <cs...@MerchantsOverseas.com>; <sp...@incubator.apache.org>
Sent: Wednesday, July 14, 2004 12:35 PM
Subject: Re: Rules Download question
| Cirelle Enterprises wrote to Chris Santerre:
|
| > Chris,
| >
| > Why aren't you running rsync for the rules.
| >
| > That would cut down on bandwidth because if the rule
| > didn't change, no download and is much better than the wget
|
| HTTP would do a good job of this itself, if RDJ took advantage of the
| If-Modified-Since request-header field, significant bandwidth could be
| saved.
|
| I'm 99% sure wget doesn't support that, or 304 replies (probably since
| it has no real concept of the local filesystem :-), but it'd be pretty
| trivial to implement with other tools/libraries not nearly as bulky as
| rsync.
|
| rsync is better for large hierarchies of many files. Using it to update
| a dozen or so files would be overkill, IMO. rsync is also quite resource
| intensive on server and client side.
|
| Chris, if you want, I can look at reworking RDJ to take advantage of
| If-Modified-Since, as long as it is (relatively) safe to assume that the
| modified dates change IFF there are new versions of each ruleset.
|
| All of the PARSE_NEW_VER_SCRIPTS stuff could still be preserved, I
| suppose.
|
| - Ryan
|
| --
| Ryan Thompson <ry...@sasknow.com>
|
| SaskNow Technologies - http://www.sasknow.com
| 901-1st Avenue North - Saskatoon, SK - S7K 1Y4
|
| Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon
| Toll-Free: 877-727-5669 (877-SASKNOW) North America
Re: Rules Download question
Posted by Ryan Thompson <sp...@sasknow.com>.
Cirelle Enterprises wrote to Chris Santerre:
> Chris,
>
> Why aren't you running rsync for the rules.
>
> That would cut down on bandwidth because if the rule
> didn't change, no download and is much better than the wget
HTTP would do a good job of this itself, if RDJ took advantage of the
If-Modified-Since request-header field, significant bandwidth could be
saved.
I'm 99% sure wget doesn't support that, or 304 replies (probably since
it has no real concept of the local filesystem :-), but it'd be pretty
trivial to implement with other tools/libraries not nearly as bulky as
rsync.
rsync is better for large hierarchies of many files. Using it to update
a dozen or so files would be overkill, IMO. rsync is also quite resource
intensive on server and client side.
Chris, if you want, I can look at reworking RDJ to take advantage of
If-Modified-Since, as long as it is (relatively) safe to assume that the
modified dates change IFF there are new versions of each ruleset.
All of the PARSE_NEW_VER_SCRIPTS stuff could still be preserved, I
suppose.
- Ryan
--
Ryan Thompson <ry...@sasknow.com>
SaskNow Technologies - http://www.sasknow.com
901-1st Avenue North - Saskatoon, SK - S7K 1Y4
Tel: 306-664-3600 Fax: 306-244-7037 Saskatoon
Toll-Free: 877-727-5669 (877-SASKNOW) North America