spam.el full functionality is officially in beta

spam.el full functionality is officially in beta

[Ted Zlatanov]

I'm not adding any more new code, but I will be fixing the current
code.  Plus, I will write the documentation when everyone is happy
with the code and customization stuff.

The following is a complete summary (to my best recollection) of new
stuff since October:

Basically, everything except ifile spam processing at summary exit
works.

- groups can be designated as spam, ham, or neither (the default).
  This classification can be done with the global regexes of
  gnus-spam-newsgroup-contents or locally for each group or topic with
  the spam-contents parameter.

- at entry in a spam group, all unread articles are marked as spam

- groups can be given a spam/ham processor and a spam processing
  destination.  The global variables gnus-spam-process-newsgroups and
  gnus-spam-process-destinations or the group/topic parameters
  spam-processor and spam-process-destination can be customized.

- at summary exit from any group, the spam processors (ifile,
  bogofilter, or blacklist) will be invoked on all the spam-marked
  articles.  The global spam-use-PROCESSOR variable can also be used
  to enable the respective spam processor.  The ifile processor is not
  functional yet.

- at summary exit from a spam group, the spam-marked articles will be
  marked as expirable, and moved to the spam-process-destination if
  it's defined.  The spam-process-destination is nil by default, so
  articles are left in the spam group.

- at summary exit from a ham group, all the ham-marked (note that the
  list of ham marks can be customized!) articles are fed to the
  whitelist or BBDB ham processor.  This does *not* include unread
  articles by default.  The global spam-use-PROCESSOR variable can
  also be used to enable the respective ham processor.  There is no
  article registry, so articles could be fed to the ham processor more
  than once.  This is not an error with BBDB or the whitelists, but
  perhaps it's worth optimizing.

- the spam/ham processors that only use the "from" field (everything
  except bogofilter and ifile) use the fast message field fetch in
  spam-fetch-field-from-fast directly from gnus-data-list.  They do
  not retrieve the message again.  Thus, they are very fast.  I don't
  know if what I have is the recommended usage, but it works for me
  and I saw it used elsewhere in the code.

Ted