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

[Ted Zlatanov <tzz@lifelogs.com>]

On Sun, 04 May 2003, zack@codesourcery.com wrote:
> 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'.

We could make ham-process-destination a function in addition to a
plain string, and have the function invoked on each spam message to
return a string.  It can be similar for spam-process-destination and
ham messages.  Would that help, or must you use manual move?

It's unfortunate you don't use splitting, that would make things
easier.

Anyhow, if none of the suggestions work for you, we can certainly
implement the move-then-mark behavior in spam.el.  I don't think it
will be too hard, in fact it can coexist with the mark-then-move
behavior pretty cleanly.

>> 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.

Hmm.  We could hook into the gnus-summary-article-move-hook and have
it save the UIDs to a file, and then you can run the script that
batch-processes all the UIDs, interactive or hooked on summary exit
for example.

Ted