How to use the spam.el package?

How to use the spam.el package?

[Kai Grossjohann]

I tried several times to configure spam.el for my use.  Finally, I
came up with the outside-Gnus setup that I want to use, and so I gave
spam.el another go.

I'm sending this here to ask whether my configuration looks sane and
to report some findings where the documentation was confusing.

My configuration looks like this:

;; Spam
(setq spam-use-bogofilter-headers t)
(setq spam-split-group "INBOX.spam")
(setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam"))
(setq gnus-spam-process-newsgroups
      '(("^nnimap:INBOX" nil)))
(setq gnus-spam-process-destinations
      '(("^nnimap:INBOX" "nnimap:INBOX.makespam")))
(spam-initialize)

;; and then:
(setq nnimap-split-fancy '(| (: spam-split) ... "INBOX.misc"))

I'm reading mail from a Cyrus server with the following setup:
Incoming messages are passed through bogofilter before Cyrus sees
them.  There is a cron job which goes through all INBOX.makespam and
INBOX.makeham folders for all users and classifies messages found
there as spam or ham respectively.

So what I want is this: Incoming spam should be split into
nnimap:INBOX.spam.  Hitting M-d on a message should send it to the
nnimap:INBOX.makespam group, where it will be picked up by the Cron
job later.  Also, marking something as ham in a spam group should
result in that message being moved to nnimap:INBOX, I guess.  (There,
nnimap-split-fancy will find it again, and then hopefully won't
consider it spam again.)

Things I found:

* The docs say "First of all, you *must* run the function
  `spam-initialize' to autoload `spam.el' and to install the `spam.el'
  hooks".  In fact, however, it seems that spam-initialize should come
  /last/, not first: its behavior depends on the other variables being
  set.

  I like obscure jokes just as well as the next person, but maybe a
  hint for the uninitiated would be nice?

* I /think/ that spam-split-group should be a naked group name whereas
  all the other variables should be fully qualified group names.  It
  isn't made clear in the documentation.

* The format of gnus-spam-process-newsgroups and
  gnus-spam-process-destinations isn't made clear, neither in info nor
  in C-h v.  I suggest to say something like "this should be a list of
  newsgroup specifications.  Each newsgroup specification has the
  format (REGEXP PROCESSOR)".

  I found out what to do by running M-x customize-variable RET and
  then looking at the resulting Lisp expression, but why not make it
  explicit?

* I wasn't sure that just setting the processor to nil was the right
  thing to do, I was just operating on a hunch that it might work.
  How about making this explicit, too?

* I would also appreciate some tutorial kind of advice, like saying
  for the following common situation, this is how you set the
  variables.  It's difficult to figure out how it all ties together:
  you have to read all of the main node on spam.el and /understand/
  it, too, if you want to configure things.

  I guess there are numerous mistakes in my config, but for the time
  being it works, and the smoke coming from my head is making the room
  foggy.

* How do I tell spam.el that messages from nnimap:INBOX.spam and
  nnimap:INBOX.makespam don't need to be frobbed further?  I'm afraid
  they'll be subjected to gnus-spam-process-destinations...

* I completely ignored the group parameters thing, even though it
  seemed the easiest way to configure stuff.  The reason for doing so
  was that I didn't fancy setting the same spam process destination on
  all my groups.  (I just switched to a new server and haven't
  switched on topics mode, yet.)


I hope that the above stupid questions are useful for something.  I'd
like to promise to help improving the documentation, but what with
real life and a job, my time has been more limited than some months
ago.


Now let me go talk to the Bogofilter folks about setting up the
server-side splitting thing.

Kai

Re: How to use the spam.el package?

[Ted Zlatanov]

On Sat, 01 Nov 2003, kai@emptydomain.de wrote:
> (setq spam-use-bogofilter-headers t)
> (setq spam-split-group "INBOX.spam")
> (setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam"))
> (setq gnus-spam-process-newsgroups
>       '(("^nnimap:INBOX" nil)))
> (setq gnus-spam-process-destinations
>       '(("^nnimap:INBOX" "nnimap:INBOX.makespam")))
> (spam-initialize)

You don't need to explicitly define the spam-process parameter - it's
nil by default, as one would expect.  Everything else looks fine.

> I'm reading mail from a Cyrus server with the following setup:
> Incoming messages are passed through bogofilter before Cyrus sees
> them.  There is a cron job which goes through all INBOX.makespam and
> INBOX.makeham folders for all users and classifies messages found
> there as spam or ham respectively.

Great.

> So what I want is this: Incoming spam should be split into
> nnimap:INBOX.spam.  Hitting M-d on a message should send it to the
> nnimap:INBOX.makespam group, where it will be picked up by the Cron
> job later.  Also, marking something as ham in a spam group should
> result in that message being moved to nnimap:INBOX, I guess.
> (There, nnimap-split-fancy will find it again, and then hopefully
> won't consider it spam again.)

That's sensible.  Just don't try to split spam from INBOX right back
into INBOX - that can cause problems.

> Things I found:
> 
> * The docs say "First of all, you *must* run the function
>   `spam-initialize' to autoload `spam.el' and to install the
>   `spam.el' hooks".  In fact, however, it seems that spam-initialize
>   should come /last/, not first: its behavior depends on the other
>   variables being set.
> 
>   I like obscure jokes just as well as the next person, but maybe a
>   hint for the uninitiated would be nice?

The docs are correct.  The behavior of spam-initialize will not be
affected by any spam.el variables, except for spam-use-stat which adds
some hooks (the spam-use-stat exception should probably be in the
manual).

> * I /think/ that spam-split-group should be a naked group name
>   whereas all the other variables should be fully qualified group
>   names.  It isn't made clear in the documentation.

You are correct.  I have clarified it.

> * The format of gnus-spam-process-newsgroups and
>   gnus-spam-process-destinations isn't made clear, neither in info
>   nor in C-h v.  I suggest to say something like "this should be a
>   list of newsgroup specifications.  Each newsgroup specification
>   has the format (REGEXP PROCESSOR)".

>   I found out what to do by running M-x customize-variable RET and
>   then looking at the resulting Lisp expression, but why not make it
>   explicit?

I have added this clarification.  I strongly prefer that users use the
customize interface, so I don't want to provide code samples for
setting the variables manually.  If you do, please write them and add
them to the manual.  I have no problem with that.

> * I wasn't sure that just setting the processor to nil was the right
>   thing to do, I was just operating on a hunch that it might work.
>   How about making this explicit, too?

Why?  It makes perfect sense that if you don't explicitly set a
processor, there won't be one.  I don't want to confuse the users
more than they need to be :)

> * I would also appreciate some tutorial kind of advice, like saying
>   for the following common situation, this is how you set the
>   variables.  It's difficult to figure out how it all ties together:
>   you have to read all of the main node on spam.el and /understand/
>   it, too, if you want to configure things.

Sure.  I welcome any contributions in that direction.  Integration of
spam.el with the registry plus making the registry work properly in
all cases are higher on my priority list.

> * How do I tell spam.el that messages from nnimap:INBOX.spam and
>   nnimap:INBOX.makespam don't need to be frobbed further?  I'm
>   afraid they'll be subjected to gnus-spam-process-destinations...

If the messages in those groups are marked as spam, they will be
moved to the spam-process-destination whether there is or isn't a
spam processor.  So don't set a spam-process-destination if you don't
want one, ditto for the spam-processor.  Is that what you're asking?

> * I completely ignored the group parameters thing, even though it
>   seemed the easiest way to configure stuff.  The reason for doing
>   so was that I didn't fancy setting the same spam process
>   destination on all my groups.  (I just switched to a new server
>   and haven't switched on topics mode, yet.)

Yeah, unfortunately group/topic parameters are incredibly easy and
convenient for this task, so I'd rather have the user use that than
write Lisp code.

> I hope that the above stupid questions are useful for something.
> I'd like to promise to help improving the documentation, but what
> with real life and a job, my time has been more limited than some
> months ago.

No problem, I appreciate the suggestions.

Ted

Re: How to use the spam.el package?

[Kai Grossjohann]

Another aside: with the previously described config, marking some
messages as spam with M-d, then exiting the group, asks me "Really
delete these 42 messages forever?"

"Which 42 messages?" I think.  "It must be the spam ones.  But I
didn't tell it to delete the messages, just move them to
nnimap:INBOX.spam..."

8-)

Re: How to use the spam.el package?

[Ted Zlatanov]

On Mon, 03 Nov 2003, kai@emptydomain.de wrote:

> Another aside: with the previously described config, marking some
> messages as spam with M-d, then exiting the group, asks me "Really
> delete these 42 messages forever?"
> 
> "Which 42 messages?" I think.  "It must be the spam ones.  But I
> didn't tell it to delete the messages, just move them to
> nnimap:INBOX.spam..."

Are you sure you're using the latest CVS?  This was fixed last week,
I believe.

Ted

Re: How to use the spam.el package?

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Sat, 01 Nov 2003, kai@emptydomain.de wrote:
>> (setq spam-use-bogofilter-headers t)
>> (setq spam-split-group "INBOX.spam")
>> (setq spam-junk-mailgroups (list "nnimap:INBOX.spam" "nnimap:INBOX.makespam"))
>> (setq gnus-spam-process-newsgroups
>>       '(("^nnimap:INBOX" nil)))
>> (setq gnus-spam-process-destinations
>>       '(("^nnimap:INBOX" "nnimap:INBOX.makespam")))
>> (spam-initialize)
>
> You don't need to explicitly define the spam-process parameter - it's
> nil by default, as one would expect.  Everything else looks fine.

Errm, you mean gnus-spam-process-newsgroups?  Okay, so I can take that
out, I guess.

>> I'm reading mail from a Cyrus server with the following setup:
>> Incoming messages are passed through bogofilter before Cyrus sees
>> them.  There is a cron job which goes through all INBOX.makespam and
>> INBOX.makeham folders for all users and classifies messages found
>> there as spam or ham respectively.
>
> Great.

Heh, I'm somewhat self-satisfied with having achieved this setup.
Goes to show you how much I've been out of touch with doing any real
work...  I even had to ask folks in a (German) newsgroup about the
shell and perl scripts I use for Bogofilter training...

>> So what I want is this: Incoming spam should be split into
>> nnimap:INBOX.spam.  Hitting M-d on a message should send it to the
>> nnimap:INBOX.makespam group, where it will be picked up by the Cron
>> job later.  Also, marking something as ham in a spam group should
>> result in that message being moved to nnimap:INBOX, I guess.
>> (There, nnimap-split-fancy will find it again, and then hopefully
>> won't consider it spam again.)
>
> That's sensible.  Just don't try to split spam from INBOX right back
> into INBOX - that can cause problems.

I must have done a mistake: I tried to tell Bogofilter that messages
in INBOX.makeham aren't spam, then put them back in INBOX.  Then they
were split again as spam.

Oh, wait!

Stupid me: I should be deleting the X-Bogosity header from messages
that were made ham.  Gnahh :-/  *bangs head against wall*

>> Things I found:
>> 
>> * The docs say "First of all, you *must* run the function
>>   `spam-initialize' to autoload `spam.el' and to install the
>>   `spam.el' hooks".  In fact, however, it seems that spam-initialize
>>   should come /last/, not first: its behavior depends on the other
>>   variables being set.
>> 
>>   I like obscure jokes just as well as the next person, but maybe a
>>   hint for the uninitiated would be nice?
>
> The docs are correct.  The behavior of spam-initialize will not be
> affected by any spam.el variables, except for spam-use-stat which adds
> some hooks (the spam-use-stat exception should probably be in the
> manual).

Hm.  Ooops.  But what about spam-install-hooks?  That seems to be set
to something depending on spam-use-foo upon loading spam.el, so if I
call spam-initialize first, then frob spam-use-foo, then it's too
late.  So I'll also have to set spam-install-hooks, right?

[time passes]

D'oh.  spam-install-hooks just arranges for spam-initialize to be
called, which it was already.  So no harm done.

*blush*

>> * I /think/ that spam-split-group should be a naked group name
>>   whereas all the other variables should be fully qualified group
>>   names.  It isn't made clear in the documentation.
>
> You are correct.  I have clarified it.

At least one observation in this message that wasn't wrong.

>> * The format of gnus-spam-process-newsgroups and
>>   gnus-spam-process-destinations isn't made clear, neither in info
>>   nor in C-h v.  I suggest to say something like "this should be a
>>   list of newsgroup specifications.  Each newsgroup specification
>>   has the format (REGEXP PROCESSOR)".
>
>>   I found out what to do by running M-x customize-variable RET and
>>   then looking at the resulting Lisp expression, but why not make it
>>   explicit?
>
> I have added this clarification.  I strongly prefer that users use the
> customize interface, so I don't want to provide code samples for
> setting the variables manually.  If you do, please write them and add
> them to the manual.  I have no problem with that.

Okay.

>> * I wasn't sure that just setting the processor to nil was the right
>>   thing to do, I was just operating on a hunch that it might work.
>>   How about making this explicit, too?
>
> Why?  It makes perfect sense that if you don't explicitly set a
> processor, there won't be one.  I don't want to confuse the users
> more than they need to be :)

Well, spam is being processed by Bogofilter in my case.  Or, put
another way, the processing I do on spam is to move it to INBOX.spam.

Maybe I'm just being too stupid.

>> * I would also appreciate some tutorial kind of advice, like saying
>>   for the following common situation, this is how you set the
>>   variables.  It's difficult to figure out how it all ties together:
>>   you have to read all of the main node on spam.el and /understand/
>>   it, too, if you want to configure things.
>
> Sure.  I welcome any contributions in that direction.  Integration of
> spam.el with the registry plus making the registry work properly in
> all cases are higher on my priority list.

Ah, yes, I should have expected the please-do-it answer ;-)
Sorry that I didn't just do it in the first place, but came here
whining instead.

>> * How do I tell spam.el that messages from nnimap:INBOX.spam and
>>   nnimap:INBOX.makespam don't need to be frobbed further?  I'm
>>   afraid they'll be subjected to gnus-spam-process-destinations...
>
> If the messages in those groups are marked as spam, they will be
> moved to the spam-process-destination whether there is or isn't a
> spam processor.  So don't set a spam-process-destination if you don't
> want one, ditto for the spam-processor.  Is that what you're asking?

I want spam to be moved to INBOX.spam.  But it doesn't make sense
(IMHO) to move messages from INBOX.spam to INBOX.spam.  I see an
infloop lurking there.

But it turns out that I haven't experienced that infloop yet.  Soooo,
there must be something (yet again) I'm missing.

>> * I completely ignored the group parameters thing, even though it
>>   seemed the easiest way to configure stuff.  The reason for doing
>>   so was that I didn't fancy setting the same spam process
>>   destination on all my groups.  (I just switched to a new server
>>   and haven't switched on topics mode, yet.)
>
> Yeah, unfortunately group/topic parameters are incredibly easy and
> convenient for this task, so I'd rather have the user use that than
> write Lisp code.

;-)

Kai

Re: How to use the spam.el package?

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Are you sure you're using the latest CVS?  This was fixed last week,
> I believe.

Oops.  I was too busy to even think of upgrading.  Gnah :-/

CVS is now running.

Kai

Re: How to use the spam.el package?

[Ted Zlatanov]

On Mon, 03 Nov 2003, kai@emptydomain.de wrote:
> Hm.  Ooops.  But what about spam-install-hooks?  That seems to be
> set to something depending on spam-use-foo upon loading spam.el, so
> if I call spam-initialize first, then frob spam-use-foo, then it's
> too late.  So I'll also have to set spam-install-hooks, right?

You used to have to do it.  The new way is to just call the
autoloaded spam-initialize, which will (we hope) do everything
properly, and if it doesn't it will be fixed.

> *blush*

It's really OK to have these questions - as you can see, you've
already pointed out several problems or unclear spots in the docs.

>>> * I wasn't sure that just setting the processor to nil was the
>>>   right thing to do, I was just operating on a hunch that it might
>>>   work.  How about making this explicit, too?
>>
>> Why?  It makes perfect sense that if you don't explicitly set a
>> processor, there won't be one.  I don't want to confuse the users
>> more than they need to be :)
> 
> Well, spam is being processed by Bogofilter in my case.  Or, put
> another way, the processing I do on spam is to move it to
> INBOX.spam.

OK, how would you suggest I change the docs and/or implementation?  I
understand the problem, I'm just not sure how I can fix it.

>>> * I would also appreciate some tutorial kind of advice, like
>>>   saying for the following common situation, this is how you set
>>>   the variables.  It's difficult to figure out how it all ties
>>>   together: you have to read all of the main node on spam.el and
>>>   /understand/ it, too, if you want to configure things.
>>
>> Sure.  I welcome any contributions in that direction.  Integration
>> of spam.el with the registry plus making the registry work properly
>> in all cases are higher on my priority list.
> 
> Ah, yes, I should have expected the please-do-it answer ;-)
> Sorry that I didn't just do it in the first place, but came here
> whining instead.

You misunderstood, I'm not opposed to writing the tutorials myself,
and in fact I probably will if no one else does.  I just want to
finish what I consider essential functionality first, in time for the
new Gnus release I hope.

>>> * How do I tell spam.el that messages from nnimap:INBOX.spam and
>>>   nnimap:INBOX.makespam don't need to be frobbed further?  I'm
>>>   afraid they'll be subjected to gnus-spam-process-destinations...
>>
>> If the messages in those groups are marked as spam, they will be
>> moved to the spam-process-destination whether there is or isn't a
>> spam processor.  So don't set a spam-process-destination if you
>> don't want one, ditto for the spam-processor.  Is that what you're
>> asking?
> 
> I want spam to be moved to INBOX.spam.  But it doesn't make sense
> (IMHO) to move messages from INBOX.spam to INBOX.spam.  I see an
> infloop lurking there.

Nah, we move message by unique article number, not message ID.  The
new articles that were just moved in are not automatically integrated
in the loop, so it will end when the old articles are all moved.  It
should work.  I wouldn't recommend it, but for pure obfuscated fun
it's hard to beat it.

Ted

Re: How to use the spam.el package?

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 03 Nov 2003, kai@emptydomain.de wrote:
>> 
>> I want spam to be moved to INBOX.spam.  But it doesn't make sense
>> (IMHO) to move messages from INBOX.spam to INBOX.spam.  I see an
>> infloop lurking there.
>
> Nah, we move message by unique article number, not message ID.  The
> new articles that were just moved in are not automatically integrated
> in the loop, so it will end when the old articles are all moved.  It
> should work.  I wouldn't recommend it, but for pure obfuscated fun
> it's hard to beat it.

Okay.  So, it's better to avoid it.  Recall that I have
gnus-spam-process-destinations set to (("^nnimap:"
"nnimap:INBOX.makespam")).  (Made a mistake makespam vs spam there.)

So how do I tell spam.el NOT to apply this rule to the
nnimap:INBOX.makespam group?  Formulating a regexp that matches
everything that "^nnimap:" matches, except "nnimap:INBOX.makespam", is
difficult.

Hm.  Maybe I could set a group parameter on nnimap:INBOX.makespam that
overrides the value with nil?

Or I could put in two entries:

    (("^nnimap:INBOX.makespam$" nil)
     ("^nnimap:" "nnimap:INBOX.makespam"))

If it searches the alist from the beginning and uses the first match,
then it would work.

It's getting a bit complicated.  I'm sure the reason is that I'm doing
something wrong.  I stumbled across this thing within five minutes;
everybody must be having the same issue.  Except, of course, if they
take another path where there is no stumbling block.

Do people put all ham groups in one topic and all spam groups in
another, then use topic parameters on those two topics, to avoid this
problem?

Kai

Re: How to use the spam.el package?

[Ted Zlatanov]

On Mon, 03 Nov 2003, kai@emptydomain.de wrote:

>> Nah, we move message by unique article number, not message ID.  The
>> new articles that were just moved in are not automatically
>> integrated in the loop, so it will end when the old articles are
>> all moved.  It should work.  I wouldn't recommend it, but for pure
>> obfuscated fun it's hard to beat it.
> 
> Okay.  So, it's better to avoid it.  Recall that I have
> gnus-spam-process-destinations set to (("^nnimap:"
> "nnimap:INBOX.makespam")).  (Made a mistake makespam vs spam there.)
> 
> So how do I tell spam.el NOT to apply this rule to the
> nnimap:INBOX.makespam group?  Formulating a regexp that matches
> everything that "^nnimap:" matches, except "nnimap:INBOX.makespam",
> is difficult.
> 
> Hm.  Maybe I could set a group parameter on nnimap:INBOX.makespam
> that overrides the value with nil?

That's what I do.  I also have ham/spam topics, and some of my
settings are different depending on the backend server.

> Or I could put in two entries:
> 
>     (("^nnimap:INBOX.makespam$" nil)
>      ("^nnimap:" "nnimap:INBOX.makespam"))
> 
> If it searches the alist from the beginning and uses the first
> match, then it would work.

I would guess it searches from the beginning, it's a standard Elisp
alist.

> It's getting a bit complicated.  I'm sure the reason is that I'm
> doing something wrong.  I stumbled across this thing within five
> minutes; everybody must be having the same issue.  Except, of
> course, if they take another path where there is no stumbling block.
> 
> Do people put all ham groups in one topic and all spam groups in
> another, then use topic parameters on those two topics, to avoid
> this problem?

I think the configurability of the package makes it hard to say one
way is "right" and another is "wrong."  It's a safe guess that most
people are using group/topic parameters based on the configurations
I've been asked to debug.

Ted

Re: How to use the spam.el package?

[Kai Grossjohann]

Kai Grossjohann <kai@emptydomain.de> writes:

> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>> Are you sure you're using the latest CVS?  This was fixed last week,
>> I believe.
>
> Oops.  I was too busy to even think of upgrading.  Gnah :-/

The new version works fine.  Great!

Kai

Re: How to use the spam.el package?

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Mon, 03 Nov 2003, kai@emptydomain.de wrote:
>> 
>> Well, spam is being processed by Bogofilter in my case.  Or, put
>> another way, the processing I do on spam is to move it to
>> INBOX.spam.
>
> OK, how would you suggest I change the docs and/or implementation?  I
> understand the problem, I'm just not sure how I can fix it.

I think it's better to change the docs.  The behavior makes sense:
moving spam to a destination group is something that can be done in
addition to other processing.

(The alternative would be to provide a list of actions, such that
moving to another group could be part of it.  But that would make the
configuration more complex for no apparent gain.)

Maybe you could extend the description of M-d.  Perhaps like this:

    Marking a message as spam means that Gnus might do two things with
    it.  First, it can analyze the message (we call it "spam
    processing"), and secondly it can move the message to another
    group (which is called the "process destination").  Read on for
    more on spam processing and process destinations.

Further down, it says "you have to collect your spam in one or more
spam groups, and set spam-junk-mailgroups appropriately".  The
following questions come up when you're naive:  How to collect the spam
in spam groups?  Of course, the answer is by hitting M-d and then
relying on the process destination to do the collecting.  But the docs
don't say :-)

And secondly, why do I *have* to set spam-junk-mailgroups?  Isn't it
enough to just process the spam?  How does spam-junk-mailgroups come
in?  Why do I need a group where all new articles get the spam mark
automatically?  Say I use the black/whitelist thing.  Then why is it
not sufficient to just blacklist the sender, then delete the spam?



I also mentioned a tutorial-type example.  It seems that you use
spam.el in the "normal" way, in the way that spam.el was intended to
be used.  So how about you describe your setup, explaining what each
configuration item does?  Something along these lines:

    I set nnmail-split-fancy like this: ....  This invokes spam-split
    which puts spam into a specific group.  This group is specified by
    the spam-split-group variable.  I have (setq spam-split-group
    "incoming-spam"), so spam-split will put spam into the
    nnml:incoming-spam group.  From time to time, I enter that group
    to check whether messages in that group are really spam.  If I
    encounter any ham, I hit M-u on it.  When exiting the group, the
    spam from nnml:incoming-spam is moved to nnml:train-spam and the
    ham is moved to nnml:train-ham.  I do this by setting the group
    parameter spam-process-destination to nnml:train-spam and
    ham-process-destination to nnml:train-ham.  I then use
    nnml:train-spam and nnml:train-ham for bogofilter training.  I set
    the spam-processor group parameter for nnml:train-spam to
    gnus-group-spam-exit-processor-bogofilter, and for the group
    nnml:train-ham I set the ham-processor group parameter to
    gnus-group-ham-exit-processor-bogofilter.  After being processed
    by bogofilter, spam from nnml:train-spam will be deleted because
    of the foo setting.  (Ed. note: which setting?)  And ham from
    nnml:train-ham will be moved to nnml:mail.misc because I set the
    group parameter ham-process-destination on nnml:train-ham
    accordingly.

In the above description, I tried to guess what your, Ted's, setup
might be.  I'm sure it's wrong.  But maybe you get the idea of what I
mean by showing the connection.

In fact, I think that lengthy paragraph is still too difficult to
understand to see the big picture.  Hm.  We need a summary explaining
just what happens.  Maybe a drawing would be nice?  But I'm really bad
at drawing...  So, maybe the above should be split into a description
what happens and then a description of the settings that are needed to
make it happen.

WDYT?

I could also describe my setup, but I'm afraid that's not really
typical.  After all, I try to make it server-based, and I guess most
users don't have their own server.

Kai