From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/54640 Path: main.gmane.org!not-for-mail From: Kai Grossjohann Newsgroups: gmane.emacs.gnus.general Subject: Re: How to use the spam.el package? Date: Mon, 03 Nov 2003 20:26:32 +0000 Sender: ding-owner@lists.math.uh.edu Message-ID: <87u15lryfb.fsf@emptyhost.emptydomain.de> References: <87brrv269g.fsf@emptyhost.emptydomain.de> <4nptg947ta.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067891228 412 80.91.224.253 (3 Nov 2003 20:27:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2003 20:27:08 +0000 (UTC) Original-X-From: ding-owner+M3181@lists.math.uh.edu Mon Nov 03 21:27:03 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AGlHz-00006u-00 for ; Mon, 03 Nov 2003 21:27:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1AGlHr-0004KA-00; Mon, 03 Nov 2003 14:26:55 -0600 Original-Received: from justine.libertine.org ([66.139.78.221]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1AGlHi-0004JB-00 for ding@lists.math.uh.edu; Mon, 03 Nov 2003 14:26:46 -0600 Original-Received: from quimby.gnus.org (quimby.gnus.org [80.91.224.244]) by justine.libertine.org (Postfix) with ESMTP id 893A23A0079 for ; Mon, 3 Nov 2003 14:26:45 -0600 (CST) Original-Received: from news by quimby.gnus.org with local (Exim 3.35 #1 (Debian)) id 1AGlHh-0003V8-00 for ; Mon, 03 Nov 2003 21:26:45 +0100 Original-To: ding@gnus.org Original-Path: not-for-mail Original-Newsgroups: gnus.ding Original-Lines: 160 Original-NNTP-Posting-Host: 213-203-244-156.kunde.vdserver.de Original-X-Trace: quimby.gnus.org 1067891204 13461 213.203.244.156 (3 Nov 2003 20:26:44 GMT) Original-X-Complaints-To: usenet@quimby.gnus.org Original-NNTP-Posting-Date: Mon, 3 Nov 2003 20:26:44 +0000 (UTC) User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.2 (gnu/linux) Cancel-Lock: sha1:8JoBsdK3ZQu7iVCFZ2j7/JwfT/4= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:54640 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:54640 Ted Zlatanov 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