http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5652
------- Additional Comments From [EMAIL PROTECTED] 2007-09-20 02:47 ------- (In reply to comment #1) > I agree this is a good idea. Uncontrolled file growth in bayes_seen and AWL > both > make SA look rather unfinished. Unfortunately, I'm not a perl jockey, or I'd > write a patch myself. > > In general I'd favor an option to essentially make bayes_seen a crude fifo of > sorts, with the depth measured either in days or entries (developer's choice > on > which to implement, both would work fine) +1 > Unfortunately, this feature will involve changing the format of the bayes_seen > database to include an ctime, atime, or entry counter. (depending on the > choice > of expiry criteria...) +1 > I know this feature offers the risk of relearning the same email, but with a > reasonable depth (ie: 30 days) this should be completely moot. It's also even > more moot if you use an atime instead of a ctime or count, as anyone "batch > learning" the same message every day in a cronjob will keep updating the atime > each time they try to learn it. atime would be overkill I think. IMO, the reason this hasn't been implemented yet is because we're coming up with too-complex fixes; token ctime would be just fine, and there's no need to track msg->token mappings so that tokens can be unlearned. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
