Bug 7436 - FEATURE IDEA: Add expiry date to rules
Summary: FEATURE IDEA: Add expiry date to rules
Status: REOPENED
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: 2017-06-15 14:59 UTC by Dianne Skoll
Modified: 2019-08-10 15:00 UTC (History)
2 users (show)



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 Dianne Skoll 2017-06-15 14:59:39 UTC
It would be nice to be able to add expiry dates to rules so SpamAssassin automatically ignores them after the expiry date.

The use case is locally-created rules designed to deal with a specific spam run that don't have long-term value; the expiry date both expires them out after a while and documents the fact that they're temporary.

This feature is intended for site rules, not centrally-distributed ones because giving spammers knowledge of expiry dates is not a good idea.

Issues to consider:

1) Meta-rules: What if a component rule expires?  Possible ways to deal with this are to ignore expiries on rules that are part of a meta rule, or alternatively ensure that the meta-rule expires at least as soon as the component rule.

2) How to expire rules?  If a rule is already expired when the config file is read, it can be discarded.  But in a daemon that might not read the config file often, we'd need a place in memory to store the expiry date of a rule and delete it once that date has passed.

3) How to express in the config file?  Ideas so far are one of:

   expire RULENAME yyyy-mm-dd

or

   tflags RULENAME expire=yyyy-mm-dd

4) (Ambitious) What about a utility script to parse the rules file and clean out old rules?  That is, copy an input rules file to an output rules file, omitting expired rules.
Comment 1 Kevin A. McGrail 2017-08-09 20:30:01 UTC
My thoughts on this topic have been an automatic gradiated disablement for efficiency.  Adding your idea of a date and the rule is only tested for every 1 out of X messages but goes back to 100% if it gets a certain # of hits.  This would allow SA to run on a subset of rules but increase the subset based on in the wild hits.
Comment 2 Henrik Krohns 2019-08-09 15:24:55 UTC
Duplicate of already closed Bug 6210. Just bloats code for no reason, people can do local scripting to rotate any cf files they wish.

*** This bug has been marked as a duplicate of bug 6210 ***
Comment 3 Kevin A. McGrail 2019-08-10 15:00:24 UTC
I think this has great merit on a per rule basis instead of .cf files.  I'd like to keep it open and see if I can get some time to test with it.