Re: Add hooks to Gnus on move/edit/delete?

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 29 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:

> I think it might work if you use nnimap splitting.  If you use Sieve
> or procmail, then it could be difficult, since the ifile database
> would be on your local host in the home dir, whereas the
> Sieve/procmail rules are on the IMAP server.

We can explicitly require that in the manual.

>> So if ifile-spam-filter could and should be replaced with another
>> ifile-gnus.el function that returns regular group names, spam.el
>> can do all the ifile classification automatically if the user just
>> sets spam-use-ifile to t.
>>
>> Does that sound reasonable?
> 
> I'm not sure.  How do I tell spam.el which group a message is in?
> If ifile has chosen the group wrongly, how do I tell it about the
> error?

I think it's supposed to be automatic, but currently only bogofilter
processing is done:

- when entering a spam group ( a member of spam-junk-mailgroups),
  all unread messages are marked as spam

- when exiting any group:

  - spam-marked articles are processed as spam, then marked expired so
    they are not processed twice and so we don't keep them around.

  - ham-marked articles are processed as ham (non-spam); these are the
    gnus-del-mark, gnus-read-mark, gnus-killed-mark,
    gnus-kill-file-mark, and gnus-low-score-mark articles.  There
    should be, but isn't, a mechanism to prevent them from being
    processed more than once.  Any suggestions?  Yet another cache or
    a supplemental ham-processed-mark?

When I say "processed," I mean "passed to bogofilter on the command line
with the appropriate flag (-n for ham, -s for spam)."

The equivalent of spam-bogofilter-register-routine for ifile needs to
be written for ifile processing on group summary exit.  I haven't done
it yet, because I didn't know that ifile-gnus.el supported nnimap
already.  So let me know if you think it's ready to be incorporated.

> ifile-gnus intercepts move and copy operations to see that.  So
> designating a message as spam works by moving it to the spam group.

With spam.el, you designate a message as spam by marking it with the
spam mark.  We could automatically move all spam articles in a group
to the spam group on summary exit when ifile is enabled, to accomodate
its operation mode.  But would that be acceptable to users?

> Maybe a two-stage process is better: first decide whether it's spam
> or not, then distribute the non-spam to the right groups.

I'm not sure how that would work.

Ted