https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7890
--- Comment #7 from RW <[email protected]> --- (In reply to [email protected] from comment #6) > (In reply to RW from comment #5) > > (In reply to [email protected] from comment #4) > It is still polling -- an inferior method: increasing frequency increases > load, but the reaction is still delayed. It makes little difference as long as the interval is small compared the typical time the users take to react to misclassifications. I use ls to determine whether there is anything in a training folder before running sa-learn on it. Typically it isn't even accessing the drive as it's working on cached metadata. I'm not sure that your idea can be made reliable without keeping an extra database or doing a periodic full retrain. > > Dovecot has a plugin that largely does what you want. It can also be done > > using "IMAP Sieve" which allows sieve-like scripts to be handle IMAP events. > > I don't know whether Cyrus has equivalent functionality, I suspect it does. > > > > At best, that functionality will be invoking sa-learn each time -- a > separate perl-program. Not as efficient as the already-running perl-program > with all necessary code already in it. spamc can be used to train to spamd if you prefer, but then you get the problem of what happens when spamd is not running. That's fairly easy to fix, but IMHO the saving in cpu cycles is unlikely to be worth the effort. Doing it from the IMAP server has the advantage that you can train as ham when mail is moved from the spam folder, and it can distinguish the special case of spam being sent to a trash folder. I'm not sure you should even be training directly on a Cyrus mailbox, I think they contain additional metadata files. Training from IMAP would avoid any problems around that. -- You are receiving this mail because: You are the assignee for the bug.
