Bug 5918 - 80_additional.cf is out of sync with scores in updates
Summary: 80_additional.cf is out of sync with scores in updates
Status: RESOLVED INVALID
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.2.4
Hardware: All All
: P3 normal
Target Milestone: 3.2.6
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-06 06:24 UTC by Aaron Richton
Modified: 2008-12-31 09:05 UTC (History)
1 user (show)


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 Aaron Richton 2008-06-06 06:24:16 UTC 
3.2/80_additional.cf commit #648640 added (really backported) rules like JM_REACTOR_MAILER and JS_BOBAX_MID_2 among others. There was no corresponding commit to 3.2/72_scores.cf, so they're all getting the default score (1). There seems to be consensus/mass-check evidence that these rules deserve scores >1. Appropriate scores should be chosen and committed to 3.2 so they can hit the update channels. As a motivating example, the latest trunk 72_scores.cf has

score JM_REACTOR_MAILER 2.409 4.417 0.000 0.000

which would have helped me with:

X-Spam-Status: No, score=4.801 tagged_above=-50 required=5
    tests=[JM_REACTOR_MAILER=1, RCVD_IN_BL_SPAMCOP_NET=2.188,
    URIBL_AB_SURBL=1.613]

of which I've seen 3 FN's in the last eight hours.
Comment 1 Justin Mason 2008-06-09 04:01:22 UTC 
we're planning to set these scores using the GA on a frequent basis for 3.3.0.
However in the meantime, I'm not sure what we should do -- apart from pick good
values out of the air and put them in manually...
Comment 2 Aaron Richton 2008-06-09 05:57:22 UTC 
Well, I'd imagine (perhaps this is overly optimistic) that the latest scores in trunk/72_scores are the "state of the art." Now, obviously there's better stuff coming in 3.3...but in the meantime, perhaps a one-time (or ideally, occasional as 3.2/updates gets commits) snapshot from trunk would make sense?
Comment 3 Daryl C. W. O'Shea 2008-06-09 06:34:36 UTC 
Back when we were doing more frequent 3.2 updates I was copying the scores from the ones I'm generating for 3.3 and cutting them in half if I was feeling really cautious that day.
Comment 4 Justin Mason 2008-06-09 06:45:02 UTC 
so that would be this, from 3.3.0 rulesrc/scores/72_scores.cf :

score JM_REACTOR_MAILER              4.438 4.499 0.000 0.000

?
Comment 5 Daryl C. W. O'Shea 2008-06-09 08:45:51 UTC 
Yep... and copy over the set 0 & 1 scores to sets 2 & 3 since we don't yet generate bayes enabled scores.  I'd probably just use 4.4 for all for sets if you think the rule is safe.
Comment 6 Aaron Richton 2008-06-10 15:59:02 UTC 
Sounds good to me, unless there are objections...
Comment 7 Justin Mason 2008-12-31 09:05:46 UTC 
ugh, missed the boat on this.  the spam has moved on and these rules don't do much good anymore...