planned spam.el features

[Ted Zlatanov <tzz@lifelogs.com>]

OK, now that spam.el is somewhat stable, I'm going to start working on
the next bunch of features:

- unified spam score command (`S t' should produce the most sensible
  score: whichever of [ifile|bogofilter|spam-stat] is set as a spam
  exit processor on the current group, or whichever the user
  specifies).  This will not unify the spam scores themselves, only
  the command used to display them.

- global message registry to record what messages were processed as
  spam or ham.  This is so a message registered by accident as spam
  can later be reclassified as ham.

- capturing messages when they are accepted, moved, or replaced.  This
  is what I saw in the ifile-gnus.el code - is it sufficient to trap
  those three article events to track an article as it moves around?
  What functions should I advise?  Examples would be greatly
  appreciated; the ifile-gnus.el example is only applicable to nnml
  unfortunately.

- optimized training on large numbers of messages, when the spam/ham
  processor allows it.

- better documentation, especially concerning interaction with
  spam-stat.el

- Hashcash support for verifying cookies?  Is anyone using this or at
  least interested?

- universal spam/ham scores?  -100 to -1 is spam, 0 to 100 is ham.
  All the backends would be required to produce a unified score.  Does
  anyone think this would be useful?

Ted