Bug 6074 - parse-rules-for-masses shouldn't use a separate rules parser
Summary: parse-rules-for-masses shouldn't use a separate rules parser
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Masses (show other bugs)
Version: unspecified
Hardware: Other All
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 6012
Blocks:
  Show dependency tree
 
Reported: 2009-02-26 18:53 UTC by Duncan Findlay
Modified: 2009-02-27 11:08 UTC (History)
1 user (show)



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 Duncan Findlay 2009-02-26 18:53:34 UTC
parse-rules-for-masses parses SpamAssassin rules for use in the scoring process, but it does so in a manner that is completely different than Mail::SpamAssassin::Conf. For example, parse-rules-for-masses is unable to handle conditional rule definitions, and it makes it more difficult to add new rule types.

It should be easy to replace parse-rules-for-masses with a script that builds a Mail::SpamAssassin::Conf object, parses the rules and dumps the results in the same format as p-r-f-m.

The only tricky part is that p-r-f-m currently is able to read "#reuse" and "#<gen:mutable>" instructions directly from the config. The "#reuse" issue will be solved with bug 6012. To handle mutable scores, we might need to make a "notmutable" tflag (and assume everything else is mutable) to replace the "<gen:mutable>" instruction.
Comment 1 Justin Mason 2009-02-27 03:13:34 UTC
(In reply to comment #0)
> The only tricky part is that p-r-f-m currently is able to read "#reuse" and
> "#<gen:mutable>" instructions directly from the config. The "#reuse" issue will
> be solved with bug 6012. To handle mutable scores, we might need to make a
> "notmutable" tflag (and assume everything else is mutable) to replace the
> "<gen:mutable>" instruction.

if we can set that tflag from the "#<gen:mutable>" markup in the rule files, that'd be fine by me.  

The alternative would be having to add a tflag line for lots of rules... actually, how many rules would that affect?
Comment 2 Michael Parker 2009-02-27 07:44:19 UTC
> The alternative would be having to add a tflag line for lots of rules...
> actually, how many rules would that affect?

In the Apache SpamAssassin ruleset its ~100 rules, for others it could be a lot more or a lot less.

Can we use:

if mutable
score BLAH 0
endif

Comment 3 Justin Mason 2009-02-27 07:59:47 UTC
(In reply to comment #2)
> > The alternative would be having to add a tflag line for lots of rules...
> > actually, how many rules would that affect?
> 
> In the Apache SpamAssassin ruleset its ~100 rules, for others it could be a lot
> more or a lot less.

hmm, that sounds reasonably manageable. ok, +1

I'd prefer btw if those "tflags nonmutable" lines remained near the scores, in 50_scores.cf, though....
Comment 4 Duncan Findlay 2009-02-27 11:08:46 UTC
I absolutely agree that the tflags should be near the scores. We may need a syntax like:

tflags FOO +nomutable

otherwise the nomutable flag will override the others.


I don't really like the "if mutable" syntax -- mutable isn't really a conditiona
l.