Re: SARE and RulesDuJour still relevant
On Fri, 14 Jan 2011 11:04:49 -1000, Warren Togami Jr. wtog...@gmail.com wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. On 14.01.11 23:19, Benny Pedersen wrote: meta SPF_NICE_PASS (SPF_HELO_PASS SPF_PASS) I don't see any benefit of this rule, do you? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool.
Re: SARE and RulesDuJour still relevant
On Mon, 17 Jan 2011 11:43:16 +0100, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 14.01.11 23:19, Benny Pedersen wrote: meta SPF_NICE_PASS (SPF_HELO_PASS SPF_PASS) I don't see any benefit of this rule, do you? it only hits ham here, never spam, so wanted to know if that same in public corpus, in my own testing its usefull with ham since most spammers can get SPF_PASS and not much spam have SPF_HELO_PASS at the same time
Re: SARE and RulesDuJour still relevant
On 15/01/11 00:19, Warren Togami Jr. wrote: On 01/14/2011 01:09 PM, Ned Slider wrote: On 14/01/11 21:04, Warren Togami Jr. wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. Warren header NSL_RCVD_HELO_USER Received =~ /helo[= ]user\)/i describe NSL_RCVD_HELO_USER Received from HELO User Might want to combine into a meta rule with existing NSL_RCVD_FROM_USER rule: header NSL_RCVD_FROM_USER Received =~ /from User [\[\(]/ describe NSL_RCVD_FROM_USER Received from User The above are particularly effective (here) against 419 / bank phish type emails sent from compromised webmail accounts. Hit rate is not great, but the FP count is near zero. Regards, Ned Thanks Ned, Both of the above rules are already in trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf. http://ruleqa.spamassassin.org/20110114-r1058896-n/NSL_RCVD_FROM_USER/detail 0.5% spam hit rate, and some ham hits, however they are all in the ancient enron corpus that we will soon be removing. http://ruleqa.spamassassin.org/20110114-r1058896-n/T_NSL_RCVD_HELO_USER/detail Very few spam hits, and a number of ham hits but all in DOS's corpus. Perhaps we should ask him if they really are ham? Could you please describe how these rules work, and why the combination of them would be useful? Ah sorry, I meant to OR them in a meta rule: The idea behind these rules originates from a discussion on the old SpamL list around a year ago. They hit against a webmail - smtp injection point typically seen in compromised webmail accounts. Because they are so specific, some speculated this must be unique to only a few webmail packages. So we are simply looking back at (typically) the first Received header for strings like: Received: from User ([85.153.20.122]) Received: from User (unknown [200.138.162.23]) Received: from User (unverified [77.250.43.54]) by mail.hotspace.com.au or Received: from unknown (HELO User) (124.124.1.228) Received: from [62.172.163.253] (account t...@kievnet.com.ua HELO User) Received: from [75.137.153.140] (helo=User) Received: from [71.82.50.143] ([71.82.50.143:4150] helo=User) In a year of running them locally I've never seen them hit on a ham message. They appear to hit quite well for me because I pre-filter 95%+ of my spam at the smtp level (greylisting, HELO checks, spamhaus etc) so SA only gets to see the difficult to catch stuff which might inflate the percentage hits. As I said, they typically hit against bank phish sent from compromised accounts on legit servers hence why they make it through greylisting and many DNSBLs. In my corpus of 3402 spam I see NSL_RCVD_FROM_USER hit 604 (17.8%) and NSL_RCVD_HELO_USER hit 181 (5.3%). As there is (virtually?) no overlap, that's a combined hit rate of ~23%, the vast majority of which I would bet is bank phish. That is why I say these rules perform well for me - once you take out the spam that's trivial to filter (spambot spam), the hit rate against the remaining spam goes up. NSL_RCVD_FROM_USER already has a score. It appears that the combination of the two rules will be zero masscheck FP's, but a maximum of 0.1% spam hits. I suppose this is worthwhile for a night of testing, but I suspect it will be too small? Warren
Re: SARE and RulesDuJour still relevant
On 15/01/11 01:54, John Hardin wrote: On Fri, 14 Jan 2011, Ned Slider wrote: header NSL_RCVD_HELO_USER Received =~ /helo[= ]user\)/i describe NSL_RCVD_HELO_USER Received from HELO User Might want to combine into a meta rule with existing NSL_RCVD_FROM_USER rule: header NSL_RCVD_FROM_USER Received =~ /from User [\[\(]/ describe NSL_RCVD_FROM_USER Received from User The above are particularly effective (here) against 419 / bank phish type emails sent from compromised webmail accounts. Hit rate is not great, but the FP count is near zero. Ned, I put those into my sandbox when you first suggested them and they are performing _quite_ well. Hi John, Yes, sorry - I had forgotten you tested these.
Re: SARE and RulesDuJour still relevant
On 01/15/2011 01:36 AM, Ned Slider wrote: In a year of running them locally I've never seen them hit on a ham message. They appear to hit quite well for me because I pre-filter 95%+ of my spam at the smtp level (greylisting, HELO checks, spamhaus etc) so SA only gets to see the difficult to catch stuff which might inflate the percentage hits. As I said, they typically hit against bank phish sent from compromised accounts on legit servers hence why they make it through greylisting and many DNSBLs. In my corpus of 3402 spam I see NSL_RCVD_FROM_USER hit 604 (17.8%) and NSL_RCVD_HELO_USER hit 181 (5.3%). As there is (virtually?) no overlap, that's a combined hit rate of ~23%, the vast majority of which I would bet is bank phish. That is why I say these rules perform well for me - once you take out the spam that's trivial to filter (spambot spam), the hit rate against the remaining spam goes up. It seems that NSL_RCVD_FROM_USER is indeed safe (no FP's except for trec_enron), but the spam hit rate may vary wildly on different targets. My servers without any pre-spamassassin filters are seeing ~0.5-1.5% hit rates. 72_scores.cf score NSL_RCVD_FROM_USER1.180 1.226 1.180 1.226 spamassassin-3.3.x already has NSL_RCVD_FROM_USER with a production score. I am confused as to how NSL_RCVD_FROM_USER got this score, because AFAICT NSL_RCVD_FROM_USER was not in the 3.3 masscheck. In any case, OR with NSL_RCVD_FROM_HELO isn't going to be helpful as you're only piling up more score. Assigning a score to the HELO rule might be a good idea if we are certain it is safe. OTOH, the masschecks indicate very little hits at all on that rule. Warren
SARE and RulesDuJour still relevant
Hey All! Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. James
Re: SARE and RulesDuJour still relevant
On 01/14/2011 01:28 PM, James Lay wrote: Hey All! Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. James As far as I know SpamAssassin Rules Emporium alias SARE is depreciated and no longer maintained... M$-Internet Exploder est le cancer de l'Internet, voyez pourquoi ici: http://www.aful.org/ressources/documentations/msie-problemes-securite -- (°- Bernard Lheureux Gestionnaire des MailingLists ML, TechML, LinuxML //\ http://www.bbsoft4.org/Mailinglists.htm ** MailTo:r...@bbsoft4.org v_/_ http://www.bbsoft4.org/ * http://www.portalinux.org/
Re: SARE and RulesDuJour still relevant
This is getting asked about every week :-) Short answer: no, not relevant anymore, don't use. Kai -- Get your web at Conactive Internet Services: http://www.conactive.com
Re: SARE and RulesDuJour still relevant
On 2011/01/14 7:28 AM, James Lay wrote: Hey All! Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. James Since SA 3.3, rules are no longer included in the tarball. You are expected to run sa-update after installation to get the latest ruleset, which you've obviously done. There is no need to copy anything after that point. RulesDuJour is deprecated in favor of sa-update and custom channels. Worthwhile SARE rules were pulled into stock SA and are no longer being updated. Be careful when looking for additional channels due to outdated info still lurking about. I use SOUGHT, others find KHOP useful and there may be a couple of others. The OpenProtect channels should not be used. Check the list archives for recent posts on the matter. -- /Jason smime.p7s Description: S/MIME Cryptographic Signature
Re: SARE and RulesDuJour still relevant
On 01/14/2011 01:28 PM, James Lay wrote: Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. On 14.01.11 13:34, Bernard Lheureux wrote: As far as I know SpamAssassin Rules Emporium alias SARE is depreciated and no longer maintained... and RulesDuJour is deprecated even longer. Last recommendations were to use sa-update even for SARE rules. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot.
Re: SARE and RulesDuJour still relevant
On 1/14/11 6:38 AM, Jason Bertoch ja...@i6ix.com wrote: On 2011/01/14 7:28 AM, James Lay wrote: Hey All! Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. James Since SA 3.3, rules are no longer included in the tarball. You are expected to run sa-update after installation to get the latest ruleset, which you've obviously done. There is no need to copy anything after that point. RulesDuJour is deprecated in favor of sa-update and custom channels. Worthwhile SARE rules were pulled into stock SA and are no longer being updated. Be careful when looking for additional channels due to outdated info still lurking about. I use SOUGHT, others find KHOP useful and there may be a couple of others. The OpenProtect channels should not be used. Check the list archives for recent posts on the matter. -- /Jason Excellentthanks for the quick answers all...have to admit SpamAssassin seems a lot easier to set up then a few years ago :) James P.S. Glad I could carry the torch of this question for this week ;)
Re: SARE and RulesDuJour still relevant
On 1/14/2011 2:28 AM, James Lay wrote: Hey All! Been a while since I did a full blown install of SpamAssassin, and as I'm looking at my old setup, I see a fair amount of changes. I have the SARE rules as well as RulesDuJour running, but noticed that on a fresh install of SA, after doing an sa-update, there are very few rules files (the bulk of which are in /var/lib/spamassassin/3.003001/). Have rules been optimized or something? Should I copy over all the SARE rules and setup RulesDuJour to update, or leave as is? Thanks for the input. James http://www.spamtips.org/ See my blog for current recommendations of rules that are tested to be safe. I use nightly masscheck results at http://ruleqa.spamassassin.org/ in addition to local masschecks to verify that rules are safe before making recommendations. https://admin.fedoraproject.org/mailman/listinfo/spamassassin-news Spamassassin for Sysadmins Newsletter You have installed all the optional plugins right (pyzor, razor, dcc)? http://www.spamtips.org/2010/12/cacheredir-rule-prevent-google-cache.html CACHEREDIR here has proven to be completely safe, while effective against 1-4% of low scoring spam. http://wiki.apache.org/spamassassin/SoughtRules Use SOUGHT. It is good. Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. Warren
Re: SARE and RulesDuJour still relevant
On Fri, 14 Jan 2011 11:04:49 -1000, Warren Togami Jr. wtog...@gmail.com wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. meta SPF_NICE_PASS (SPF_HELO_PASS SPF_PASS)
Re: SARE and RulesDuJour still relevant
On 14/01/11 21:04, Warren Togami Jr. wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. Warren header NSL_RCVD_HELO_USER Received =~ /helo[= ]user\)/i describeNSL_RCVD_HELO_USER Received from HELO User Might want to combine into a meta rule with existing NSL_RCVD_FROM_USER rule: header NSL_RCVD_FROM_USER Received =~ /from User [\[\(]/ describe NSL_RCVD_FROM_USER Received from User The above are particularly effective (here) against 419 / bank phish type emails sent from compromised webmail accounts. Hit rate is not great, but the FP count is near zero. Regards, Ned
Re: SARE and RulesDuJour still relevant
On 01/14/2011 01:09 PM, Ned Slider wrote: On 14/01/11 21:04, Warren Togami Jr. wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. Warren header NSL_RCVD_HELO_USER Received =~ /helo[= ]user\)/i describe NSL_RCVD_HELO_USER Received from HELO User Might want to combine into a meta rule with existing NSL_RCVD_FROM_USER rule: header NSL_RCVD_FROM_USER Received =~ /from User [\[\(]/ describe NSL_RCVD_FROM_USER Received from User The above are particularly effective (here) against 419 / bank phish type emails sent from compromised webmail accounts. Hit rate is not great, but the FP count is near zero. Regards, Ned Thanks Ned, Both of the above rules are already in trunk/rulesrc/sandbox/jhardin/20_misc_testing.cf. http://ruleqa.spamassassin.org/20110114-r1058896-n/NSL_RCVD_FROM_USER/detail 0.5% spam hit rate, and some ham hits, however they are all in the ancient enron corpus that we will soon be removing. http://ruleqa.spamassassin.org/20110114-r1058896-n/T_NSL_RCVD_HELO_USER/detail Very few spam hits, and a number of ham hits but all in DOS's corpus. Perhaps we should ask him if they really are ham? Could you please describe how these rules work, and why the combination of them would be useful? NSL_RCVD_FROM_USER already has a score. It appears that the combination of the two rules will be zero masscheck FP's, but a maximum of 0.1% spam hits. I suppose this is worthwhile for a night of testing, but I suspect it will be too small? Warren
Re: SARE and RulesDuJour still relevant
On Fri, 14 Jan 2011, Warren Togami Jr. wrote: Anyone else have effective local rules? Please let me know and I'll put them into the nightly masscheck for testing. I need to put in my postcard rules... -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Activist: Someone who gets involved. Unregistered Lobbyist: Someone who gets involved with something the MSM doesn't approve of. -- WizardPC --- 3 days until Benjamin Franklin's 305th Birthday
Re: SARE and RulesDuJour still relevant
On Fri, 14 Jan 2011, Ned Slider wrote: header NSL_RCVD_HELO_USER Received =~ /helo[= ]user\)/i describeNSL_RCVD_HELO_USER Received from HELO User Might want to combine into a meta rule with existing NSL_RCVD_FROM_USER rule: header NSL_RCVD_FROM_USER Received =~ /from User [\[\(]/ describe NSL_RCVD_FROM_USER Received from User The above are particularly effective (here) against 419 / bank phish type emails sent from compromised webmail accounts. Hit rate is not great, but the FP count is near zero. Ned, I put those into my sandbox when you first suggested them and they are performing _quite_ well. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Activist: Someone who gets involved. Unregistered Lobbyist: Someone who gets involved with something the MSM doesn't approve of. -- WizardPC --- 3 days until Benjamin Franklin's 305th Birthday
Re: RulesDuJour
Anshul Chauhan wrote: we have to copy KAM.cf to /usr/share/spamassassin only for its integration with spamassassin or something else is to done I'm using spamassassin-3.2.5-1.el4.rf on Centos4.7 Any add-on rules should be placed in the same directory as your local.cf (ie: /etc/mail/spamassassin/ in most cases). SA reads *.cf from this directory, not just local.cf. Adding files to /usr/share/spamassassin, or making changes to files present there, is not a good idea. When SpamAssassin gets upgraded, this whole directory will be nuked by the installer.
Re: RulesDuJour
Anshul Chauhan wrote: we have to copy KAM.cf to /usr/share/spamassassin only for its integration with spamassassin or something else is to done I'm using spamassassin-3.2.5-1.el4.rf on Centos4.7 On 30.06.09 02:11, Matt Kettler wrote: Any add-on rules should be placed in the same directory as your local.cf (ie: /etc/mail/spamassassin/ in most cases). SA reads *.cf from this directory, not just local.cf. Adding files to /usr/share/spamassassin, or making changes to files present there, is not a good idea. When SpamAssassin gets upgraded, this whole directory will be nuked by the installer. ... and after first sa-update, it won't get used even. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One World. One Web. One Program. - Microsoft promotional advertisement Ein Volk, ein Reich, ein Fuhrer! - Adolf Hitler
Re: RulesDuJour
we have to copy KAM.cf to /usr/share/spamassassin only for its integration with spamassassin or something else is to done I'm using spamassassin-3.2.5-1.el4.rf on Centos4.7 Warm Regards, Anshul Chauhan Dream is not what you see while sleep, it's the thing that does not let you sleep. On Sat, Jun 27, 2009 at 2:39 AM, Gerry Maddock gmadd...@futuremetals.comwrote: R I'm new to the list, and haven't been working with Spamassasin for long (about 1 year). It worked fine filtering spam, but now more and more are getting through. I found something called RulesDuJour on the net, but it seems it's not being updated anymore. Is it usefull to stil use it, or does anyone have some advice about thirth party rules that can help? Hey Roland, checkout KAM ( http://www.peregrinehw.com/downloads/SpamAssassin/contrib/KAM.cf) also sought (http://wiki.apache.org/spamassassin/SoughtRules) JFK Antifishing (http://www.jules.fm/Logbook/files/anti-phishing-v2.html) Also use Razor,DCC, Pyzor I suggest looking into using MailScanner + spamassassin you can find MailScanner here: http://www.mailscanner.info/ CONFIDENTIALITY: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and / or privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
Re: RulesDuJour
On 26.06.09 23:05, Roland Klein Overmeer wrote: I'm new to the list, and haven't been working with Spamassasin for long (about 1 year). It worked fine filtering spam, but now more and more are getting through. I found something called RulesDuJour on the net, but it seems it's not being updated anymore. Is it usefull to stil use it, or does anyone have some advice about thirth party rules that can help? I am sure RulesDuJour are obsolete for more then a year. Since SpamAssassin-3.1, sa-update is the preferred say to upsate rules, including those of SARE. Who told you to use the RulesDuJour script? The SARE rules aren't being updated for longer time, see http://www.rulesemporium.com/ -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
RulesDuJour
Hi All, I'm new to the list, and haven't been working with Spamassasin for long (about 1 year). It worked fine filtering spam, but now more and more are getting through. I found something called RulesDuJour on the net, but it seems it's not being updated anymore. Is it usefull to stil use it, or does anyone have some advice about thirth party rules that can help? Regards, Roland.
Re: RulesDuJour
R I'm new to the list, and haven't been working with Spamassasin for long (about 1 year). It worked fine filtering spam, but now more and more are getting through. I found something called RulesDuJour on the net, but it seems it's not being updated anymore. Is it usefull to stil use it, or does anyone have some advice about thirth party rules that can help? Hey Roland, checkout KAM ( http://www.peregrinehw.com/downloads/SpamAssassin/contrib/KAM.cf) also sought (http://wiki.apache.org/spamassassin/SoughtRules) JFK Antifishing (http://www.jules.fm/Logbook/files/anti-phishing-v2.html) Also use Razor,DCC, Pyzor I suggest looking into using MailScanner + spamassassin you can find MailScanner here: http://www.mailscanner.info/ CONFIDENTIALITY: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and / or privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
Re: RulesDuJour Tripwire Issue
On Wed, 2008-08-27 at 23:05 -0500, Curtis LaMasters wrote: @Andy - I was able to parse the script that you sent me to which had neither my problem nor my solution Actually it DID contain your problem AND the solution: # Version 1.31 NOTICE! Rules du jour is no longer being maintained. As the author of RDJ, I recommend switching to the official update method for spamassassin, sa-update. That should have told you all you needed to know.
RulesDuJour Tripwire Issue
Now on to my next issue. Thank you Dan for helping me with the last one. I have RulesDuJour updating (probably too often) but I'm getting the following error. I've been able to find the issue on Google but no resolution. Hoping you can help me figure this out. ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/tripwire.cf/etc/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /etc/spamassassin/RulesDuJour/tripwire.cf.20080827-1656 /etc/spamassassin/ tripwire.cf; Lint output: [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf: META HTTP-EQUIV=Pragma CONTENT=no-cache [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf: META HTTP-EQUIV=Expires CONTENT=-1 [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/ tripwire.cf: /HEAD/HTML [14866] warn: lint: 4 issues detected, please rerun with debug enabled for more information Curtis LaMasters http://www.curtis-lamasters.com http://www.builtnetworks.com
Re: RulesDuJour Tripwire Issue
Curtis LaMasters wrote: Now on to my next issue. Thank you Dan for helping me with the last one. I have RulesDuJour updating (probably too often) but I'm getting the following error. I've been able to find the issue on Google but no resolution. Hoping you can help me figure this out. RDJ is almost completely dead and obsolete. sa-update would be the preferred way to update most rules, and with a little tweaking it can even update rules from SARE. Based on the results you're seeing check the URL for tripwire in your RDJ script. I'm betting it points to a URL that's no longer serving the tripwire file, and instead returns an error page which produces the errors below. ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/tripwire.cf http://tripwire.cf /etc/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /etc/spamassassin/RulesDuJour/tripwire.cf.20080827-1656 /etc/spamassassin/tripwire.cf http://tripwire.cf; Lint output: [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf http://tripwire.cf: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf http://tripwire.cf: META HTTP-EQUIV=Pragma CONTENT=no-cache [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf http://tripwire.cf: META HTTP-EQUIV=Expires CONTENT=-1 [14866] warn: config: failed to parse line, skipping, in /etc/spamassassin/tripwire.cf http://tripwire.cf: /HEAD/HTML [14866] warn: lint: 4 issues detected, please rerun with debug enabled for more information Curtis LaMasters http://www.curtis-lamasters.com http://www.builtnetworks.com
Re: RulesDuJour Tripwire Issue
@Andy - I was able to parse the script that you sent me to which had neither my problem nor my solution within it but I did find 1 problem. On my config it was listed as 99_FVGT_Tripwire.cf as well as the script that you sent a link to. However, located at the download site it was 88_FVGT_Tripwire.cf. @Matt - Thank you, you were correct. The download link was incorrect. I believe my using rulesdujour stemmed from me using outdated setup documents. I'll put some effort into researching that. Thanks, Curtis LaMasters http://www.curtis-lamasters.com http://www.builtnetworks.com
RE: RulesDuJour
But it is. RulesDuJour delivery is broken, and it gives only HTTP-error page, which causes the error. sa-update can deliver the rules without errors. However, I already use sa-update other than RulesDuJour, which is scheduled as follow: 22 14 * * 1,2,3,4,5 sa-update rcamavisd restart What channels sa-update updates? And if I use the '--channelfile' what happens? Maybe sa-update updates only the channels included in the file specifided for the argument '--channelfile' or it adds the file listed to the default list of channels maintained by sa-update? Thanks, rocsca
RE: RulesDuJour
Rocco Scappatura wrote: But it is. RulesDuJour delivery is broken, and it gives only HTTP-error page, which causes the error. sa-update can deliver the rules without errors. However, I already use sa-update other than RulesDuJour, which is scheduled as follow: The webpage at http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt says: How to update SARE rulesets via Apache SpamAssassin's sa-update. This is what RDJ did and apparently RDJ doesn't work anymore. What channels sa-update updates? And if I use the '--channelfile' what happens? Maybe sa-update updates only the channels included in the file specifided for the argument '--channelfile' or it adds the file listed to the default list of channels maintained by sa-update? The page describes how to select what channels sa-update will update. You'll just have an extra sa-update in your crontab; one for the official SA rules and one for the SARE rules. Grts, Rob
Re: RulesDuJour
What channels sa-update updates? And if I use the '--channelfile' what happens? Maybe sa-update updates only the channels included in the file specifided for the argument '--channelfile' or it adds the file listed to the default list of channels maintained by sa-update? The page describes how to select what channels sa-update will update. You'll just have an extra sa-update in your crontab; one for the official SA rules and one for the SARE rules. I have only one sa-update in my crontab -- channels.txt -- update.spamassassin.org 72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net 70_sare_evilnum0.cf.sare.sa-update.dostech.net 70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net 70_sare_html0.cf.sare.sa-update.dostech.net 70_sare_html_eng.cf.sare.sa-update.dostech.net 70_sare_header0.cf.sare.sa-update.dostech.net 70_sare_header_eng.cf.sare.sa-update.dostech.net 70_sare_specific.cf.sare.sa-update.dostech.net 70_sare_adult.cf.sare.sa-update.dostech.net 72_sare_bml_post25x.cf.sare.sa-update.dostech.net 99_sare_fraud_post25x.cf.sare.sa-update.dostech.net 70_sare_spoof.cf.sare.sa-update.dostech.net 70_sare_random.cf.sare.sa-update.dostech.net 70_sare_oem.cf.sare.sa-update.dostech.net 70_sare_genlsubj0.cf.sare.sa-update.dostech.net 70_sare_genlsubj_eng.cf.sare.sa-update.dostech.net 70_sare_unsub.cf.sare.sa-update.dostech.net 70_sare_uri0.cf.sare.sa-update.dostech.net 70_sare_obfu0.cf.sare.sa-update.dostech.net 70_sare_stocks.cf.sare.sa-update.dostech.net -- -- cronjob --- /usr/local/bin/sa-update --allowplugins --channelfile /etc/spamassassin/channels.txt --nogpg /usr/local/bin/sa-compile /etc/init.d/spamassassin reload --
RE: RulesDuJour
The page describes how to select what channels sa-update will update. You'll just have an extra sa-update in your crontab; one for the official SA rules and one for the SARE rules. I have only one sa-update in my crontab Yes, sorry, it can be done using 1 sa-update line; I actually don't remember why I have 2 lines for that but it works. Maybe I'll change that someday. However, I think we agree that the OP should switch from RDJ to sa-update to let it handle the SARE updates. Grts, Rob
RE: RulesDuJour
I was thinking of looking into RulesDuJour as an alternative to sa-update, as there hasn't been anything to update since July, unless one installs yet unreleased versions of SpamAssassin. (find var -ls to check.) However reading this thread has scared me further. (Shall I chuck Santa Claus (rms) and the Penguin (linus) and install WIN2000 and enjoy Norton Daily Updates?)
Re: RulesDuJour
[EMAIL PROTECTED] wrote:
I was thinking of looking into RulesDuJour as an alternative to
sa-update, as there hasn't been anything to update since July, unless
one installs yet unreleased versions of SpamAssassin. (find var -ls
to check.)
Why are you so concerned about updates for the sake of updates?
Generally we only feel compelled to write rules and release them when
there's a need for them (remember, we're all volunteers). Personally,
I've been receiving very, very little spam that isn't caught by SA.
If you'd like to use RDJ go for it. The SARE rules (which are available
via sa-update anyway, and from what I've heard only reliably via
sa-update) haven't been updated much in the last 6 months either:
[EMAIL PROTECTED] channels]$ find . -type f -mtime -180 -name *.gz -exec ls
-l {} \; | cut -d' ' -f7-
May 28 13:14 ./70_sare_obfu.cf/200705281000.tar.gz
May 28 14:14 ./70_sare_obfu.cf/200705281100.tar.gz
May 29 16:14 ./70_sare_obfu.cf/200705291300.tar.gz
Jun 1 05:14 ./70_sare_obfu.cf/200706010200.tar.gz
Jun 4 21:14 ./70_sare_obfu.cf/200706041800.tar.gz
Jun 5 11:14 ./70_sare_obfu.cf/200706050800.tar.gz
May 21 10:14 ./70_sare_obfu1.cf/200705210700.tar.gz
May 21 11:14 ./70_sare_obfu1.cf/200705210800.tar.gz
May 28 13:14 ./70_sare_obfu1.cf/200705281000.tar.gz
Jun 1 05:14 ./70_sare_obfu1.cf/200706010200.tar.gz
Jun 4 21:14 ./70_sare_obfu1.cf/200706041800.tar.gz
May 21 10:14 ./72_sare_bml_post25x.cf/200705210700.tar.gz
May 28 13:14 ./70_sare_obfu0.cf/200705281000.tar.gz
Jun 1 05:14 ./70_sare_obfu0.cf/200706010200.tar.gz
Jun 4 21:14 ./70_sare_obfu0.cf/200706041800.tar.gz
May 21 10:14 ./70_sare_adult.cf/200705210700.tar.gz
Mar 9 10:08 ./70_sc_top200.cf/200703090800.tar.gz
Mar 9 11:08 ./70_sc_top200.cf/200703090900.tar.gz
Mar 9 12:08 ./70_sc_top200.cf/200703091000.tar.gz
Mar 9 17:08 ./70_sc_top200.cf/200703091500.tar.gz
Mar 12 11:08 ./70_sc_top200.cf/200703120800.tar.gz
Mar 14 16:08 ./70_sc_top200.cf/200703141300.tar.gz
Mar 15 13:08 ./70_sc_top200.cf/200703151000.tar.gz
Mar 22 13:24 ./70_sc_top200.cf/200703221000.tar.gz
Mar 30 12:10 ./70_sc_top200.cf/200703300900.tar.gz
Apr 5 12:10 ./70_sc_top200.cf/200704050900.tar.gz
Apr 6 10:10 ./70_sc_top200.cf/200704060700.tar.gz
Apr 6 17:10 ./70_sc_top200.cf/200704061400.tar.gz
May 23 11:14 ./70_sc_top200.cf/200705230800.tar.gz
May 24 12:14 ./70_sc_top200.cf/200705240900.tar.gz
May 6 23:24 ./70_sare_stocks.cf/200705062000.tar.gz
May 7 00:24 ./70_sare_stocks.cf/200705062100.tar.gz
Aug 18 08:14 ./70_sare_stocks.cf/200708181200.tar.gz
Apr 6 10:10 ./00_FVGT_File001.cf/200704060700.tar.gz
[EMAIL PROTECTED] channels]$
If you like, since you seem to be preoccupied with the raw number of
updates, you can compare that the number of updates released by the SA
project in the last 6 months:
[EMAIL PROTECTED] asf-sa-updates]$ find . -type f -mtime -180 -name *.gz
-perm 444 -exec ls -l {} \; | cut -d' ' -f7-
Sep 3 23:21 ./572502.tar.gz
May 7 00:31 ./535131.tar.gz
May 11 01:54 ./535132.tar.gz
May 31 01:41 ./543064.tar.gz
Jun 9 04:12 ./545708.tar.gz
Jul 4 17:46 ./548226.tar.gz
Jul 11 00:36 ./555165.tar.gz
Jul 15 18:55 ./556472.tar.gz
[EMAIL PROTECTED] asf-sa-updates]$
However reading this thread has scared me further.
(Shall I chuck Santa Claus (rms) and the Penguin (linus) and install
WIN2000 and enjoy Norton Daily Updates?)
That might not be a bad idea.
Daryl
RulesDuJour
Hello, It is some weeks that I get errors while I try to updates the SA rulesets. For example recently I get an error after the update of TripWire and SARE rulesets: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf /tmp/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /tmp/RulesDuJour/tripwire.cf.20070831-1530 /etc/mail/spamassassin/tripwire.cf; mv -f /etc/mail/spamassassin/70_sare_stocks.cf /tmp/RulesDuJour/70_sare_stocks.cf.2; mv -f /tmp/RulesDuJour/70_sare_stocks.cf.20070831-1530 /etc/mail/spamassassin/70_sare_stocks.cf; Lint output: [826] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [826] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [826] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [826] warn: config: failed to parse line, skipping: /HEAD/HTML [826] warn: lint: 4 issues detected, please rerun with debug enabled for more information I can't try how to solve this problem.. Maybe is there any outdates ruleset? If yes, who is it? Thanks, rocsca
Re: RulesDuJour
Rocco Scappatura schrieb: Hello, It is some weeks that I get errors while I try to updates the SA rulesets. For example recently I get an error after the update of TripWire and SARE rulesets: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf /tmp/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /tmp/RulesDuJour/tripwire.cf.20070831-1530 /etc/mail/spamassassin/tripwire.cf; mv -f /etc/mail/spamassassin/70_sare_stocks.cf /tmp/RulesDuJour/70_sare_stocks.cf.2; mv -f /tmp/RulesDuJour/70_sare_stocks.cf.20070831-1530 /etc/mail/spamassassin/70_sare_stocks.cf; Lint output: [826] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [826] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [826] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [826] warn: config: failed to parse line, skipping: /HEAD/HTML [826] warn: lint: 4 issues detected, please rerun with debug enabled for more information I can't try how to solve this problem.. Maybe is there any outdates ruleset? If yes, who is it? Using sa-update is the suggested method now: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt or read the lists archive you should find many posts on this ... Thanks, rocsca -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
RE: RulesDuJour
Using sa-update is the suggested method now: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt I don't think that this is related to the error discussed in this thread. rocsca
Re: RulesDuJour
Using sa-update is the suggested method now: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt I don't think that this is related to the error discussed in this thread. rocsca But it is. RulesDuJour delivery is broken, and it gives only HTTP-error page, which causes the error. sa-update can deliver the rules without errors.
RulesDuJour/deneb.dwf.com: 404 errors
I am getting the following error message from my (daily) update of SpamAssassin Rules --- Subject: RulesDuJour/deneb.dwf.com: 404 errors and the contents of the message The following rules had errors: SARE 70_sare_bayes_poison_nxm.cf Ruleset had an unknown error: curl exit code: 52 curl: (52) Empty reply from server 000 --- Other than blowing everything away and starting again Im not sure how to clear this up. Can one of you experts give me a clue. -- Reg.Clemens [EMAIL PROTECTED]
Re: RulesDuJour/deneb.dwf.com: 404 errors
On Thu, 2007-08-02 at 12:25 -0600, Reg Clemens wrote: I am getting the following error message from my (daily) update of SpamAssassin Rules --- Subject: RulesDuJour/deneb.dwf.com: 404 errors and the contents of the message The following rules had errors: SARE 70_sare_bayes_poison_nxm.cf Ruleset had an unknown error: curl exit code: 52 curl: (52) Empty reply from server 000 --- Other than blowing everything away and starting again Im not sure how to clear this up. actually, that is the best policy. RulesDuJour has been supplanted by sa-update. Can one of you experts give me a clue. Not an expert, but I did create an RPM will all of the pieces so that I would not have to re-create this every time. I have a script that runs from cron once a day that calls sa-update. If successful, it runs sa-compile, then reloads amavisd (and flushes postfix, since amavisd is messy when it reloads... Probably need to code a graceful shutdown for amavisd at some point.) To pick up all of the channels, I created a channel file, like so: [EMAIL PROTECTED] ~]$ sudo cat /etc/sysconfig/sa-update-channels updates.spamassassin.org 70_sare_evilnum0.cf.sare.sa-update.dostech.net bogus-virus-warnings.cf.sare.sa-update.dostech.net 70_sare_adult.cf.sare.sa-update.dostech.net 70_sare_random.cf.sare.sa-update.dostech.net 70_sare_header0.cf.sare.sa-update.dostech.net 70_sare_genlsubj0.cf.sare.sa-update.dostech.net 99_sare_fraud_post25x.cf.sare.sa-update.dostech.net 70_sare_html0.cf.sare.sa-update.dostech.net 70_sare_html1.cf.sare.sa-update.dostech.net 70_sare_uri0.cf.sare.sa-update.dostech.net 70_sare_specific.cf.sare.sa-update.dostech.net 70_sare_obfu0.cf.sare.sa-update.dostech.net 70_sare_unsub.cf.sare.sa-update.dostech.net 70_sare_stocks.cf.sare.sa-update.dostech.net So that gpg works, I imported the public key from dostech.net and referenced it in an gpgkeyfile: [EMAIL PROTECTED] ~]$ sudo cat /etc/sysconfig/sa-update-keys 5244EC45 856AA88A the actual update command is sa-update --channelfile /etc/sysconfig/sa-update-channels --gpgkeyfile /etc/sysconfig/sa-update-keys once set up, this has much less impact than rulesdujour had. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: RulesDuJour lint failed. Updates rolled back.
for RULESET_NAME in ${TRUSTED_RULESETS} ; do
# Set up some array variables
INDEX=${!RULESET_NAME};
Sleep 1# --- add this line at the end of the for loop
done
{^_^}
- Original Message -
From: Dallas Engelken [EMAIL PROTECTED]
To: users@spamassassin.apache.org
Sent: Thursday, 2007, June 28 15:31
Subject: Re: RulesDuJour lint failed. Updates rolled back.
This must be an issue that needs to be raised with Prolexic, as they are
doing the DDoS protection for rulesemporium.com.
Can anyone reproduce this redirect outside of RDJ, and give me a dump of
the full transaction including http headers?
I'd rather fix the actual problem and not patch around it.
Thanks,
Dallas
Lindsay Haisley wrote:
This problem is probably due to the way Rules Emporium is handling
traffic. If requests come too fast from the same address, or if their
server is busy, they send an HTML redirect page instructing the client
to try again in 0.1 second. Curl and wget don't understand meta
http-equiv=Refresh ... and simply store the refresh page as the
output of the request. rules_du_jour is just a shell script so a proper
fix should be pretty easy. The following is a quick and dirty patch
which sort of solves the problem, at least for the next run of
rules_du_jour.
cut here
--- /root/rules_du_jour.orig2007-06-17 21:01:24.0 -0500
+++ /var/lib/spamassassin/rules_du_jour 2007-06-18
12:37:44.0 -0500
@@ -907,6 +907,8 @@
[ ${SEND_THE_EMAIL} ] echo -e ${MESSAGES} | sh -c
${MAILCMD} -s \RulesDuJour Run Summary on ${HOSTNAME}\
${MAIL_ADDRESS};
fi
+grep -il 'META HTTP-EQUIV' ${TMPDIR}/*|xargs -n1 rm -f +
cd ${OLDDIR};
exit;
cut here
rules_du_jour will still fail, but this will clean up the mess and next
time (hopefully) it'll run properly. A proper fix would sense when this
happens and retry the download after a suitable short wait. It may also
be helpful to insert some sleep .5 instructions at appropriate points
(or sleep 1 if your implementation of sleep(1) doesn't understand
floating point numbers).
On Thu, 2007-06-28 at 11:22 +0100, Nigel Frankcom wrote:
On Wed, 27 Jun 2007 16:42:39 -0400, Daryl C. W. O'Shea
[EMAIL PROTECTED] wrote:
Nigel Frankcom wrote:
On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED]
wrote:
I?ve been getting the lint failures found below on my Rules Du Jour
updates for a few weeks now. Yes this would be since the DDoS
attacks
on rulesemporium. It looks like the same problem people have been
having with the tripwire but for me it?s the adult and since just
recently the spoof rules. The solutions I've seen don't seem to work
for me. I see that my cron job (run nightly) is pulling some HTML
source instead of the rules. I?ve tried removing the faulty
70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually
replacing it with the ?actual? file using wget. I?ve even manually
updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure
that it was correct. When I us ?wget
http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it
works without problems. Does anyone have any ideas on how I might fix
this problem?
snip
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf
The quick cure is to delete anything in the
/etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand.
That worked for me on CentOS 4.5
The bug has been reported and a fix is due in 3.2.2 I believe.
Huh? What's SA have to do with RDJ triggering Prolexic's DoS
protection?
Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the
sa-update errors confused. I guess maybe I should dye my hair blonde.
Apologies for any confusion I've caused.
Kind regards
Nigel
--
Dallas Engelken
[EMAIL PROTECTED]
http://uribl.com
Re: RulesDuJour lint failed. Updates rolled back.
On Wed, 27 Jun 2007 16:42:39 -0400, Daryl C. W. O'Shea [EMAIL PROTECTED] wrote: Nigel Frankcom wrote: On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED] wrote: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf The quick cure is to delete anything in the /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand. That worked for me on CentOS 4.5 The bug has been reported and a fix is due in 3.2.2 I believe. Huh? What's SA have to do with RDJ triggering Prolexic's DoS protection? Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the sa-update errors confused. I guess maybe I should dye my hair blonde. Apologies for any confusion I've caused. Kind regards Nigel
Re: RulesDuJour lint failed. Updates rolled back.
Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the sa-update errors confused. I guess maybe I should dye my hair blonde. Apologies for any confusion I've caused. Geez - blonde it is - it's sa-compile not sa-update! I wonder if McDonalds have any jobs going :-/ Kind regards Nigel
Re: RulesDuJour lint failed. Updates rolled back.
This problem is probably due to the way Rules Emporium is handling
traffic. If requests come too fast from the same address, or if their
server is busy, they send an HTML redirect page instructing the client
to try again in 0.1 second. Curl and wget don't understand meta
http-equiv=Refresh ... and simply store the refresh page as the
output of the request. rules_du_jour is just a shell script so a proper
fix should be pretty easy. The following is a quick and dirty patch
which sort of solves the problem, at least for the next run of
rules_du_jour.
cut here
--- /root/rules_du_jour.orig2007-06-17 21:01:24.0 -0500
+++ /var/lib/spamassassin/rules_du_jour 2007-06-18 12:37:44.0 -0500
@@ -907,6 +907,8 @@
[ ${SEND_THE_EMAIL} ] echo -e ${MESSAGES} | sh -c ${MAILCMD} -s
\RulesDuJour Run Summary on ${HOSTNAME}\ ${MAIL_ADDRESS};
fi
+grep -il 'META HTTP-EQUIV' ${TMPDIR}/*|xargs -n1 rm -f
+
cd ${OLDDIR};
exit;
cut here
rules_du_jour will still fail, but this will clean up the mess and next
time (hopefully) it'll run properly. A proper fix would sense when this
happens and retry the download after a suitable short wait. It may also
be helpful to insert some sleep .5 instructions at appropriate points
(or sleep 1 if your implementation of sleep(1) doesn't understand
floating point numbers).
On Thu, 2007-06-28 at 11:22 +0100, Nigel Frankcom wrote:
On Wed, 27 Jun 2007 16:42:39 -0400, Daryl C. W. O'Shea
[EMAIL PROTECTED] wrote:
Nigel Frankcom wrote:
On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED]
wrote:
I?ve been getting the lint failures found below on my Rules Du Jour
updates for a few weeks now. Yes this would be since the DDoS attacks
on rulesemporium. It looks like the same problem people have been
having with the tripwire but for me it?s the adult and since just
recently the spoof rules. The solutions I've seen don't seem to work
for me. I see that my cron job (run nightly) is pulling some HTML
source instead of the rules. I?ve tried removing the faulty
70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually
replacing it with the ?actual? file using wget. I?ve even manually
updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure
that it was correct. When I us ?wget
http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it
works without problems. Does anyone have any ideas on how I might fix
this problem?
snip
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf
The quick cure is to delete anything in the
/etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand.
That worked for me on CentOS 4.5
The bug has been reported and a fix is due in 3.2.2 I believe.
Huh? What's SA have to do with RDJ triggering Prolexic's DoS protection?
Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the
sa-update errors confused. I guess maybe I should dye my hair blonde.
Apologies for any confusion I've caused.
Kind regards
Nigel
--
Lindsay Haisley [EMAIL PROTECTED]
FMP Computer Services
Re: RulesDuJour lint failed. Updates rolled back.
This must be an issue that needs to be raised with Prolexic, as they are
doing the DDoS protection for rulesemporium.com.
Can anyone reproduce this redirect outside of RDJ, and give me a dump of
the full transaction including http headers?
I'd rather fix the actual problem and not patch around it.
Thanks,
Dallas
Lindsay Haisley wrote:
This problem is probably due to the way Rules Emporium is handling
traffic. If requests come too fast from the same address, or if their
server is busy, they send an HTML redirect page instructing the client
to try again in 0.1 second. Curl and wget don't understand meta
http-equiv=Refresh ... and simply store the refresh page as the
output of the request. rules_du_jour is just a shell script so a proper
fix should be pretty easy. The following is a quick and dirty patch
which sort of solves the problem, at least for the next run of
rules_du_jour.
cut here
--- /root/rules_du_jour.orig2007-06-17 21:01:24.0 -0500
+++ /var/lib/spamassassin/rules_du_jour 2007-06-18 12:37:44.0 -0500
@@ -907,6 +907,8 @@
[ ${SEND_THE_EMAIL} ] echo -e ${MESSAGES} | sh -c ${MAILCMD} -s
\RulesDuJour Run Summary on ${HOSTNAME}\ ${MAIL_ADDRESS};
fi
+grep -il 'META HTTP-EQUIV' ${TMPDIR}/*|xargs -n1 rm -f
+
cd ${OLDDIR};
exit;
cut here
rules_du_jour will still fail, but this will clean up the mess and next
time (hopefully) it'll run properly. A proper fix would sense when this
happens and retry the download after a suitable short wait. It may also
be helpful to insert some sleep .5 instructions at appropriate points
(or sleep 1 if your implementation of sleep(1) doesn't understand
floating point numbers).
On Thu, 2007-06-28 at 11:22 +0100, Nigel Frankcom wrote:
On Wed, 27 Jun 2007 16:42:39 -0400, Daryl C. W. O'Shea
[EMAIL PROTECTED] wrote:
Nigel Frankcom wrote:
On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED]
wrote:
I?ve been getting the lint failures found below on my Rules Du Jour
updates for a few weeks now. Yes this would be since the DDoS attacks
on rulesemporium. It looks like the same problem people have been
having with the tripwire but for me it?s the adult and since just
recently the spoof rules. The solutions I've seen don't seem to work
for me. I see that my cron job (run nightly) is pulling some HTML
source instead of the rules. I?ve tried removing the faulty
70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually
replacing it with the ?actual? file using wget. I?ve even manually
updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure
that it was correct. When I us ?wget
http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it
works without problems. Does anyone have any ideas on how I might fix
this problem?
snip
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf
The quick cure is to delete anything in the
/etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand.
That worked for me on CentOS 4.5
The bug has been reported and a fix is due in 3.2.2 I believe.
Huh? What's SA have to do with RDJ triggering Prolexic's DoS protection?
Daryl is right, there is no fix due in 3.2.2 - I got the RDJ and the
sa-update errors confused. I guess maybe I should dye my hair blonde.
Apologies for any confusion I've caused.
Kind regards
Nigel
--
Dallas Engelken
[EMAIL PROTECTED]
http://uribl.com
Re: RulesDuJour lint failed. Updates rolled back.
On Thu, 2007-06-28 at 17:31 -0500, Dallas Engelken wrote:
This must be an issue that needs to be raised with Prolexic, as they are
doing the DDoS protection for rulesemporium.com.
Can anyone reproduce this redirect outside of RDJ, and give me a dump of
the full transaction including http headers?
Dallas,
By running a curl hit repeatedly on the RE server I reproduced the
problem. The cmd sent was:
curl -w %{http_code} --compressed -D /tmp/curl_headers -O -R -s -S
http://www.rulesemporium.com/rules/99_FVGT_Tripwire.cf
The headers sent back were as follows:
HTTP/1.0 200 OK
Connection: Close
Pragma: no-cache
cache-control: no-cache
Content-Type: text/html; charset=iso-8859-1
The page body returned was:
HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1
META HTTP-EQUIV=Pragma CONTENT=no-cache
META HTTP-EQUIV=Expires CONTENT=-1
/HEAD/HTML
A normal fetch of the actual .cf file returns these headers:
HTTP/1.1 200 OK
Age: 882
Date: Thu, 28 Jun 2007 22:41:08 GMT
Connection: Keep-Alive
Via: NS-CACHE-7.0: 1
ETag: 389f7-dbae-eb58c6c0
Server: Apache/2.0.54 (Gentoo/Linux) DAV/2 SVN/1.2.0 PHP/4.3.11
Last-Modified: Thu, 02 Jun 2005 00:00:03 GMT
Accept-Ranges: bytes
Content-Length: 56238
Keep-Alive: timeout=15, max=99
Content-Type: text/plain; charset=ISO-8859-1
I'd rather fix the actual problem and not patch around it.
Absolutely!!
--
Lindsay Haisley | In an open world,| PGP public key
FMP Computer Services |who needs Windows | available at
512-259-1190 | or Gates| http://pubkeys.fmp.com
http://www.fmp.com| |
Re: RulesDuJour lint failed. Updates rolled back.
On Thu, 2007-06-28 at 18:56 -0500, Lindsay Haisley wrote: By running a curl hit repeatedly on the RE server I reproduced the problem. By running this test a couple of times I'm apparently now blocked by RE :-P Oh well . Hope the info I sent was useful. -- Lindsay Haisley | In an open world,| PGP public key FMP Computer Services |who needs Windows | available at 512-259-1190 | or Gates| http://pubkeys.fmp.com http://www.fmp.com| |
RulesDuJour lint failed. Updates rolled back.
I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf /etc/mail/spamassassin/RulesDuJour/70_sare_adult.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/70_sare_adult.cf.20070627-0524 /etc/mail/spamassassin/70_sare_adult.cf; mv -f /etc/mail/spamassassin/70_sare_spoof.cf /etc/mail/spamassassin/RulesDuJour/70_sare_spoof.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/70_sare_spoof.cf.20070627-0525 /etc/mail/spamassassin/70_sare_spoof.cf; Lint output: [27054] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [27054] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [27054] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [27054] warn: config: failed to parse line, skipping: /HEAD/HTML [27054] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [27054] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [27054] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [27054] warn: config: failed to parse line, skipping: /HEAD/HTML [27054] warn: lint: 8 issues detected, please rerun with debug enabled for more information /snip Regards, Dave B.
Re: RulesDuJour lint failed. Updates rolled back.
David Boltz schrieb: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks [RDJ Problems ...] btw: Are there any additional things to know/caveats if i want to use sa-update channels for RDJ: (besides adding the default channel as described in: http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt) Regards, Dave B. -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: RulesDuJour lint failed. Updates rolled back.
On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED] wrote: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf The quick cure is to delete anything in the /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand. That worked for me on CentOS 4.5 The bug has been reported and a fix is due in 3.2.2 I believe. Regards Nigel
Re: RulesDuJour lint failed. Updates rolled back.
Nigel Frankcom schrieb: On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED] wrote: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf The quick cure is to delete anything in the /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand. That works, until the next run, then same error here ... That worked for me on CentOS 4.5 The bug has been reported and a fix is due in 3.2.2 I believe. Regards Nigel -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: RulesDuJour lint failed. Updates rolled back.
On Wed, 27 Jun 2007 16:18:28 +0200, Matthias Haegele [EMAIL PROTECTED] wrote: Nigel Frankcom schrieb: On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED] wrote: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf The quick cure is to delete anything in the /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand. That works, until the next run, then same error here ... That worked for me on CentOS 4.5 The bug has been reported and a fix is due in 3.2.2 I believe. Regards Nigel I had that a couple of times initially, but repeating the process and since running RDJ manually I haven't had a recurrence. RDJ doesn't change that often and it is no big deal here to add a manual RDJ to my manual morning admin chores (spam checks, logs, updates etc.) KR Nigel
Re: RulesDuJour lint failed. Updates rolled back.
Nigel Frankcom wrote: On Wed, 27 Jun 2007 08:48:02 -0400, David Boltz [EMAIL PROTECTED] wrote: I?ve been getting the lint failures found below on my Rules Du Jour updates for a few weeks now. Yes this would be since the DDoS attacks on rulesemporium. It looks like the same problem people have been having with the tripwire but for me it?s the adult and since just recently the spoof rules. The solutions I've seen don't seem to work for me. I see that my cron job (run nightly) is pulling some HTML source instead of the rules. I?ve tried removing the faulty 70_sare_adult.* from etc/mail/spamassassin/RulesDuJour/ and manually replacing it with the ?actual? file using wget. I?ve even manually updated the used /etc/mail/spamassassin/70_sare_adult.cf to ensure that it was correct. When I us ?wget http://rulesemporium.com/rules/70_sare_adult.cf? to grab the file it works without problems. Does anyone have any ideas on how I might fix this problem? snip ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/70_sare_adult.cf The quick cure is to delete anything in the /etc/mail/spamassassin/RulesDuJour/ directory and rerun RDJ by hand. That worked for me on CentOS 4.5 The bug has been reported and a fix is due in 3.2.2 I believe. Huh? What's SA have to do with RDJ triggering Prolexic's DoS protection? Daryl
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
From: Phil Barnett [EMAIL PROTECTED]
On Friday 22 June 2007 00:54, jdow wrote:
I think it was mentioned around these precincts about the time tripwire
was converted to 99_FVGTTripWire.cf and added to the SARE repositories
as a SARE rule set. I also note that I don't use it here anymore. The
return on CPU cycles investment was not sufficient to run that set
anymore.
When I'm looking for a place to shed load, I'll remember. Right now, this
is a
quad processor box, so I'll take all the rules I can get. We have a pretty
good spam marking rate right now. Not many things hit tripwire, but all
the
ones that do are spam, so I find it useful to drive the score up.
Take a quick look at tripwire and its newer equivalent. They should be
about the same thing. Loading both will result in the rules that may share
a name between the files having the newer version superseded by the older
version because files load in alphabetical order.
{^_^}
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Friday 22 June 2007 12:32, jdow wrote: Take a quick look at tripwire and its newer equivalent. They should be about the same thing. Loading both will result in the rules that may share a name between the files having the newer version superseded by the older version because files load in alphabetical order. I checked. RDJ is pulling the new one and naming it tripwire.cf in the working rule directory. At least they have the same date/time stamp and identical content. So I think I'm only using the newer one. Thanks. -- Phil Barnett AI4OF SKCC #600
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
From: Phil Barnett [EMAIL PROTECTED]
On Friday 22 June 2007 12:32, jdow wrote:
Take a quick look at tripwire and its newer equivalent. They should be
about the same thing. Loading both will result in the rules that may
share
a name between the files having the newer version superseded by the older
version because files load in alphabetical order.
I checked. RDJ is pulling the new one and naming it tripwire.cf in the
working
rule directory. At least they have the same date/time stamp and identical
content. So I think I'm only using the newer one.
RDJ does THAT? That's unbelievably ugly! The SARE rules have the lead
numbers for a purpose, make sure the rules load in a specific order.
{O.O} Me glad me use me own bash script instead of RDJ me thinks.
Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Is anyone else getting these failed messages on their tripwire.cf updates? I've been getting this message for several days now. It looks to me like the new tripwire.cf is very broken. -- Forwarded Message -- Subject: RulesDuJour Run Summary on taz5.fiberhosting.net Date: Thursday 21 June 2007 02:26 From: To: RulesDuJour Run Summary on taz5.fiberhosting.net: TripWire has changed on taz5.fiberhosting.net. Version line: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf /usr/share/spamassassin/RulesDuJour/99_ --- FVGT_Tripwire.cf.2; mv -f /usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225 /usr/share/spamassassin/tripwire.cf; Lint output: [24363] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues detected, please rerun with debug enabled for more information -- Phil Barnett AI4OF SKCC #600 RulesDuJour Run Summary on taz5.fiberhosting.net: TripWire has changed on taz5.fiberhosting.net. Version line: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf /usr/share/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225 /usr/share/spamassassin/tripwire.cf; Lint output: [24363] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues detected, please rerun with debug enabled for more information
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Thu, 21 Jun 2007 03:07:52 -0400, Phil Barnett [EMAIL PROTECTED] wrote: Is anyone else getting these failed messages on their tripwire.cf updates? I've been getting this message for several days now. It looks to me like the new tripwire.cf is very broken. -- Forwarded Message -- Subject: RulesDuJour Run Summary on taz5.fiberhosting.net Date: Thursday 21 June 2007 02:26 From: To: RulesDuJour Run Summary on taz5.fiberhosting.net: TripWire has changed on taz5.fiberhosting.net. Version line: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf /usr/share/spamassassin/RulesDuJour/99_ --- FVGT_Tripwire.cf.2; mv -f /usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225 /usr/share/spamassassin/tripwire.cf; Lint output: [24363] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues detected, please rerun with debug enabled for more information I've been getting the same for weeks. I ended up manually updating rules; especially the stock one since more and more seem to be slipping through. The problems seemed to start after the DDoS on rulesemporium; since then I've not been able to get any sense out of it via RDJ. When I manually update it all lint's clean. Time consuming but it works Hope that helps Nigel
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Nigel Frankcom wrote: I've been getting the same for weeks. I ended up manually updating rules; especially the stock one since more and more seem to be slipping through. The problems seemed to start after the DDoS on rulesemporium; since then I've not been able to get any sense out of it via RDJ. When I manually update it all lint's clean. Time consuming but it works Note that there haven't been any updates to 70_sare_stocks.cf since May 7th and no updates at all since June 5th, so manual updates probably aren't worth the bother. Daryl [EMAIL PROTECTED] channels]$ ls -l | grep -P May|Jun drwxrwxr-x 2 dos dos 4096 May 21 10:14 70_sare_adult.cf drwxrwxr-x 2 dos dos 4096 Jun 5 11:14 70_sare_obfu.cf drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu0.cf drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu1.cf drwxrwxr-x 2 dos dos 4096 May 7 00:24 70_sare_stocks.cf drwxrwxr-x 2 dos dos 12288 May 24 12:14 70_sc_top200.cf drwxrwxr-x 2 dos dos 4096 May 21 10:14 72_sare_bml_post25x.cf [EMAIL PROTECTED] channels]$
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Nigel Frankcom wrote: On Thu, 21 Jun 2007 03:07:52 -0400, Phil Barnett [EMAIL PROTECTED] wrote: Is anyone else getting these failed messages on their tripwire.cf updates? I've been getting this message for several days now. It looks to me like the new tripwire.cf is very broken. -- Forwarded Message -- Subject: RulesDuJour Run Summary on taz5.fiberhosting.net Date: Thursday 21 June 2007 02:26 From: To: RulesDuJour Run Summary on taz5.fiberhosting.net: TripWire has changed on taz5.fiberhosting.net. Version line: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf /usr/share/spamassassin/RulesDuJour/99_ --- FVGT_Tripwire.cf.2; mv -f /usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225 /usr/share/spamassassin/tripwire.cf; Lint output: [24363] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues detected, please rerun with debug enabled for more information I've been getting the same for weeks. I ended up manually updating rules; especially the stock one since more and more seem to be slipping through. The problems seemed to start after the DDoS on rulesemporium; since then I've not been able to get any sense out of it via RDJ. When I manually update it all lint's clean. Time consuming but it works Just try to delete the downloaded files in your rules_du_jour folder (for example /etc/mail/spamassassin/rules_du_jour/* ), respectively just the rule(s) that go wrong.I then redownloads the rules correctly and you're clear to go with RDJ again Matt
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Thu, 21 Jun 2007 03:30:00 -0400, Daryl C. W. O'Shea [EMAIL PROTECTED] wrote: Nigel Frankcom wrote: I've been getting the same for weeks. I ended up manually updating rules; especially the stock one since more and more seem to be slipping through. The problems seemed to start after the DDoS on rulesemporium; since then I've not been able to get any sense out of it via RDJ. When I manually update it all lint's clean. Time consuming but it works Note that there haven't been any updates to 70_sare_stocks.cf since May 7th and no updates at all since June 5th, so manual updates probably aren't worth the bother. Daryl [EMAIL PROTECTED] channels]$ ls -l | grep -P May|Jun drwxrwxr-x 2 dos dos 4096 May 21 10:14 70_sare_adult.cf drwxrwxr-x 2 dos dos 4096 Jun 5 11:14 70_sare_obfu.cf drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu0.cf drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu1.cf drwxrwxr-x 2 dos dos 4096 May 7 00:24 70_sare_stocks.cf drwxrwxr-x 2 dos dos 12288 May 24 12:14 70_sc_top200.cf drwxrwxr-x 2 dos dos 4096 May 21 10:14 72_sare_bml_post25x.cf [EMAIL PROTECTED] channels]$ It's good to know there's been no updates; though I'd guessed that from the file time stamps on rulesemporium. There still seems to be a problem with RDJ though. It looks like it's pulling an entire page not just rules; I can't see any other reason for the table etc elements in the debug. I'm still curious as to why so many stock spam are getting through (so many being relative to normal). On the surface they don't look any different from those that have been caught for ages. Samples available if required. Kind regards Nigel
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Thu, 21 Jun 2007 09:38:03 +0200, Matthias Keller [EMAIL PROTECTED] wrote: Nigel Frankcom wrote: On Thu, 21 Jun 2007 03:07:52 -0400, Phil Barnett [EMAIL PROTECTED] wrote: Is anyone else getting these failed messages on their tripwire.cf updates? I've been getting this message for several days now. It looks to me like the new tripwire.cf is very broken. -- Forwarded Message -- Subject: RulesDuJour Run Summary on taz5.fiberhosting.net Date: Thursday 21 June 2007 02:26 From: To: RulesDuJour Run Summary on taz5.fiberhosting.net: TripWire has changed on taz5.fiberhosting.net. Version line: ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf /usr/share/spamassassin/RulesDuJour/99_ --- FVGT_Tripwire.cf.2; mv -f /usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225 /usr/share/spamassassin/tripwire.cf; Lint output: [24363] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [24363] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues detected, please rerun with debug enabled for more information I've been getting the same for weeks. I ended up manually updating rules; especially the stock one since more and more seem to be slipping through. The problems seemed to start after the DDoS on rulesemporium; since then I've not been able to get any sense out of it via RDJ. When I manually update it all lint's clean. Time consuming but it works Just try to delete the downloaded files in your rules_du_jour folder (for example /etc/mail/spamassassin/rules_du_jour/* ), respectively just the rule(s) that go wrong.I then redownloads the rules correctly and you're clear to go with RDJ again Matt Give that man a cigar! Seemed to work OK. Thanks Matt. Kind regards Nigel
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Thursday 21 June 2007 03:38, Matthias Keller wrote: Just try to delete the downloaded files in your rules_du_jour folder (for example /etc/mail/spamassassin/rules_du_jour/* ), respectively just the rule(s) that go wrong.I then redownloads the rules correctly and you're clear to go with RDJ again Did that two days ago. And everything came in fine and worked. I linted it then and tonight and the current ruleset lints fine. The error messages are from the RDJ script pulling in a new file. It does look like the RDJ script is pulling the wrong file because the lint error shows html tags and there aren't any in my current tripwire.cf file. If it is true that there are no updates, then why is the RDJ script trying to update anything? Is the RDJ server still being DOS'd? -- Phil Barnett AI4OF SKCC #600
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Phil Barnett wrote: On Thursday 21 June 2007 03:38, Matthias Keller wrote: Just try to delete the downloaded files in your rules_du_jour folder (for example /etc/mail/spamassassin/rules_du_jour/* ), respectively just the rule(s) that go wrong.I then redownloads the rules correctly and you're clear to go with RDJ again Did that two days ago. And everything came in fine and worked. I linted it then and tonight and the current ruleset lints fine. The error messages are from the RDJ script pulling in a new file. It does look like the RDJ script is pulling the wrong file because the lint error shows html tags and there aren't any in my current tripwire.cf file. If it is true that there are no updates, then why is the RDJ script trying to update anything? Is the RDJ server still being DOS'd The Problem occurs because RDJ once fetched a page which wasn't the rules but a HTML page. Now the config didn't lint anymore but RDJ doesn't delete the offending page but assumes, that the page will be updated soon to fix the lint error. The downloaded HTML page now has a current timestamp and since the real .cf file is older and there hasn't been an update since, the newer HTML page is kept and fails to lint every time until you manually delete it (and the actual .cf gets redownloaded) or a new version of the .cf is uploaded... RDJ ONLY redownloads a rule from the server IF it has been modified since the timestamp of the local file... If RDJ would delete failing files, it would solve that problem but lead to more traffic to the server, especially when ddoses happen, because everyone would try to redownload all the pages all the times Matt
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Phil Barnett schrieb:
On Thursday 21 June 2007 03:38, Matthias Keller wrote:
Just try to delete the downloaded files in your rules_du_jour folder
(for example /etc/mail/spamassassin/rules_du_jour/* ), respectively just
the rule(s) that go wrong.I then redownloads the rules correctly and
you're clear to go with RDJ again
Did that two days ago. And everything came in fine and worked. I linted it
then and tonight and the current ruleset lints fine.
The error messages are from the RDJ script pulling in a new file. It does look
like the RDJ script is pulling the wrong file because the lint error shows
html tags and there aren't any in my current tripwire.cf file.
If it is true that there are no updates, then why is the RDJ script trying to
update anything? Is the RDJ server still being DOS'd?
This (see post new patch for rules_du_jour ... (Lindsay
Haisley)/18.06.2007) works fine here.
But you probably have to delete the faulty .cf files manually.
cut here
--- /root/rules_du_jour.orig2007-06-17 21:01:24.0 -0500
+++ /var/lib/spamassassin/rules_du_jour 2007-06-18 12:37:44.0 -0500
@@ -907,6 +907,8 @@
[ ${SEND_THE_EMAIL} ] echo -e ${MESSAGES} | sh -c ${MAILCMD} -s
\RulesDuJour Run Summary on ${HOSTNAME}\ ${MAIL_ADDRESS};
fi
+grep -il 'META HTTP-EQUIV' ${TMPDIR}/*|xargs -n1 rm -f
+
cd ${OLDDIR};
exit;
cut here
--
Grüsse/Greetings
MH
Dont send mail to: [EMAIL PROTECTED]
--
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Unless something has changed with the most recent versions of SpamAssassin
I see two configuraton errors present.
1) YOu do NOT use /use/share/spamassassin to store rules. They belong
in /etc/mail/spamassassin or some other such place.
2) Why are you running tripwire.cf (obsolete) and 99_FGTTripWire.cf at
the same time?
(Note that I do NOT use RulesDuJour here. I have my own script for
handling updates. It's a ridiculously simple bash script that I can
read. {^_-} So maybe using /usr/share/spamassassin is some form of
silly RDJ action. That is a directory that is utterly wiped out with
each upgrade of SpamAssassin, though. So anything in it gets lost.)
{^_^}
- Original Message -
From: Nigel Frankcom [EMAIL PROTECTED]
On Thu, 21 Jun 2007 03:07:52 -0400, Phil Barnett [EMAIL PROTECTED]
wrote:
Is anyone else getting these failed messages on their tripwire.cf updates?
I've been getting this message for several days now.
It looks to me like the new tripwire.cf is very broken.
-- Forwarded Message --
Subject: RulesDuJour Run Summary on taz5.fiberhosting.net
Date: Thursday 21 June 2007 02:26
From:
To:
RulesDuJour Run Summary on taz5.fiberhosting.net:
TripWire has changed on taz5.fiberhosting.net.
Version line:
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /usr/share/spamassassin/tripwire.cf
/usr/share/spamassassin/RulesDuJour/99_
---
FVGT_Tripwire.cf.2; mv -f
/usr/share/spamassassin/RulesDuJour/tripwire.cf.20070621-0225
/usr/share/spamassassin/tripwire.cf;
Lint output: [24363] warn: config: failed to parse line, skipping:
HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [24363] warn:
config:
failed to parse line, skipping: META HTTP-EQUIV=Pragma
CONTENT=no-cache [24363] warn: config: failed to parse line, skipping:
META HTTP-EQUIV=Expires CONTENT=-1 [24363] warn: config: failed to
parse line, skipping: /HEAD/HTML [24363] warn: lint: 4 issues
detected,
please rerun with debug enabled for more information
I've been getting the same for weeks. I ended up manually updating
rules; especially the stock one since more and more seem to be
slipping through.
The problems seemed to start after the DDoS on rulesemporium; since
then I've not been able to get any sense out of it via RDJ.
When I manually update it all lint's clean. Time consuming but it
works
Hope that helps
Nigel
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Daryl, note that a simple update to RDJ to add a time gap between
individual file update attempts gets through the DDoS protection
somewhat better than a raw RDJ. A friend of mine made such a change
and has it working better.
{^_^}
- Original Message -
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Nigel Frankcom wrote:
I've been getting the same for weeks. I ended up manually updating
rules; especially the stock one since more and more seem to be
slipping through.
The problems seemed to start after the DDoS on rulesemporium; since
then I've not been able to get any sense out of it via RDJ.
When I manually update it all lint's clean. Time consuming but it
works
Note that there haven't been any updates to 70_sare_stocks.cf since May
7th and no updates at all since June 5th, so manual updates probably
aren't worth the bother.
Daryl
[EMAIL PROTECTED] channels]$ ls -l | grep -P May|Jun
drwxrwxr-x 2 dos dos 4096 May 21 10:14 70_sare_adult.cf
drwxrwxr-x 2 dos dos 4096 Jun 5 11:14 70_sare_obfu.cf
drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu0.cf
drwxrwxr-x 2 dos dos 4096 Jun 4 21:14 70_sare_obfu1.cf
drwxrwxr-x 2 dos dos 4096 May 7 00:24 70_sare_stocks.cf
drwxrwxr-x 2 dos dos 12288 May 24 12:14 70_sc_top200.cf
drwxrwxr-x 2 dos dos 4096 May 21 10:14 72_sare_bml_post25x.cf
[EMAIL PROTECTED] channels]$
RE: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
-Original Message-
From: jdow [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 7:50 AM
To: users@spamassassin.apache.org
Subject: Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
Daryl, note that a simple update to RDJ to add a time gap
between individual file update attempts gets through the DDoS
protection somewhat better than a raw RDJ. A friend of mine
made such a change and has it working better.
I have been getting these same messages as Daryl since the DDoS attack
on rulesemporium also. I am not so good with all of this though. Could
you please explain in more detail what you mean by this statement? What
do you mean by adding a time gap? Perhaps I am asking an obvious
question but I am afraid your statement is not obvious to me.
Thanks,
Steve
{^_^}
- Original Message -
From: Daryl C. W. O'Shea [EMAIL PROTECTED]
Nigel Frankcom wrote:
I've been getting the same for weeks. I ended up manually updating
rules; especially the stock one since more and more seem to be
slipping through.
The problems seemed to start after the DDoS on
rulesemporium; since
then I've not been able to get any sense out of it via RDJ.
When I manually update it all lint's clean. Time consuming but it
works
Note that there haven't been any updates to 70_sare_stocks.cf since
May
7th and no updates at all since June 5th, so manual updates
probably
aren't worth the bother.
Daryl
[EMAIL PROTECTED] channels]$ ls -l | grep -P May|Jun
drwxrwxr-x 2 dos dos 4096 May 21 10:14 70_sare_adult.cf
drwxrwxr-x
2 dos dos 4096 Jun 5 11:14 70_sare_obfu.cf drwxrwxr-x 2 dos dos
4096 Jun 4 21:14 70_sare_obfu0.cf drwxrwxr-x 2 dos dos
4096 Jun 4
21:14 70_sare_obfu1.cf drwxrwxr-x 2 dos dos 4096 May 7 00:24
70_sare_stocks.cf drwxrwxr-x 2 dos dos 12288 May 24 12:14
70_sc_top200.cf drwxrwxr-x 2 dos dos 4096 May 21 10:14
72_sare_bml_post25x.cf [EMAIL PROTECTED] channels]$
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Thursday 21 June 2007 08:47, jdow wrote: Unless something has changed with the most recent versions of SpamAssassin I see two configuraton errors present. 1) YOu do NOT use /use/share/spamassassin to store rules. They belong in /etc/mail/spamassassin or some other such place. This is a configurable option in SA, so you can put it anywhere you want. Why the people at Plesk decided to put it there is beyond me, but it works, so I'm leaving it alone. Also, /usr/share/spamassassin may be wiped out on each upgrade, but /usr/share/spamassassin/rulesdujour is not, and the next run of RDJ repopulates the former. 2) Why are you running tripwire.cf (obsolete) and 99_FGTTripWire.cf at the same time? When RDJ downloads 99FGTTripWire.cf, it renames it to tripwire.cf when it moves it. I had no idea that tripwire was obsolete. Where is this information distributed? -- Phil Barnett AI4OF SKCC #600
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
From: Phil Barnett [EMAIL PROTECTED]
On Thursday 21 June 2007 08:47, jdow wrote:
Unless something has changed with the most recent versions of SpamAssassin
I see two configuraton errors present.
1) YOu do NOT use /use/share/spamassassin to store rules. They belong
in /etc/mail/spamassassin or some other such place.
This is a configurable option in SA, so you can put it anywhere you want.
Why
the people at Plesk decided to put it there is beyond me, but it works, so
I'm leaving it alone.
Also, /usr/share/spamassassin may be wiped out on each upgrade,
but /usr/share/spamassassin/rulesdujour is not, and the next run of RDJ
repopulates the former.
2) Why are you running tripwire.cf (obsolete) and 99_FGTTripWire.cf at
the same time?
When RDJ downloads 99FGTTripWire.cf, it renames it to tripwire.cf when it
moves it.
I had no idea that tripwire was obsolete. Where is this information
distributed?
I think it was mentioned around these precincts about the time tripwire
was converted to 99_FVGTTripWire.cf and added to the SARE repositories
as a SARE rule set. I also note that I don't use it here anymore. The
return on CPU cycles investment was not sufficient to run that set
anymore.
{^_^}
Re: Fwd: RulesDuJour Run Summary on taz5.fiberhosting.net
On Friday 22 June 2007 00:54, jdow wrote: I think it was mentioned around these precincts about the time tripwire was converted to 99_FVGTTripWire.cf and added to the SARE repositories as a SARE rule set. I also note that I don't use it here anymore. The return on CPU cycles investment was not sufficient to run that set anymore. When I'm looking for a place to shed load, I'll remember. Right now, this is a quad processor box, so I'll take all the rules I can get. We have a pretty good spam marking rate right now. Not many things hit tripwire, but all the ones that do are spam, so I find it useful to drive the score up. -- Phil Barnett AI4OF SKCC #600
[OT] RDJ RulesDuJour Updates dont lint
Hello! Any tipps:? ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf /etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/tripwire.cf.20070613-0836 /etc/mail/spamassassin/tripwire.cf; mv -f /etc/mail/spamassassin/blacklist.cf /etc/mail/spamassassin/RulesDuJour/sa-blacklist.current.2; mv -f /etc/mail/spamassassin/RulesDuJour/blacklist.cf.20070613-0836 /etc/mail/spamassassin/blacklist.cf; mv -f /etc/mail/spamassassin/blacklist-uri.cf /etc/mail/spamassassin/RulesDuJour/sa-blacklist.current.uri.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/blacklist-uri.cf.20070613-0836 /etc/mail/spamassassin/blacklist-uri.cf; mv -f /etc/mail/spamassassin/70_sc_top200.cf /etc/mail/spamassassin/RulesDuJour/70_sc_top200.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/70_sc_top200.cf.20070613-0836 /etc/mail/spamassassin/70_sc_top200.cf; mv -f /etc/mail/spamassassin/70_sare_genlsubj.cf /etc/mail/spamassassin/RulesDuJour/70_sare_genlsubj.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/70_sare_genlsubj.cf.20070613-0836 /etc/mail/spamassassin/70_sare_genlsubj.cf; mv -f /etc/mail/spamassassin/70_sare_uri3.cf /etc/mail/spamassassin/RulesDuJour/70_sare_uri3.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/70_sare_uri3.cf.20070613-0837 /etc/mail/spamassassin/70_sare_uri3.cf; Lint output: [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0SCRIPT Language=JavaScriptvar coupon1= 268980629;var coupon2= 304354668;var style1= 519728833;var style2= 192774663;var add = coupon1+coupon2+style1+style2;document.cookie=NSC_DOSP=+add+;path=/;window.location=window.location.href;window.focus();/SCRIPT/HEAD/HTML [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0SCRIPT Language=JavaScriptvar coupon1= 268980629;var coupon2= 304354668;var style1= 519728833;var style2= 192774663;var add = coupon1+coupon2+style1+style2;document.cookie=NSC_DOSP=+add+;path=/;window.location=window.location.href;window.focus();/SCRIPT/HEAD/HTML [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0SCRIPT Language=JavaScriptvar coupon1= 268980629;var coupon2= 304354668;var style1= 519728833;var style2= 192774663;var add = coupon1+coupon2+style1+style2;document.cookie=NSC_DOSP=+add+;path=/;window.location=window.location.href;window.focus();/SCRIPT/HEAD/HTML [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0.1 [18730] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Pragma CONTENT=no-cache [18730] warn: config: failed to parse line, skipping: META HTTP-EQUIV=Expires CONTENT=-1 [18730] warn: config: failed to parse line, skipping: /HEAD/HTML [18730] warn: lint: 7 issues detected, please rerun with debug enabled for more information -- Thx for your help! MH Dont send mail to: [EMAIL PROTECTED] --
Re: [OT] RDJ RulesDuJour Updates dont lint
Hi! /etc/mail/spamassassin/tripwire.cf; mv -f /etc/mail/spamassassin/blacklist.cf /etc/mail/spamassassin/RulesDuJour/sa-blacklist.current.2; mv -f /etc/mail/spamassassin/RulesDuJour/blacklist.cf.20070613-0836 /etc/mail/spamassassin/blacklist.cf; mv -f coupon1+coupon2+style1+style2;document.cookie=NSC_DOSP=+add+;path=/;window.location=window.location.href;window.focus();/SCRIPT/HEAD/HTML [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0SCRIPT Language=JavaScriptvar coupon1= What about you check the content of those files first before mailing the list? Seems you have broken files, eg, HTML errors inside them. Pretty obvious. Bye, Raymond.
Re: [OT] RDJ RulesDuJour Updates dont lint
On Wed, 13 Jun 2007, Raymond Dijkxhoorn wrote: coupon1+coupon2+style1+style2;document.cookie=NSC_DOSP=+add+;path=/;window.location=window.location.href;window.focus();/SCRIPT/HEAD/HTML [18730] warn: config: failed to parse line, skipping: HTMLHEADMETA HTTP-EQUIV=Refresh CONTENT=0SCRIPT Language=JavaScriptvar coupon1= What about you check the content of those files first before mailing the list? Seems you have broken files, eg, HTML errors inside them. Pretty obvious. In the words of Inigo Montoya, I do not think [that word] means what you think it means. While the errors do contain HTML tags, I wouldn't exactly call them obvious, especially given all the javascript and a context where HTML is unexpected. In any case, I've found that it's sometimes better to just let it go and allow someone else respond to questions you find irritating and unnecessary. Matthias, if you look through recent list posts, you'll find that RDJ has been causing lots of people trouble due to the fact that certain rule channels have been unavailable. -- Public key #7BBC68D9 at| Shane Williams http://pgp.mit.edu/| System Admin - UT iSchool =--+--- All syllogisms contain three lines | [EMAIL PROTECTED] Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew
Re: Rulesdujour?
Matt Kettler writes: 2) Antidrug is a part of SA as of SA 3.0.0. If you're using antidrug with SA 3.0.0 or higher, you're possibly downgrading your antidrug rules. Unless you're using SA 2.64 or lower, you should remove antidrug.cf from your system completely. 3) If I ever make updates to the antidrug rules, I'd submit them to the main SA project to avoid conflicts. I will likely NOT update antidrug.cf. (anyone using 2.64 or older would get a much bigger boost in accuracy from updating SA than they will from updating my rules.) Maybe we need a way to indicate precedence -- ie. rule XXX replaces rule YYY, so ignore that rule if it's in the ruleset? --j.
lint test failed after rulesdujour update
Hi, I am new to spamassassin so sorry if my question is a bit stupid. I have mail spamassassin 3.1.0 running with mailscanner. It updates it self via RulesDuJour on a regular basis and I get an email which informs me of the update. This morning I noticed that there was a error in the process, I received a second email which contained the following plus a traceback that mentioned missing operators. **WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/antidrug.cf /etc/spamassassin/RulesDuJour/antidrug.cf.2; mv -f /etc/spamassassin/RulesDuJour/antidrug.cf.20070125-0029 /etc/spamassassin/antidrug.cf; I couldnt rollback because the file antidrug.cf.20070125-0029 did not exist so I decided to run spamassassin --lint at the command line myself expecting the same error but instead it ran ok, I sent the spamassassin test email to myself and it was caught so everything seems to be working as expected, however I would really like to know why the above error was thrown. Regards, Michael
Re: lint test failed after rulesdujour update
On Thursday 25 January 2007 6:33 am, Michael Connors wrote: Hi, I am new to spamassassin so sorry if my question is a bit stupid. I have mail spamassassin 3.1.0 running with mailscanner. It updates it self via RulesDuJour on a regular basis and I get an email which informs me of the update. This morning I noticed that there was a error in the process, I received a second email which contained the following plus a traceback that mentioned missing operators. **WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/antidrug.cf /etc/spamassassin/RulesDuJour/antidrug.cf.2; mv -f /etc/spamassassin/RulesDuJour/antidrug.cf.20070125-0029 /etc/spamassassin/antidrug.cf; I couldnt rollback because the file antidrug.cf.20070125-0029 did not exist so I decided to run spamassassin --lint at the command line myself expecting the same error but instead it ran ok, I sent the spamassassin test email to myself and it was caught so everything seems to be working as expected, however I would really like to know why the above error was thrown. Regards, Michael The creator of antidrug posted a thorugh explanation of the where and when regarding this rule (see marc.theaimsgroup.com/?l=spamassassin-usersm=116965442518029w=2). Without trying to sound holier-than-thou (lord knows, I'm the last one that should cop that attitude), you should search the archives first. That said, a precis of Matt Kettler's post: 1. The location of antidrug.cf has moved, and; 2. It's included in SA 3+ and, in fact, can be counter-productive if used in combination with same. HTH. Dimitri -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: lint test failed after rulesdujour update
Dimitri Yioulos wrote: On Thursday 25 January 2007 6:33 am, Michael Connors wrote: Hi, I am new to spamassassin so sorry if my question is a bit stupid. I have mail spamassassin 3.1.0 running with mailscanner. It updates it self via RulesDuJour on a regular basis and I get an email which informs me of the update. This morning I noticed that there was a error in the process, I received a second email which contained the following plus a traceback that mentioned missing operators. **WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/antidrug.cf /etc/spamassassin/RulesDuJour/antidrug.cf.2; mv -f /etc/spamassassin/RulesDuJour/antidrug.cf.20070125-0029 /etc/spamassassin/antidrug.cf; I couldnt rollback because the file antidrug.cf.20070125-0029 did not exist so I decided to run spamassassin --lint at the command line myself expecting the same error but instead it ran ok, I sent the spamassassin test email to myself and it was caught so everything seems to be working as expected, however I would really like to know why the above error was thrown. Regards, Michael The creator of antidrug posted a thorugh explanation of the where and when regarding this rule (see marc.theaimsgroup.com/?l=spamassassin-usersm=116965442518029w=2). Without trying to sound holier-than-thou (lord knows, I'm the last one that should cop that attitude), you should search the archives first. That said, a precis of Matt Kettler's post: 1. The location of antidrug.cf has moved, and; 2. It's included in SA 3+ and, in fact, can be counter-productive if used in combination with same. HTH. Dimitri Thank you Dimitri. I'd also add: 3) I've posted the error-generating file as a last-resort to draw people's attention to the fact they need to change their RDJ before someone else, possibly malicious, has control of my old account. A malicious person could post a replacement file that whitelists spam.
Re: lint test failed after rulesdujour update
On Thursday 25 January 2007 10:10 am, Matt Kettler wrote: Dimitri Yioulos wrote: On Thursday 25 January 2007 6:33 am, Michael Connors wrote: Hi, I am new to spamassassin so sorry if my question is a bit stupid. I have mail spamassassin 3.1.0 running with mailscanner. It updates it self via RulesDuJour on a regular basis and I get an email which informs me of the update. This morning I noticed that there was a error in the process, I received a second email which contained the following plus a traceback that mentioned missing operators. **WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/spamassassin/antidrug.cf /etc/spamassassin/RulesDuJour/antidrug.cf.2; mv -f /etc/spamassassin/RulesDuJour/antidrug.cf.20070125-0029 /etc/spamassassin/antidrug.cf; I couldnt rollback because the file antidrug.cf.20070125-0029 did not exist so I decided to run spamassassin --lint at the command line myself expecting the same error but instead it ran ok, I sent the spamassassin test email to myself and it was caught so everything seems to be working as expected, however I would really like to know why the above error was thrown. Regards, Michael The creator of antidrug posted a thorugh explanation of the where and when regarding this rule (see marc.theaimsgroup.com/?l=spamassassin-usersm=116965442518029w=2). Without trying to sound holier-than-thou (lord knows, I'm the last one that should cop that attitude), you should search the archives first. That said, a precis of Matt Kettler's post: 1. The location of antidrug.cf has moved, and; 2. It's included in SA 3+ and, in fact, can be counter-productive if used in combination with same. HTH. Dimitri Thank you Dimitri. I'd also add: 3) I've posted the error-generating file as a last-resort to draw people's attention to the fact they need to change their RDJ before someone else, possibly malicious, has control of my old account. A malicious person could post a replacement file that whitelists spam. Matt, Thanks for completing the info. Hence my holier-than-thou disclaimer. Dimitri -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Rulesdujour?
Greetings; I got this email from Rules_Du_Jour this morning, what is the fix? Thu Jan 25 05:59:52 2007 ***WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. Rollback command is: mv -f /etc/mail/spamassassin/antidrug.cf /etc/mail/spamassassin/RulesDuJour/antidrug.cf.2; mv -f /etc/mail/spamassassin/RulesDuJour/antidrug.cf.20070125-0559 /etc/mail/spamassassin/antidrug.cf; Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. [16404] warn: String found where operator expected at (eval 1122) line 1, near you are [16404] warn: (Missing operator before are?) [16404] warn: String found where operator expected at (eval 1122) line 1, near are running [16404] warn: (Missing operator before running?) [16404] warn: String found where operator expected at (eval 1122) line 1, near running SA [16404] warn: (Missing operator before SA?) [16404] warn: Number found where operator expected at (eval 1122) line 1, near SA 3.0.0 [16404] warn: (Missing operator before 3.0.0?) [16404] warn: String found where operator expected at (eval 1122) line 1, near 3.0.0 or [16404] warn: (Missing operator before or?) [16404] warn: String found where operator expected at (eval 1122) line 1, near or higher [16404] warn: (Missing operator before higher?) [16404] warn: String found where operator expected at (eval 1122) line 1, near higher you [16404] warn: (Missing operator before you?) [16404] warn: String found where operator expected at (eval 1122) line 1, near you already [16404] warn: (Missing operator before already?) [16404] warn: String found where operator expected at (eval 1122) line 1, near already have [16404] warn: (Missing operator before have?) [16404] warn: String found where operator expected at (eval 1122) line 1, near have antidrug [16404] warn: (Missing operator before antidrug?) [16404] warn: String found where operator expected at (eval 1122) line 1, near antidrug and [16404] warn: (Missing operator before and?) [16404] warn: String found where operator expected at (eval 1122) line 1, near and this [16404] warn: (Missing operator before this?) [16404] warn: String found where operator expected at (eval 1122) line 1, near this file [16404] warn: (Missing operator before file?) [16404] warn: config: unclosed 'if' in /etc/mail/spamassassin/antidrug.cf: if you are running SA 3.0.0 or higher, you already have antidrug and this file [16404] warn: lint: 6 issues detected, please rerun with debug enabled for more information -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
Re: Rulesdujour?
On Thu, Jan 25, 2007 at 11:50:13AM -0500, Gene Heskett wrote: I got this email from Rules_Du_Jour this morning, what is the fix? Don't take this the wrong way, but did you read the errors at all? Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. It makes it pretty clear that you should stop using it and why. -- Randomly Selected Tagline: Ask them to list all 54 flavors, then order Vanilla. pgpzEzoDNpvgw.pgp Description: PGP signature
Re: Rulesdujour?
On Thu, 25 Jan 2007 12:20:09 -0500, Gene Heskett [EMAIL PROTECTED] wrote: On Thursday 25 January 2007 11:56, Theo Van Dinter wrote: On Thu, Jan 25, 2007 at 11:50:13AM -0500, Gene Heskett wrote: I got this email from Rules_Du_Jour this morning, what is the fix? Don't take this the wrong way, but did you read the errors at all? Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. It makes it pretty clear that you should stop using it and why. Yes I did read it, but I'm not sure what rule I should remove, or if I should stop using rulesdujour. Has it fallen out of favor or was it too good for somebody? FWIW, rulesdujour, if its complaining about a package, should not only say its an out of date package, but should name it so that one can find and remove it! This message didn't arrive until after this one this morning: Matt Kettler's AntiDrug has changed on coyote.coyote.den. Version line: # rev 0.65 10/01/2006 - updated URL, etc So I assume that's the file being bitched about, so I've removed several of them in the /etc/spamassassin/rulesdujour dir, and removed the antidrug thing from /etc/rulesdujour/config. Damn I get enough of that, some of them claim I could get it up if I was 100 years old. But I'm diabetic 72, so the chances are somewhere between damned slim and none. What else is in your RDJ config? It might be worth taking a walk through the rules site and just checking what you've got and what, if any have been obfuscated. Kind regards Nigel
Re: Rulesdujour?
On Thursday 25 January 2007 11:56, Theo Van Dinter wrote: On Thu, Jan 25, 2007 at 11:50:13AM -0500, Gene Heskett wrote: I got this email from Rules_Du_Jour this morning, what is the fix? Don't take this the wrong way, but did you read the errors at all? Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. It makes it pretty clear that you should stop using it and why. Yes I did read it, but I'm not sure what rule I should remove, or if I should stop using rulesdujour. Has it fallen out of favor or was it too good for somebody? FWIW, rulesdujour, if its complaining about a package, should not only say its an out of date package, but should name it so that one can find and remove it! This message didn't arrive until after this one this morning: Matt Kettler's AntiDrug has changed on coyote.coyote.den. Version line: # rev 0.65 10/01/2006 - updated URL, etc So I assume that's the file being bitched about, so I've removed several of them in the /etc/spamassassin/rulesdujour dir, and removed the antidrug thing from /etc/rulesdujour/config. Damn I get enough of that, some of them claim I could get it up if I was 100 years old. But I'm diabetic 72, so the chances are somewhere between damned slim and none. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
Re: Rulesdujour?
On Thursday 25 January 2007 12:33, Nigel Frankcom wrote: On Thu, 25 Jan 2007 12:20:09 -0500, Gene Heskett [EMAIL PROTECTED] wrote: On Thursday 25 January 2007 11:56, Theo Van Dinter wrote: On Thu, Jan 25, 2007 at 11:50:13AM -0500, Gene Heskett wrote: I got this email from Rules_Du_Jour this morning, what is the fix? Don't take this the wrong way, but did you read the errors at all? Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. It makes it pretty clear that you should stop using it and why. Yes I did read it, but I'm not sure what rule I should remove, or if I should stop using rulesdujour. Has it fallen out of favor or was it too good for somebody? FWIW, rulesdujour, if its complaining about a package, should not only say its an out of date package, but should name it so that one can find and remove it! This message didn't arrive until after this one this morning: Matt Kettler's AntiDrug has changed on coyote.coyote.den. Version line: # rev 0.65 10/01/2006 - updated URL, etc So I assume that's the file being bitched about, so I've removed several of them in the /etc/spamassassin/rulesdujour dir, and removed the antidrug thing from /etc/rulesdujour/config. Damn I get enough of that, some of them claim I could get it up if I was 100 years old. But I'm diabetic 72, so the chances are somewhere between damned slim and none. What else is in your RDJ config? It might be worth taking a walk through the rules site and just checking what you've got and what, if any have been obfuscated. Kind regards Nigel TRUSTED_RULESETS=EVILNUMBERS EVILNUMBERS1 EVILNUMBERS2 BOGUSVIRUS SARE_ADULT SARE_BAYES_POISON_NXM SARE_BML SARE_CODING SARE_REDIRECT_POST300 SARE_GENLSUBJ SARE_UNSUB SARE_HEADER0 SARE_HEADER2 SARE_OBFU0 SARE_OBFU1 SARE_OEM SARE_RANDOM SARE_URI0 SARE_URI1 SARE_URI3 SARE_URI_ENG SARE_WHITELIST SARE_WHITELIST_SPF SARE_WHITELIST_RCVD SARE_SPECIFIC SARE_STOCKS SARE_FRAUD SARE_SPOOF ZMI_GERMAN SA_DIR=/etc/mail/spamassassin MAIL_ADDRESS=[EMAIL PROTECTED] SA_RESTART=killall -HUP spamd -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved.
Re: Rulesdujour?
Gene Heskett wrote: On Thursday 25 January 2007 11:56, Theo Van Dinter wrote: On Thu, Jan 25, 2007 at 11:50:13AM -0500, Gene Heskett wrote: I got this email from Rules_Du_Jour this morning, what is the fix? Don't take this the wrong way, but did you read the errors at all? Lint output: [16404] warn: config: failed to parse line, skipping: README: [16404] warn: config: failed to parse line, skipping: WARNING: YOU HAVE DOWNLOADED THIS RULESET from COMCAST. I am TERMINATING THIS ACCOUNT. [16404] warn: config: failed to parse line, skipping: Someone else will eventually have control of this webspace, possibly a malicious spammer. [16404] warn: config: failed to parse line, skipping: STOP using RDJ on this file *NOW* [16404] warn: config: failed to parse line, skipping: Also, make note of the fact that this file is for users of SA 2.64 and below. It makes it pretty clear that you should stop using it and why. Yes I did read it, but I'm not sure what rule I should remove, or if I should stop using rulesdujour. Has it fallen out of favor or was it too good for somebody? No, you shouldn't stop using RDJ. You should however stop using RDJ to update antidrug, for the following reasons: 1) Antidrug is no longer actively maintained. I haven't edited the rules themselves in a very long time, over a year. You've probably downloaded update since, but it's all notes in the comments. ie: don't use this with 3.0.0 or higher went in back in june or july 06. October 06 saw the ruleset updated with a comment telling you it moved (that few read). 2) Antidrug is a part of SA as of SA 3.0.0. If you're using antidrug with SA 3.0.0 or higher, you're possibly downgrading your antidrug rules. Unless you're using SA 2.64 or lower, you should remove antidrug.cf from your system completely. 3) If I ever make updates to the antidrug rules, I'd submit them to the main SA project to avoid conflicts. I will likely NOT update antidrug.cf. (anyone using 2.64 or older would get a much bigger boost in accuracy from updating SA than they will from updating my rules.) Therefore, checking Antidrug with RDJ is pointless. In fact, the current version of RDJ no longer supports antidrug at all for this very reason. So, I suggest that you take the following steps: 1) update your RDJ. Chris Thielen, the author of RDJ, has in the past pointed out that it's no longer available via exit0.us, but can be gotten here: http://sandgnat.com/rdj/rules_du_jour 2) remove antidrug.cf from your system unless your SA version is 2.64 or lower. If it is, I would SERIOUSLY consider upgrading.
RulesDuJour
The configuration that I inherited had only got TRUSTED_RULESETS=TRIPWIRE SARE_EVILNUMBERS0 SARE_RANDOM; in /etc/rulesdujour/config. This obviously allows a lot of spam to filter through (or at elaast would allow the rules to become outdated). Looking at rulesdujour.sh I notice it references a lot mor rule sets than these. What problems might I encounter if I add all of these (except for those noted as pre 3.0) to my config file? mike
Re: RulesDuJour
On 8-Dec-2006, at 01:46, Mike Kenny wrote: The configuration that I inherited had only got TRUSTED_RULESETS=TRIPWIRE SARE_EVILNUMBERS0 SARE_RANDOM; in /etc/rulesdujour/config. This obviously allows a lot of spam to filter through (or at elaast would allow the rules to become outdated). Looking at rulesdujour.sh I notice it references a lot mor rule sets than these. What problems might I encounter if I add all of these (except for those noted as pre 3.0) to my config file? Well, ALL of them would be a bit much. The drawback is that some will add some overheard, both in time and in resources, to processing messages. The more messages your mailserver gets, the more you care about that. I would look at the SARE ones and enable those that sound good to you, and see how that goes. -- You may be anti anti-spam-kook if: Despite having invented the FUSSP, you not only don't know the difference between the SMTP envelope and SMTP headers; you doubt there is such a thing as the SMTP envelope because email doesn't involve paper.
Re: RulesDuJour 1.29 - SARE Stocks Ruleset) not found (404)
Sorry about that! It's fixed now and 1.29b is available on the web site.
Max Matslofva wrote:
Hi
RulesDuJour 1.29 tries to fetch 70_sare_stocks.cf from
http://www.rulesemporium.com/rules/rules/70_sare_stocks.cf
The correct URL for 70_sare_stocks.cf is
http://www.rulesemporium.com/rules/70_sare_stocks.cf
See patch below
/Max
--- rules_du_jour Wed Dec 6 08:45:55 2006
+++ rules_du_jour.org Wed Dec 6 08:45:36 2006
@@ -565,7 +565,7 @@
PARSE_NEW_VER_SCRIPTS[69]=${PERL} -ne 'print if
/^\s*#.*(version|rev|revision)[:\.\s]*[0-9]/i ;' | ${HEAD};
SARE_STOCKS=70;
- CF_URLS[70]=${RULESEMPORIUM}/70_sare_stocks.cf;
+ CF_URLS[70]=${RULESEMPORIUM}/rules/70_sare_stocks.cf;
CF_FILES[70]=70_sare_stocks.cf;
CF_NAMES[70]=SARE Stocks Ruleset);
PARSE_NEW_VER_SCRIPTS[70]=${PERL} -ne 'print if
/^\s*#.*(version|rev|revision)[:\.\s]*[0-9]/i ;' | ${HEAD};
RulesDuJour 1.29 - SARE Stocks Ruleset) not found (404)
Hi
RulesDuJour 1.29 tries to fetch 70_sare_stocks.cf from
http://www.rulesemporium.com/rules/rules/70_sare_stocks.cf
The correct URL for 70_sare_stocks.cf is
http://www.rulesemporium.com/rules/70_sare_stocks.cf
See patch below
/Max
--- rules_du_jour Wed Dec 6 08:45:55 2006
+++ rules_du_jour.org Wed Dec 6 08:45:36 2006
@@ -565,7 +565,7 @@
PARSE_NEW_VER_SCRIPTS[69]=${PERL} -ne 'print if
/^\s*#.*(version|rev|revision)[:\.\s]*[0-9]/i ;' | ${HEAD};
SARE_STOCKS=70;
- CF_URLS[70]=${RULESEMPORIUM}/70_sare_stocks.cf;
+ CF_URLS[70]=${RULESEMPORIUM}/rules/70_sare_stocks.cf;
CF_FILES[70]=70_sare_stocks.cf;
CF_NAMES[70]=SARE Stocks Ruleset);
PARSE_NEW_VER_SCRIPTS[70]=${PERL} -ne 'print if
/^\s*#.*(version|rev|revision)[:\.\s]*[0-9]/i ;' | ${HEAD};
Rulesdujour is broken?
In another thread, I noticed that someone had a SARE ruleset for stock scams and the like. Since they had been plaguing us constantly in recent months, I decided I should get rules_du_jour to update that ruleset for us. I quickly found out that rules_du_jour was horribly out of date on our system, and that none of the rulesets had been updated in months. Okay, no matter... just update the rules_du_jour configuration file to use the most recent rulesets (http://sandgnat.com/rdj/rules_du_jour), and I should be on my way, right? Um, no. When I add nice things like SARE_STOCKS and SARE_SPAMCOP_TOP200 to the TRUSTED_RULESETS variable, it skips downloading those rules with this error message: No index found for ruleset named SARE_SPAMCOP_TOP200. Check that this ruleset is still valid. And yet, I can find that rule at http://www.rulesemporium.com/rules.htm#sc_top200. Thankfully, most of the other new rulesets I put in there work fine. Of course, the rules_du_jour website is also broken, so I can't install the latest version or anything. :(
RulesduJour How often is too often?
I have it set to go about about every six hours yet blacklist_uri always seems to have an update. Is there any reason I couldn't up it to like every four hours? Would that stress the rules servers a bit too much? How often does everyone else update?
Re: RulesduJour How often is too often?
At 07:38 AM 11/2/2006, you wrote: I have it set to go about about every six hours yet blacklist_uri always seems to have an update. Is there any reason I couldn't up it to like every four hours? Would that stress the rules servers a bit too much? How often does everyone else update? Well considering it's called rules du jour, and I seem to recall Jour is day, and the instructions say do NOT use more than once a day... I update once a day. :-D
RE: RulesduJour How often is too often?
Oops, I musta missed that part. Hmm.. Maybe I could make a copy of dujour that just looked for updates to blacklist_uri. -Original Message- From: Evan Platt [mailto:[EMAIL PROTECTED] Sent: Thursday, November 02, 2006 7:44 AM To: users@spamassassin.apache.org Subject: Re: RulesduJour How often is too often? At 07:38 AM 11/2/2006, you wrote: I have it set to go about about every six hours yet blacklist_uri always seems to have an update. Is there any reason I couldn't up it to like every four hours? Would that stress the rules servers a bit too much? How often does everyone else update? Well considering it's called rules du jour, and I seem to recall Jour is day, and the instructions say do NOT use more than once a day... I update once a day. :-D
R: RulesduJour How often is too often?
I have it set to go about about every six hours yet blacklist_uri always seems to have an update. Is there any reason I couldn't up it to like every four hours? Would that stress the rules servers a bit too much? How often does everyone else update? /ME: Once per day. Also note that there are 1-3 updates per month and that, in example, SARE rules are mainly meant to discover a wide range of spam flavors. They seldom ship rules for specific threats. A daily update is going to be really enough, I guess. --- Giampaolo Tomassoni - IT Consultant Piazza VIII Aprile 1948, 4 I-53044 Chiusi (SI) - Italy Ph: +39-0578-21100 MAI inviare una e-mail a: NEVER send an e-mail to: [EMAIL PROTECTED]
What has happened to RulesDuJour?
If I go to the RulesDuJour site (http://www.exit0.us/index.php?pagename=RulesDuJour), I get: Object not found! The requested URL was not found on this server. The link on the referring page seems to be wrong or outdated. Please inform the author of that page about the error. If you think this is a server error, please contact the webmaster Error 404 www.exit0.us Tue 31 Oct 2006 03:48:05 PM EST Apache What is going on here? Has the site moved?
problem in updating the spam database with rulesdujour
hey friends, I am using spamassassin 3.1.3 on Fc3 along with postfix + mailscanner. I have configured rulesdujour to download latest spam rules. When I tried to ran the rulesdujour script I got the following errors at the end. Lint output: [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] [6769] warn: lint: 66 issues detected, please rerun with debug enabled for more information there are many lines with the same error I am omitting those lines to keep this mail short **WARNING***: spamassassin --lint failed. Rolling configuration files back, not restarting SpamAssassin. I ran spamassassin in debug mode spamassassin -D --lint [7957] dbg: config: read file /etc/mail/spamassassin/tripwire.cf [7957] dbg: config: using /root/.spamassassin for user state dir [7957] dbg: config: using /root/.spamassassin/user_prefs for user prefs file [7957] dbg: config: read file /root/.spamassassin/user_prefs [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9c0afb8) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::Hashcash from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::Hashcash=HASH(0x9c1c2b0) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::SPF=HASH(0x9c4d27c) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::Pyzor from @INC [7957] dbg: pyzor: network tests on, attempting Pyzor [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::Pyzor=HASH(0x9c4ff00) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::SpamCop from @INC [7957] dbg: reporter: network tests on, attempting SpamCop [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::SpamCop=HASH(0x9c2b8b4) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::AWL from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::AWL=HASH(0x9cd44f0) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::AutoLearnThreshold from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::AutoLearnThreshold=HASH(0x9ce1ebc) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::WhiteListSubject from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::WhiteListSubject=HASH(0x9ceb774) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::MIMEHeader from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::MIMEHeader=HASH(0x9cf5924) [7957] dbg: plugin: loading Mail::SpamAssassin::Plugin::ReplaceTags from @INC [7957] dbg: plugin: registered Mail::SpamAssassin::Plugin::ReplaceTags=HASH(0x9cee358) [7957] dbg: plugin: fixed relative path: /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_adult.cf [7957] dbg: config: using /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_adult.cf for included file [7957] dbg: config: read file /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_adult.cf [7957] dbg: plugin: fixed relative path: /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_bayes_poison_nxm.cf [7957] dbg: config: using /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_bayes_poison_nxm.cf for included file [7957] dbg: config: read file /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_bayes_poison_nxm.cf [7957] dbg: plugin: fixed relative path: /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum0.cf [7957] dbg: config: using /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum0.cf for included file [7957] dbg: config: read file /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum0.cf [7957] dbg: plugin: fixed relative path: /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum1.cf [7957] dbg: config: using /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum1.cf for included file [7957] dbg: config: read file /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_evilnum1.cf [7957] dbg: plugin: fixed relative path: /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_genlsubj0.cf [7957] dbg: config: using /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_genlsubj0.cf for included file [7957] dbg: config: read file /var/lib/spamassassin/3.001003/saupdates_openprotect_com/70_sare_genlsubj0.cf [7957] dbg: plugin: fixed relative path: /var/lib
Re: problem in updating the spam database with rulesdujour
ankush grover, 30.10.2006 13:04: hey friends, I am using spamassassin 3.1.3 on Fc3 along with postfix + mailscanner. I have configured rulesdujour to download latest spam rules. When I tried to ran the rulesdujour script I got the following errors at the end. Lint output: [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] [6769] warn: config: failed to parse line, skipping: AUTOBAN: Over 500 *.cf requests in 48 hours period - Check your CRON [6769] warn: config: failed to parse line, skipping: CONTACT: [EMAIL PROTECTED] Have you checked your cron like the error suggests? Seems you are flooding the servers. How often is rdj ran? Have you 'tested' a lot? -- Cheers Vidar Tyldum Hansen
Re: problem in updating the spam database with rulesdujour
Have you checked your cron like the error suggests? Seems you are flooding the servers. How often is rdj ran? Have you 'tested' a lot? -- hey, Actullay other admin set the wrong crontab . Yes the script has ran atleast 5 times a day before I posted this problem I have disable the script for 1 day. Hopefully things will cool down. Ankush Grover
Re: sa-update versus rulesdujour questions
Jo Rhett wrote: Is there any difference here that I'm overlooking? Any advantage to RDJ? And leading to my next point, given that sa-update is working fine -- isn't rdj going to be slimmed down to just the part that restarts the process after running sa-update? Hi Jo, I'm the author of RDJ. I wrote it for the purpose of updating the then blossoming field of 3rd party rulesets at a time when there was no official update mechanism in SA. Now that there/ is/ an official SA update mechanism, I have no plans to further enhance RDJ. I will continue to fix bugs and add rulesets to the default list, if people request so. There will be no slimming-down since I see no reason to surprise 5000 users by making them change what works fine for them now :). The discussion of pros and cons for implementing sa-update or rdj has already been handled nicely by other people, so I won't go into that. Want my advice as the RDJ author? Use sa-update. If you want to update a ruleset which has no sa-update channel then set up RDJ at that time and use it conjunction with sa-update. Chris T. PS sorry I got into this conversation so late. I tend to track my mailing lists infrequently
Re: sa-update versus rulesdujour questions
Theo Van Dinter wrote: FWIW, it happens to be the official tool since no one ever submitted RDJ to be the official tool, so we had to write our own. I would have offered, had I known there was any interest. Chris T.
RE: sa-update versus rulesdujour questions
Theo Van Dinter wrote: FWIW, it happens to be the official tool since no one ever submitted RDJ to be the official tool, so we had to write our own. I would have offered, had I known there was any interest. Chris T. I'm glad it isn't the official tool since it doesn't run natively on Windows. Sa_update does. Bret
