Re: A different spam model, which might be possible already

[Zack Weinberg <zack@codesourcery.com>]

Ted Zlatanov <tzz@lifelogs.com> writes:

>> * If I do 'B m' on message(s) in the spam group, they automagically
>>   get their $ mark removed.  
>
> Currently, the behavior is the reverse: if the articles have a
> ham-mark in a spam group (see the ham-marks group parameter) they will
> be moved out of the spam group to the ham-process-destination group
> after being processed with the group's ham processors.  What you
> describe could be coded as alternate behavior, but I don't see the
> advantage (see later about article moving and tracking).

The trouble with ham-process-destination is there isn't just one ham
group.  Most of the false positives I get with the current static
database belong to various mailing lists.  But I don't use splitting,
so Gnus doesn't have any way of knowing which mailing-list folder a
message belongs to.  Hence, I need to specify it by hand, using 'B m'.  

> I'm not sure what's the benefit of doing the article move on the
> server side.  Isn't it better to let Gnus do the move, since it will
> involve about the same amount of (minimal) network traffic?  Or is the
> nnimap remote article move somehow suboptimal?

I wasn't suggesting not to let Gnus do the move (I'm not sure whether
nnimap remote move is optimal or not, but that's a separate problem).
What I want to avoid is having Gnus read the entire message from the
server and then feed it into an ssh pipe straight back to the server.
Hence the dance with the IMAP UIDs and the remote script needing to
know which group the messages are in at the time it runs.

>> there is a need for the messages not to get deleted or moved until
>> the aforementioned digging happens.
>
> Why?  As long as you don't expunge or expire the articles before
> calling the shell pipe for ham articles in spam groups or spam
> articles in ham groups, spam.el will know if they got moved to another
> group or were left in the original group, marked as expired.  It can
> tell that to the shell pipe to the remote server.

In the proposed scheme I am playing fast and loose with internal
details of Courier IMAP mailboxes in order to map UIDs to messages on
the server side.  I do not want to risk complicating the issue by
having this happen after the server-side state of these messages
changes.

zw