Mailing-List: contact users-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of rwmaillists@googlemail.com
 designates 74.125.82.47 as permitted sender)
Date: Thu, 31 Jan 2013 22:50:58 +0000
From: RW <rwmaillists@googlemail.com>
To: users@spamassassin.apache.org
Subject: Re: Calling spamassassin directly yields very different results
 than calling spamassassin via amavis-new
Message-ID: <20130131225058.27ab954e@gumby.homeunix.com>
In-Reply-To: <alpine.LNX.2.00.1301311206001.26242@athena.impsec.org>
References: <50EDEBAD.2030104@indietorrent.org>
	<50EE053B.7000107@indietorrent.org>
	<201301100136.27445.mewolf1@gmx.net>
	<50EE2030.6020604@indietorrent.org>
	<alpine.LNX.2.00.1301091812350.13134@athena.impsec.org>
	<50EEEFC0.9050706@indietorrent.org>
	<20130110164944.26e84494@gumby.homeunix.com>
	<50EEF7D3.7080003@indietorrent.org>
	<50EEFED7.9090800@indietorrent.org>
	<20130110180604.5bce777e@gumby.homeunix.com>
	<50EF0EBE.9000401@indietorrent.org>
	<50EF2101.7000005@whyscream.net>
	<50F083DC.3040808@indietorrent.org>
	<50F44D77.6080209@indietorrent.org>
	<20130114194906.23094021@gumby.homeunix.com>
	<50F471C5.7090800@indietorrent.org>
	<alpine.LNX.2.00.1301141647120.18624@athena.impsec.org>
	<50F58343.2000101@indietorrent.org>
	<alpine.LNX.2.00.1301151038460.8211@athena.impsec.org>
	<50F5BE84.7080507@indietorrent.org>
	<alpine.LNX.2.00.1301151414470.8211@athena.impsec.org>
	<510AB4FD.5070406@indietorrent.org>
	<alpine.LNX.2.00.1301311206001.26242@athena.impsec.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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.