Re: spam.el: automatically resplitting ham in a spam group?

[lorentey@elte.hu (Lőrentey Károly)]

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 20 Nov 2003, lorentey@elte.hu wrote:
>
>> Lőrentey Károly <lorentey@elte.hu> writes:
>>> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>> I could make a ham-destination option to use 'respool instead of a
>>>> group name, but just recently there was discussion of a nnimap bug
>>>> with respooling.  What if the respooling returns nil, do we leave
>>>> the ham message in the spam group?
>>>
>>> Hm.  What if spam-split would simply be disabled during the
>>> ham-exit respool?
>> 
>> Sorry, my mind was wandering about respooling back to the spam
>> group.  When does respooling return nil?  Does it mean that the
>> respooling failed to categorize the message in any group?  I guess
>> in my case, leaving ham in the spam group is OK if it can not be
>> meaningfully resplit.
>
> Respooling could return nil if the last element is spam-split or some
> other function that can return nil.  I think returning nil as the last
> split element is officially a Bad Thing, and spam-split does it
> because anywhere but the last element it indicates a fall-through
> (thus, ham gets through spam-split).

I see.  But I don't think it is normal that spam-split (or some other
nil-returning function) would be at the end of the split
specification.

> Anyhow, the big concern, which I just formulated this morning because
> my brain works better then :) is that we resplit right back into the
> spam group.  That's a very bad thing, because it will look to the
> user like spam.el is not doing its job.

IMHO most of this (except infrequent the nil case) would be eliminated
by disabling spam-split.

-- 
Lőrentey Károly