Re: How to use the spam.el package?

[Ted Zlatanov <tzz@lifelogs.com>]

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