-Also, when you load @file{spam.el}, you will be able to customize its
-variables. Try @code{customize-group} on the @samp{spam} variable
-group.
-
-@menu
-* Spam ELisp Package Sequence of Events::
-* Spam ELisp Package Filtering of Incoming Mail::
-* Spam ELisp Package Global Variables::
-* Spam ELisp Package Sorting and Score Display in Summary Buffer::
-* Spam ELisp Package Configuration Examples::
-* Blacklists and Whitelists::
-* BBDB Whitelists::
-* Gmane Spam Reporting::
-* Anti-spam Hashcash Payments::
-* Blackholes::
-* Regular Expressions Header Matching::
-* Bogofilter::
-* SpamAssassin back end::
-* ifile spam filtering::
-* spam-stat spam filtering::
-* SpamOracle::
-* Extending the Spam ELisp package::
-@end menu
-
-@node Spam ELisp Package Sequence of Events
-@subsubsection Spam ELisp Package Sequence of Events
-@cindex spam filtering
-@cindex spam filtering sequence of events
-@cindex spam
-You must read this section to understand how @code{spam.el} works.
-Do not skip, speed-read, or glance through this section.
-
-There are two @emph{contact points}, if you will, between
-@code{spam.el} and the rest of Gnus: checking new mail for spam, and
-leaving a group.
-
-Getting new mail in Gnus is done in one of two ways. You can either
-split your incoming mail or you can classify new articles as ham or
-spam when you enter the group.
-
-Splitting incoming mail is better suited to mail back ends such as
-@code{nnml} or @code{nnimap} where new mail appears in a single file
-called a @dfn{Spool File}. See @xref{Spam ELisp Package Filtering of
-Incoming Mail}.
-
-@vindex gnus-spam-autodetect
-@vindex gnus-spam-autodetect-methods
-For back ends such as @code{nntp} there is no incoming mail spool, so
-an alternate mechanism must be used. This may also happen for
-back ends where the server is in charge of splitting incoming mail, and
-Gnus does not do further splitting. The @code{spam-autodetect} and
-@code{spam-autodetect-methods} group parameters (accessible with
-@kbd{G c} and @kbd{G p} as usual), and the corresponding variables
-@code{gnus-spam-autodetect} and @code{gnus-spam-autodetect-methods}
-(accessible with @kbd{M-x customize-variable} as usual) can help.
-
-When @code{spam-autodetect} is used (you can turn it on for a
-group/topic or wholesale by regular expression matches, as needed), it
-hooks into the process of entering a group. Thus, entering a group
-with unseen or unread articles becomes the substitute for checking
-incoming mail. Whether only unseen articles or all unread articles
-will be processed is determined by the
-@code{spam-autodetect-recheck-messages}. When set to @code{t}, unread
-messages will be rechecked. You should probably stick with the
-default of only checking unseen messages.
-
-@code{spam-autodetect} grants the user at once more and less control
-of spam filtering. The user will have more control over each group's
-spam methods, so for instance the @samp{ding} group may have
-@code{spam-use-BBDB} as the autodetection method, while the
-@samp{suspect} group may have the @code{spam-use-blacklist} and
-@code{spam-use-bogofilter} methods enabled. Every article detected to
-be spam will be marked with the spam mark @samp{$} and processed on
-exit from the group as normal spam. The user has less control over
-the @emph{sequence} of checks, as he might with @code{spam-split}.
-
-When the newly split mail goes into groups, or messages are
-autodetected to be ham or spam, those groups must be exited (after
-entering, if needed) for further spam processing to happen. It
-matters whether the group is considered a ham group, a spam group, or
-is unclassified, based on its @code{spam-content} parameter
-(@pxref{Spam ELisp Package Global Variables}). Spam groups have the
-additional characteristic that, when entered, any unseen or unread
-articles (depending on the @code{spam-mark-only-unseen-as-spam}
-variable) will be marked as spam. Thus, mail split into a spam group
-gets automatically marked as spam when you enter the group.
-
-Thus, when you exit a group, the @code{spam-processors} are applied,
-if any are set, and the processed mail is moved to the
-@code{ham-process-destination} or the @code{spam-process-destination}
-depending on the article's classification. If the
-@code{ham-process-destination} or the @code{spam-process-destination},
-whichever is appropriate, are @code{nil}, the article is left in the
-current group.
-
-If a spam is found in any group (this can be changed to only non-spam
-groups with @code{spam-move-spam-nonspam-groups-only}), it is
-processed by the active @code{spam-processors} (@pxref{Spam ELisp
-Package Global Variables}) when the group is exited. Furthermore, the
-spam is moved to the @code{spam-process-destination} (@pxref{Spam
-ELisp Package Global Variables}) for further training or deletion.
-You have to load the @code{gnus-registry.el} package and enable the
-@code{spam-log-to-registry} variable if you want spam to be processed
-no more than once. Thus, spam is detected and processed everywhere,
-which is what most people want. If the
-@code{spam-process-destination} is @code{nil}, the spam is marked as
-expired, which is usually the right thing to do.
-
-If spam can not be moved---because of a read-only back end such as
-@acronym{NNTP}, for example, it will be copied.