Re: [auto] bad sandbox rules report
On Wed, May 05, 2021 at 04:24:01PM +0300, Henrik K wrote:
> On Wed, May 05, 2021 at 09:01:15AM -0400, Bill Cole wrote:
> > On 2021-05-05 at 04:30:14 UTC-0400 (Wed, 5 May 2021 08:30:14 + (UTC))
> > Rules Report Cron
> > is rumored to have said:
> >
> > > HTTP get: https://ruleqa.spamassassin.org/1-days-ago?xml=1
> > > HTTP get: https://ruleqa.spamassassin.org/2-days-ago?xml=1
> > > HTTP get: https://ruleqa.spamassassin.org/3-days-ago?xml=1
> > > Invalid \0 character in pathname for ftdir:
> > > rulesrc/core\0rulesrc/sandbox at lib/Mail/SpamAssassin.pm line 2010.
> >
> > That seems BAD but I do not understand what's causing it.
>
> Ughh.. some kludgy solution of passing multiple paths into single config
> variable.
>
> build/mkupdates/listpromotable:site_rules_filename => join("\000", qw(
> rulesrc/core rulesrc/sandbox )),
> masses/rule-qa/list-bad-rules:site_rules_filename => join("\000", qw(
> rulesrc/core rulesrc/sandbox )),
>
> Just gonna go with the flow, fixed SpamAssassin.pm..
Though it seems rulesrc/core does not exist anywhere, probably some legacy
thing? Will check further and perhaps eliminate all crappy \0 code..
Re: [auto] bad sandbox rules report
On Wed, May 05, 2021 at 09:01:15AM -0400, Bill Cole wrote:
> On 2021-05-05 at 04:30:14 UTC-0400 (Wed, 5 May 2021 08:30:14 + (UTC))
> Rules Report Cron
> is rumored to have said:
>
> > HTTP get: https://ruleqa.spamassassin.org/1-days-ago?xml=1
> > HTTP get: https://ruleqa.spamassassin.org/2-days-ago?xml=1
> > HTTP get: https://ruleqa.spamassassin.org/3-days-ago?xml=1
> > Invalid \0 character in pathname for ftdir:
> > rulesrc/core\0rulesrc/sandbox at lib/Mail/SpamAssassin.pm line 2010.
>
> That seems BAD but I do not understand what's causing it.
Ughh.. some kludgy solution of passing multiple paths into single config
variable.
build/mkupdates/listpromotable:site_rules_filename => join("\000", qw(
rulesrc/core rulesrc/sandbox )),
masses/rule-qa/list-bad-rules:site_rules_filename => join("\000", qw(
rulesrc/core rulesrc/sandbox )),
Just gonna go with the flow, fixed SpamAssassin.pm..
Re: [auto] bad sandbox rules report
On 2021-05-05 at 04:30:14 UTC-0400 (Wed, 5 May 2021 08:30:14 + (UTC)) Rules Report Cron is rumored to have said: HTTP get: https://ruleqa.spamassassin.org/1-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/2-days-ago?xml=1 HTTP get: https://ruleqa.spamassassin.org/3-days-ago?xml=1 Invalid \0 character in pathname for ftdir: rulesrc/core\0rulesrc/sandbox at lib/Mail/SpamAssassin.pm line 2010. That seems BAD but I do not understand what's causing it. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: [auto] bad sandbox rules report
Guys, I'm disabling 0 hit/non perfomers/abandoned rules in hstern's sandbox. make test spit out: STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent If your rules depend on sandbox rules which are not in your own, PLEASE always copy these rules to your own sandbox. This will avoid suprises in the future. We're masschecking lots of ancient bloat. Thanks for your help in cleaning up this mess Axb
Re: [auto] bad sandbox rules report
On 03/06/2013 10:19 AM, Axb wrote: Guys, I'm disabling 0 hit/non perfomers/abandoned rules in hstern's sandbox. make test spit out: STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_SUBJ_RE_FW which is nonexistent STOX_REPLY_TYPE_WITHOUT_QUOTES depends on __HS_QUOTE which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent FROM_12LTRDOM depends on __HS_SUBJ_RE_FW which is nonexistent RISK_FREE depends on __HS_SUBJ_RE_FW which is nonexistent T_MIME_NO_TEXT depends on __HS_SUBJ_RE_FW which is nonexistent If your rules depend on sandbox rules which are not in your own, PLEASE always copy these rules to your own sandbox. This will avoid suprises in the future. We're masschecking lots of ancient bloat. Thanks for your help in cleaning up this mess I've copied the dependencies to jm and jhardin sandboxes. Suggest you rename them so they're unique to your rules and/or put them in a commitername_dependencies.cf file
Re: [auto] bad sandbox rules report
On 3/6/2013 4:54 AM, Axb wrote: I've copied the dependencies to jm and jhardin sandboxes. Suggest you rename them so they're unique to your rules and/or put them in a commitername_dependencies.cf file I like getting rid of the rules that aren't working. But this copying rules in sandbox concerns me since sandboxes are really a gateway to final that copying rules is inefficient. Doesn't the dependency show up and you can edit to leave the original rule?
Re: [auto] bad sandbox rules report
On 03/06/2013 11:55 AM, Kevin A. McGrail wrote: On 3/6/2013 4:54 AM, Axb wrote: I've copied the dependencies to jm and jhardin sandboxes. Suggest you rename them so they're unique to your rules and/or put them in a commitername_dependencies.cf file I like getting rid of the rules that aren't working. But this copying rules in sandbox concerns me since sandboxes are really a gateway to final that copying rules is inefficient. Doesn't the dependency show up and you can edit to leave the original rule? It would be neater and safer practice not to depend on somebody elses sandbox rules. What if you remove one of your rule files as because you consider them to be old, bad, useless, ugly ? are YOU responsible for your neighbour's broken metasa? AND if the dependency is looks like it can be recycled in many, many rules we have a nice /rules/10_hasbase.cf for cases like these.
Re: [auto] bad sandbox rules report
On Wed, 6 Mar 2013, Axb wrote: If your rules depend on sandbox rules which are not in your own, PLEASE always copy these rules to your own sandbox. This will avoid suprises in the future. It also can lead to problems if the owner of that rule modifies their original copy, but I see your point. -- 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 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- 4 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: [auto] bad sandbox rules report
On Wed, 6 Mar 2013, Axb wrote: I've copied the dependencies to jm and jhardin sandboxes. Suggest you rename them so they're unique to your rules and/or put them in a commitername_dependencies.cf file Thanks! -- 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 --- Failure to plan ahead on someone else's part does not constitute an emergency on my part. -- David W. Barts in a.s.r --- 4 days until Daylight Saving Time begins in U.S. - Spring Forward
Re: [auto] bad sandbox rules report
Godo day rulesrc/sandbox/khopesh/ is full of rules which are tflags nopublish We've been masschecking these rules for months and it seems pretty pointless to spend CPU time on them if they're never going to be published. Could these be reviewed and disabled/removed if there's no plan to push out? Thanks Axb.
Re: [auto] bad sandbox rules report
Good day Commiters, Could we agree to remove/disable no hits at all rules? This would speed up masschecks quite a bit. (also, never hurts to do a cleanup) Thanks Axb
Re: [auto] bad sandbox rules report
Den 2012-07-04 10:44, Axb skrev: Could we agree to remove/disable no hits at all rules? no, spammers would start using this taktics after disable is there an minimum time for not hitting ?, or just not hitting last masscheck ? This would speed up masschecks quite a bit. oh fair :) (also, never hurts to do a cleanup) it does not take long if done daily, but if it done on each 365 day it takes 365 days, i know this from expirence :)
Re: [auto] bad sandbox rules report
ah, noted. --j. On Thu, Aug 27, 2009 at 01:23, Warren Togamiwtog...@redhat.com wrote: On 08/26/2009 04:31 AM, Rules Report Cron wrote: rulesrc/sandbox/jm/20_khop_sc_bug_6114.cf (10 rules, 10 bad): KHOP_SC_CIDR16: no hits at all KHOP_SC_CIDR24: no hits at all KHOP_SC_CIDR8: no hits at all KHOP_SC_TOP10: no hits at all KHOP_SC_TOP100: no hits at all KHOP_SC_TOP20: no hits at all KHOP_SC_TOP200: no hits at all KHOP_SC_TOP_CIDR16: no hits at all KHOP_SC_TOP_CIDR24: no hits at all KHOP_SC_TOP_CIDR8: no hits at all khopesh in #spamassassin mentioned that these rules in the sandbox broke a few weeks ago when the sandbox moved. He hasn't had time to follow up. I don't know the details myself. Warren -- --j.
