Bug 7436

Summary: FEATURE IDEA: Add expiry date to rules
Product: Spamassassin Reporter: Dianne Skoll <dfs>
Component: RulesAssignee: SpamAssassin Developer Mailing List <dev>
Status: REOPENED ---    
Severity: enhancement CC: apache, kmcgrail
Priority: P2    
Version: unspecified   
Target Milestone: Undefined   
Hardware: All   
OS: All   
Whiteboard:

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.