Bug 6721 - ADVANCE_FEE_* scores are too dynamic
Summary: ADVANCE_FEE_* scores are too dynamic
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-12 22:17 UTC by AXB
Modified: 2019-06-24 12:03 UTC (History)
3 users (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 AXB 2011-12-12 22:17:42 UTC 
Working with trunk SA 3.4 I've noticed that the ADVANCE_FEE_* scores are VERY dynamic, always depending on masschecks and, over time, retun inconsistent results compared with the older ADVANCE_FEE rules which had basic static scores.

It makes it hard to create metas when rules come and go so I'd like to propose a basic set of "old fashioned" type static rules with static scores.

I know the project's target is to rely on masschecks for score generation but a basic static ruleset would warrant "basic" performace which can be enhanced by adding extra rule sets & metas.

Comments pls?
Comment 1 Kevin A. McGrail 2011-12-12 22:42:40 UTC 
I think there are two solutions to this:

1 - We need more people in masscheck. That's held up because of a security issue.  But my theory is more corpora, less swings on the scores.

2 - Perhaps we need something on scores for sandboxes that allows a minimum and a maximum threshold.  I seem to remember a recent change that made any scores in sandbox a maximum.

But in the end, algorithms that let spammers reuse old tricks after a time are going to need a balance between static scores and dynamic scores.  

I know every time I've look at getting rid of some old obscure rule, I see some new run of spam that makes me reconsider.

In the meantime, if you have specific static scores, I'm happy to throw them on my server and test to lead to a vote here.
Comment 2 AXB 2011-12-16 11:19:29 UTC 
I suggest JH and myself review the los I have in mind and those with a score above 1.6 get added to a static 20_advance_fee.cf and in 50_scores.cf
For scores higher thatn 2.0 we could round them -0.5 for "safety"

These rule could then commented out in sandboxes.

John? (via IM this could be pretty easy to handle)

comments appreciated
Comment 3 Kevin A. McGrail 2011-12-16 15:57:58 UTC 
(In reply to comment #2)
> I suggest JH and myself review the los I have in mind and those with a score
> above 1.6 get added to a static 20_advance_fee.cf and in 50_scores.cf
> For scores higher thatn 2.0 we could round them -0.5 for "safety"
> 
> These rule could then commented out in sandboxes.
> 
> John? (via IM this could be pretty easy to handle)
> 
> comments appreciated

Looking at those rules and suggesting some static scores as well as moving them out of sandbox sounds fine to me.  Will retain my veto if the scores are too high or I'm feeling bitter, though.

regards,
KAM
Comment 4 John Hardin 2011-12-17 02:17:43 UTC 
I don't have a problem promoting the ADVANCE_FEE_* rules to static, but I regularly modify the subrules as new 419s come across the wire. Is having a static rule that depends on a subrule in a sandbox considered kosher? Or would the subrules be moved out to static rule files as well, even given their non-static dynamicness? :)
Comment 5 Henrik Krohns 2019-06-24 12:03:39 UTC 
Closing stale bug, these seem to be turned into sandbox already.