http://bugzilla.spamassassin.org/show_bug.cgi?id=2975
------- Additional Comments From [EMAIL PROTECTED] 2005-05-03 13:43 ------- Justin, my sentiments exactly. A lock-safe equivalent of rm -f bayes_seen would be a pretty desirable tool anyway, and offers at least an interim solution. As for options to solve this the "right way", I just sent this to Michael off-line regarding comment #7 and figured this should be echoed here (with more thoughts added to 3) I'd say option 2) is the most consistent with how SA handles expiry of tokens, and seems the most sensible option. 1)could be workable as well, but 2) strikes me as an improvement. 3) could be implemented as an option that simply disables the bayes_seen portion entirely, and isn't very relevant to expiry as it works by eliminating the need. Unless SA is redesigned to exclusively do things this way, you'll need 1,2,or 5. I don't think that in the general case you want to use this as your normal mode of operation. Protecting against accidental re-learning is good in most environments. 4) While an interesting idea, this doesn't address or solve the problem of expiry. If you went this way you'd still need 1,2, or 5 to solve the boundless-growth problem. See also thoughts on 3. 5) sounds extensively complicated, bulky in terms of storage demand, and of limited gain. I think you'll find that this mechanism would allow the bayes_seen to grow more-or-less without bound anyway. I state this based on the theory that it only takes one unexpired token to retain a message ID, and the majority of messages you train are going to have at least one "frequently seen" token that keeps getting learned in new messages. SA's token expiry is going to favor keeping these "frequently seen" tokens when it expires tokens, because they're going to have a short delta-atime. (And it would be right to keep them, as statistically speaking they are the best candidates to keep) In summary, it sounds like the best thing to do would be 2. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
