All, this message tried to address most of the comments made regarding RulesDuJour so far.
On Sun, 2004-01-18 at 12:50, Martin Radford wrote: > At Sun Jan 18 16:06:13 2004, Charles Gregory wrote: > > > A thought, and a suggestion: > > > > Thought: Some of the rules in 'rules du jour' look like they are fairly > > 'stable'. There is no reason to be downloading 'backhair' or 'weeds' > > everyday, is there? Aah, I see I spelled "du jour" wrong, I changed the wiki pages and script name accordingly. > > Suggestion: For frequent changers, like 'evilrules', how about setting up > HTTP provides a straightforward way to avoid repeated downloads of a > file that hasn't changed, by sending If-Modified-Since requests. > > Unfortunately wget doesn't yet support this, though it is mentioned in > its TODO file. (This is with wget 1.9.1, which is the current > version.) While wget doesn't use If-Modified-Since, it *does* support conditional downloading of files using the -N switch. Instead of using If-Modified-Since, it sends an HTTP HEAD request, then reads the Last-Modified header and uses that to determine if it should download the file or not. edit: I just noticed Martin already explained this in a followup post. In regards to excessive bandwidth, I have made every effort to ensure files are not retrieved unless they have been updated (although with enough traffic, even bandwidth used by HEAD requests will add up). Bob's suggestion of adding a random delay, when run non-interactively should help cut down on bandwidth spikes at certain times of day. Regarding rulesets going away, I just added a bit of code that fires off an email to the administrator if a ruleset file goes missing (returns 404/4XX, domain not found, etc). Regarding how large the script is, my intention was to create a single script that managed all my rulesets automatically. I wanted it to be easily configurable by newbies, yet flexible enough to handle (for instance) editing the rules stream inline. There is also a lot of debug information so people can (hopefully) understand the logic. Finally, per some suggestions, I added --lint support. If spamassassin --lint fails, the rulesets are rolled back to their original configuration (before rules_du_jour was invoked). I also changed the default behavior when running interactively to output the debug information. I put the new version (1.04) up at: http://sandgnat.com/cmos/rules_du_jour If this doesn't address somebody's issue or suggestion, yell again -- additional comments welcome. -- Chris Thielen Easily generate SpamAssassin rules to catch obfuscated spam phrases: http://www.sandgnat.com/cmos/ ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
