Bug 5174 - RFE: "promothreshold" parameter to set rule-promotion metadata
Summary: RFE: "promothreshold" parameter to set rule-promotion metadata
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: sa-update (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-10 11:09 UTC by Justin Mason
Modified: 2006-11-10 11:09 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 Justin Mason 2006-11-10 11:09:12 UTC
I'm messing around with some interesting, automatically-generated rules
at the moment.  It looks like I'll be able to collect a corpus of
spam and nonspam, run a script, and get a set of rules that hits 6%
of spam with 0 FPs on the nightly mass-check corpora.  (See
 http://ruleqa.spamassassin.org/?daterev=20061109-r472811-n&rule=%2FXMAILER_MIMEOLE&srcpath=rulesrc%2Fsandbox%2Fjm%2F&s_zero=on&s_detail=on&g=Change

for an example.)

Now, I'd like to automate this a little more -- for example, driving
it from spamtraps and creating rulesets weekly, let's say.  But I don't
want to allow rules with any FPs at all to get into rule updates.

A good way to do this would be to add a new config setting which controls
the promotion thresholds, currently set to a default of:


# as per http://wiki.apache.org/spamassassin/RulesProjPromotion, for -P
my $promote_so_min      = 0.95;
my $promote_hitrate_min = 0.02;
my $promote_fprate_max  = 1.00;

(from hit-frequencies).

I suggest something like "#promothreshold so_min=1.00 hitrate_min=0.02
fprate_max=0.00". the "#" is to protect it against normal parsing, like "#reuse".