Re: How to use the spam.el package?

[Kai Grossjohann <kai@emptydomain.de>]

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