Bug 2295 - Patch adding thresholds to report_safe
Summary: Patch adding thresholds to report_safe
Status: RESOLVED WONTFIX
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P5 enhancement
Target Milestone: 2.70
Assignee: Daniel Quinlan
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-05 07:29 UTC by Rich Puhek
Modified: 2003-09-23 06:50 UTC (History)
1 user (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Patch for report_threshold enhancements. patch None Rich Puhek [HasCLA]
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 Rich Puhek 2003-08-05 07:29:47 UTC 
This patch adds the following options to spamassassin:

report_safe_threshold
report_safe_attach_threshold
report_safe_defang_threshold


Basically, they're intended to allow finer control over the rewriting process.
report_safe_threshold, if defined, will be a threshold value for SA to follow
the report_safe settings (so it has no effect if report_safe = 0).

If either of the other two options is non zero, they'll control the threshold
for which a message is re-written. If the mail scores >=
report_safe_attach_threshold, rewrite_as_spam() is called. If it scores >=
report_safe_defang_threshold, rewrite_as_spam() is called, and the attachment
type is changed to text/plain. If these options are non zero, the
report_safe_threshold and report_safe options are overridden. 

Minimal testing has been performed so far. I have been running my email account
through a patched system, with no obvious ill effects. I have not confirmed that
all the POD documentation looks as pretty as it should either.

The patch modifies PerMsgStatus.pm and Conf.pm
Comment 1 Rich Puhek 2003-08-05 07:31:28 UTC 
Created attachment 1217 [details]
Patch for report_threshold enhancements.
Comment 2 Daniel Quinlan 2003-08-21 23:18:31 UTC 
Thanks, but I don't think we want to add this much complexity to how
report_safe and friends work.  This is far too complicated and very few users
would use this feature, so I don't think the tradeoff of requiring ourselves
to maintain this feature would pay off.  There's also the problem that there
really isn't much danger difference between high and low scoring spam, it may
even be that low scoring spam is WORSE than high scoring spam because those are
more sophisticated spammers.  If a user is vulnerable, then all of their spam
should be encapsulated.

I think most of the desired effect can be achieved by setting a higher
required_hits number and treating high-scoring ham differently than low-scoring
ham.  You can do the same with spam.  Lots of advanced users already do that.
I realize that doesn't match the flexibility of your patch, but perhaps that
would accomplish some of what you want.
Comment 3 Daniel Quinlan 2003-09-23 14:50:28 UTC 
Okay, I'm going ahead to close this one for the aforementioned reasons.