Bug 1112 - Specify meta rules using regexps
Summary: Specify meta rules using regexps
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P2 enhancement
Target Milestone: ---
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-12 19:57 UTC by Matthew Cline
Modified: 2002-12-22 08:41 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Cline 2002-10-12 19:57:52 UTC 
I've modified the meta-test compiler so that the tests to be checked against
can be specified using a regexp followed by an operator: all rules matching
the regexp will be strung together, with the given operator between each
of them.

Thus, instead of:

meta T_TOO_MANY_UA     ( USER_AGENT_PINE + USER_AGENT_MUTT +
USER_AGENT_MOZILLA_UA + USER_AGENT_MOZILLA_XM + USER_AGENT_MACOE +
USER_AGENT_ENTOURAGE + USER_AGENT_KMAIL + USER_AGENT_IMP + USER_AGENT_TONLINE +
USER_AGENT_APPLEMAIL + USER_AGENT_GNUS_UA + USER_AGENT_GNUS_XM > 1 )

You can write:

    meta T_TOO_MANY_UA      ( (USER_AGENT.* +) > 1)  

Easier to read, plus if new USER_AGENT rules get added, you don't have
to update the T_TOO_MANY_UA rule.

The regexps have "^" and "$" added to their fronts and ends by the rule
compiler, so the regexp must match the whole rule name.

A rulename regexp can start with a "." or "[", so this works:

   meta TOO_MANY_FOO       ( (.*FOO.* +) > 1)

and this:

   meta TOO_MANY_FOO       ( ([FX]OO.* +) > 1)
Comment 1 Daniel Quinlan 2002-10-13 00:52:00 UTC 
This seems pretty hackish to me considering that it's only used for one, maybe
two, additive conjunction rules.  Bloating meta tests by 52-lines to save a
little bit of space in a rule seems like a bad maintainability trade-off.

I think I'd rather just see an eval be used for this test.  Perhaps a new eval:
type for (meta?) rules that have to be run after everything else.
Comment 2 Daniel Quinlan 2002-12-17 04:19:42 UTC 
No rules seem to be using this feature.  Should we keep it in the code?
Comment 3 Justin Mason 2002-12-17 06:57:35 UTC 
I would prefer not to, I don't like it.  strikes me as something that
(a) is slightly confusing and (b) could have side-effects later.
Comment 4 Theo Van Dinter 2002-12-17 07:33:28 UTC 
Actually, I've been using this code for a number of different test rules.  At
this point though, I think the only ones left are NIGERIAN_BODY and
NIGERIAN_SUBJECT.

They could be modified to use an eval rather easily, as long as they run after
the other body/header/etc tests.  I really don't want to make yet another rule
type though.

Since my two rules are really just combinations of string matches, maybe I
should split out the single meta into individual strings and let them just live
on their own?  I'd hate to see these strings, which work well together, get
trimmed due to low hit rate or high FPs (NIGERIAN_BODY requires at least 2
strings to match, SUBJECT could be easily split since it only requires a single
string match.)
Comment 5 Matthew Cline 2002-12-22 17:41:02 UTC 
OK, I've removed the code from PerMsgStatus.pm, and none of the meta rules use it
anymore, so I'm resolving this as WONTFIX.