Re: `S t' always returns nil

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 27 Jan 2003, chris@splinter.inka.de wrote:
> You still get this output (at least by default) using the
> Robinson or the Graham algorithm. The newer Robinson-Fisher
> though, which has three possible return values, can return
> 'Spam', 'Ham' or 'Unsure'.

OK, so "Spam" and "Yes" are both positive spam indicators.  I've added
that to spam.el.

>> Fixing this is trivial, but should I match on something else, or
>> should I allow both ^Yes and ^Spam as valid spam indicators in the
>> header?
> 
> Since the indicators are configurable, it might be advisable to
> allow the user to tell Gnus what to match on.

Done, another long variable comes into existence!

spam-bogofilter-bogosity-positive-spam-header is a regexp.  The
default allows for "Yes" and "Spam."

> There's one thing to be decided if Robinson-Fisher is integrated
> into spam.el, though: What should be done with the 'unsure'
> messages?  Should they be moved to a separate group?

I want spam.el to remain binary (spam vs. ham).  Introducing a third
category would complicate things enormously.  ifile is the only
multi-way classifier in a limited way, and I'm not sure that's too
useful.  We should have three ways of dealing with 'Unsure' messages:

- treat them as ham (the case now)

- let the user decide if they are to be ham or spam (why would the
  user ever want unsure messages as spam, though?)

- use the spamicity score for 'Unsure' messages, cutoff decided by the
  user

I think the third option is best, what do you think?

Ted