On Fri, 1 Feb 2013 09:00:48 -0800 (PST)
John Hardin wrote:
> On Fri, 1 Feb 2013, Ben Johnson wrote:
>
> > John, thanks for pointing-out the problems associated with
> > re-sending the messages via sendmail.
> >
> > I threw a line out to the Dovecot users group and learned how to
> > move messages without going through the MTA. Dovecot has a utility
> > executable, "deliver", which is well-suited to the task.
> >
> > For those who may have a similar need, here's the Dovecot Antispam
> > pipe script that I'm using, courtesy of Steffen Kaiser on the
> > Dovecot Users mailing list:
> >
> > ---------------------------------------
> > #!/bin/bash
> >
> > mode=
> > for opt; do
> > if test "x$*" == "x--ham"; then
> > mode=HAM
> > break
> > elif test "x$*" == "x--spam"; then
> > mode=SPAM
> > break
> > fi
> > done
> >
> > if test -n "$mode"; then
> > # options from http://wiki1.dovecot.org/LDA
> > /usr/lib/dovecot/deliver -d u...@example.com -m
> > Training.$mode fi
> >
> > exit 0
> > ---------------------------------------
>
> That seems a lot better.
>
> > Regarding the second point, I'm not sure I understand the problem.
> > If someone drags a message from Trash to SPAM, shouldn't it be
> > submitted for learning as spam?
> >
> > The last sentence sounds like somewhat of a deal-breaker. Doesn't my
> > whole strategy go somewhat limp if ham cannot be submitted for
> > training?
> >
> > John and RW, do you recommend enabling or disabling the append
> > option, given the way I'm reviewing the submissions and sorting
> > them manually?
>
> I think they're proceeding from the assumption of *un-reviewed*
> training, i.e. blind trust in the reliability of the users.
>
> If it's possible to enable IMAP Append on a per-folder basis then
> enabling it only on your training inbox folders shouldn't be an issue
> - the messages won't be trained until you've reviewed them.
>
> Without that level of fine-grain control I still don't see an issue
> from this if you can prevent the users from adding content directly
> to the folders that sa-learn actually processes. If IMAP Append only
> applies to "shared" folders then there shouldn't be a problem -
> configure sa-learn to learn from folders in *your account*, that
> nobody else can access directly.
This is what it says:
antispam_allow_append_to_spam (boolean) Specifies whether to allow
appending mails to the spam folder from the unknown source. See the
ALLOWING APPENDS section below for the details on why it is not
advised to turn this option on. Optional, default = NO.
...
ALLOWING APPENDS
By appends we mean the case of mail moving when the source folder is
unknown, e.g. when you move from some other account or with tools
like offlineimap. You should be careful with allowing APPENDs to
SPAM folders. The reason for possibly allowing it is to allow
not-SPAM --> SPAM transitions to work and be trained. However,
because the plugin cannot know the source of the message (it is
assumed to be from OTHER folder), multiple bad scenarios can happen:
1. SPAM --> SPAM transitions cannot be recognised and are trained;
2. TRASH --> SPAM transitions cannot be recognised and are trained;
3. SPAM --> not-SPAM transitions cannot be recognised therefore
training good messages will never work with APPENDs.
I presume that the plugin works by monitoring COPY commands and so
can't work properly when a move is done by FETCH-APPEND-DELETE.
For sa-learn the problem would be 3, but I don't see how that is
affected by allowing appends on the spam folder.
