Bug 3370 - Further enhancement request for --lint / check for broken meta rules
Summary: Further enhancement request for --lint / check for broken meta rules
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Regression Tests (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 3109
Blocks:
  Show dependency tree
 
Reported: 2004-05-11 09:57 UTC by Fred T
Modified: 2006-08-03 11:14 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Fred T 2004-05-11 09:57:10 UTC
--lint might not be the proper place for this, some of it might but not all.

Those of us who create a lot of custom rules find ourselves checking for simple 
human errors that can cause a ruleset to go bad.

The following is a list of suggestions combined by our SARE group, order is set 
by importance:

Dumb rule checking, could lint check for a stupid rule like:
body  FOO  /(?:this|that|them|these||those)/

That double || will fire on everything and can not be valid in a rule.
A few of us have suffered from this in the past.  Asking for this because we 
are human and make mistakes.
Some other examples of this include:
/(?: |)/
/(?:| )/
or could be:
/(?: |foo|bar)/
/(?:foo|bar| )/

Other possible lint warnings:
Unknown meta rule warnings (meta rules that include rules that are possibly mis-
spelled or missing)
meta  FOO  (BAR_DOES_NOT_EXIST && NEITHER_DO_I)
score FOO  1.0
This produces no errors.


Missing Descriptions - I object to this but it was brought as a possible 
improvement.  I personally do not use any descriptions for my own rules, so if 
something like this does make it in, would it be possible to turn off warnings 
on something like this?  Config like:
lint_ignore_descriptions 1

Missing scores - This might be helpful, but many times I write a simple rule to 
run against mass-check and I don't need a score set until I figure out how the 
rule will perform.

Could the error messages from --lint be improved?  Maybe check for common 
mistakes like not escaping @
I'm not educated enough with perl to know what @ is used for, so maybe this 
alone would help some folks.

Take the following rule:
body TEST_FOO	/the@man test/


It produces the folling lint error:
LINTING RULESET
Failed to compile body SpamAssassin tests, skipping:
        (Global symbol "@man" requires explicit package name at 
C:\Perl\Site\Etc\Mail\SpamAssassin/NEW_RULES_UNDER_TEST.cf, rule TEST_FOO, line 
1.)

This does tell the filename the problem exists in, I thought is was doing 
something different, either way, that was reported to me and needed to be 
included.
Thank you
Comment 1 Justin Mason 2004-05-11 23:21:40 UTC
there's actually a linting script in masses -- "lint-rules-from-freqs".
right now, it accepts freqs data on STDIN and does some linting; but it
should probably be modified to not always require freqs, since most
of its linting code does not use that anyway.

It already does a fair bit of warning about missing descriptions, etc., and
looks into the rule code for issues, so would be the best place for these.

actually, I think it may also catch missing meta rules (Theo, didn't you add
that a while back?)

(also we're already getting complaints about spamassassin --lint being too strict ;)
Comment 2 Fred T 2004-11-02 10:39:49 UTC
Using 3.0.1 --lint does not identify broken meta rules.

meta  TEST_FOO1		(MY_META_TEST01 && __FOO_BAR_BS)
score TEST_FOO1		1.1


Most of what I brought up when I opened this ticket can be ignored but I think 
this issue is more important and not going to cause people to complain about 
lint being too strict.  This is an important lint item which is not performed.
Comment 3 Daniel Quinlan 2005-03-30 01:08:54 UTC
move bug to Future milestone (previously set to Future -- I hope)
Comment 4 Daniel Quinlan 2005-04-08 01:22:41 UTC
I have modified make test to handle meta rules with missing or disabled
dependencies.  meta rules with syntax errors still has to be addressed
somewhere.
Comment 5 Daniel Quinlan 2005-04-08 01:25:36 UTC
see also bug 4037 and bug 4071
Comment 6 Fred T 2005-09-29 15:29:37 UTC
Daniel,
I haven't looked into this much, Can this make test be used to test 3rd party 
rules?  Is it included with 3.1?  If so, I'd be happy to close this ticket, but 
this issue hit me again today so I'd love to have some way to catch my stupid 
user mistakes.
Comment 7 Fred T 2006-04-19 18:07:50 UTC
Should I close this ticket?  I understand it might not be practical for this 
feature, since it's built into your t test's it is only handy for those of us 
writing 3rd party rules.  I've since built my own meta dependancy walker so I 
no longer need this built in.
Comment 8 Justin Mason 2006-04-19 18:21:19 UTC
well, the meta dependency tree tracing in bug 3109 would make it reasonably simple.
Comment 9 Justin Mason 2006-08-03 18:14:21 UTC
'spamassassin --lint -Dinfo' will now report broken meta dependencies...