On Thu, 31 Jan 2013 12:12:15 -0800 (PST) John Hardin wrote: > On Thu, 31 Jan 2013, Ben Johnson wrote: >
> > So, I finally got around to tackling this change. > > > > With a couple of simple modifications, I was able to achieve the > > desired result with the Dovecot Antispam plug-in. > > > > Basically, I changed the last two directive values from the switches > > that are normally passed to the "sa-learn" binary (--spam and > > --ham) to destination email addresses that are passed to "sendmail" > > in my revised pipe script. > > Passing the messages through sendmail again isn't optimal as that > will make further changes to the headers. This may have effects on > the quality of the learning, unless the original message is attached > as an RFC-822 attachment to the message being sent to the corpus > mailbox, which of course means you then can't just run sa-learn > directly against that mailbox - the review process would involve > moving the attachment as a standalone message to the spam or ham > learning mailbox. > > Ideally you want to just move the messages between mailboxes without > involving another delivery processing. I don't know enough about > Dovecot or your topology to say whether that's going to be as easy as > using sendmail to mail the message to you. Actually that's the way that the dovecot plugin works. I think that the sendmail option is mainly a way to get training done on a remote machine - it's a standard feature of DSPAM for which the plugin was originally developed. When I looked at the plugin it seemed to have quite a serious flaw. IIRC it disables IMAP APPENDs on the Spam folder which makes it incompatible with synchronisation tools like OfflineImap and probably some IMAP clients that implement offline support in the same way.
