Re: spam-check-BBDB bug?/bbdb whitelist split function

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 05 Feb 2003, billw@wolfram.com wrote:
> On Wed Feb 05 2003 at 08:47, Ted Zlatanov <tzz@lifelogs.com> said:
> 
>>> I've also adjusted this to return a positive match for bbdb
>>> persons; folks who maintain bbdb as a whitelist might find it
>>> useful (adjust for local conditions, YMMV, etc.):
>>
>> Currently, spam-split will fall through to the next spam/ham check
>> on a whitelist match.
>>
>> I thought of having whitelists return t for a positive ham match,
>> and then spam-split wouldn't examine the rest of the spam/ham
>> checks but simply return nil altogether. Does that makes sense?
> 
> Kinda, but I don't have a clear picture of the whole thing (hence my
> little function to do the one thing I wanted at that precise place).

I had screwed up my code in spam.el - now, spam-use-BBDB and
spam-use-whitelist will not go to the next rule, if the sender is in
the BBDB/whitelist but simply exit spam-split altogether; also they
will only consider messages from people NOT in the BBDB/whitelist spam
if spam-use-{whitelist,BBDB}-exclusive is set.  Basically, I ended up
doing what you (and I assume everyone else) wants out of
BBDB/whitelisting, instead of the broken behavior I had in place
before.

>> Or should spam-split have a ham-split-group analogous to
>> spam-split-group?
> 
> Aha - that's exactly what I was grepping for last night.

I'd rather have spam-split fall through to the next rule in the
split-fancy sequence, I think.  It was just not doing the right thing
before, that's all...  The bug was in the code, not the design.

But if people want ham-split-group, I can add it to the ham checks as
an option, instead of fall-through.  This variable name is getting
dangerously close to "split-pea and ham soup."

Thanks
Ted