From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/48890 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Trouble with spam.el and ifile Date: Tue, 07 Jan 2003 17:07:23 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: owner-ding@hpc.uh.edu Message-ID: <4n1y3owr50.fsf@lockgroove.bwh.harvard.edu> References: <4nadic3fo1.fsf@lockgroove.bwh.harvard.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1041977279 18103 80.91.224.249 (7 Jan 2003 22:07:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2003 22:07:59 +0000 (UTC) Cc: ding@gnus.org Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18W1t0-0004hP-00 for ; Tue, 07 Jan 2003 23:07:50 +0100 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 18W1st-00048G-00; Tue, 07 Jan 2003 16:07:43 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 07 Jan 2003 16:08:37 -0600 (CST) Original-Received: from sclp3.sclp.com (sclp3.sclp.com [66.230.238.2]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id QAA11994 for ; Tue, 7 Jan 2003 16:08:23 -0600 (CST) Original-Received: (qmail 2550 invoked by alias); 7 Jan 2003 22:07:25 -0000 Original-Received: (qmail 2545 invoked from network); 7 Jan 2003 22:07:25 -0000 Original-Received: from clifford.bwh.harvard.edu (134.174.9.41) by 66.230.238.6 with SMTP; 7 Jan 2003 22:07:25 -0000 Original-Received: from lockgroove.bwh.harvard.edu (lockgroove [134.174.9.133]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id h07M7NW29497; Tue, 7 Jan 2003 17:07:23 -0500 (EST) Original-Received: (from tzz@localhost) by lockgroove.bwh.harvard.edu (8.11.6+Sun/8.11.0) id h07M7Nt23161; Tue, 7 Jan 2003 17:07:23 -0500 (EST) Original-To: David Z Maze X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: David Z Maze , ding@gnus.org In-Reply-To: (David Z Maze's message of "Tue, 07 Jan 2003 16:05:40 -0500") User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2 (sparc-sun-solaris2.8) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:48890 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:48890 On Tue, 07 Jan 2003, dmaze@MIT.EDU wrote: > The custom interface still doesn't make things really clear. (And I > missed things doing C-h v spam-, because some of the variables > are gnus-spam-*.) That's because they are in gnus.el, and are Gnus-global variables rather than spam.el variables. If Lars or other Gnus people think I should rename them, no problem (but it will break existing setups). > But now I have > > gnus-spam-newsgroup-contents '(("mail.misc.spam" gnus-group-spam-classification-spam)) > gnus-spam-process-newsgroups '((".*" (gnus-group-spam-exit-processor-ifile))) > gnus-spam-process-destinations '((".*" "nnml:mail.misc.spam")) > spam-junk-mailgroups '("mail.misc.spam") > spam-split-group "mail.misc.spam" > spam-use-ifile t > > Is this right? Yes. It says "mail.misc.spam is a spam group; all my groups should be spam-processed with ifile; all spam articles should be moved to mail.misc.spam after spam proecsssing; all my incoming spam should be filtered, through ifile, into mail.misc.spam." > It should be clearer in the documentation/Customize descriptions > where you need the backend prefix and where you don't. Yeah, the docs need work for sure. I've been trying to get the package functionality in place first. > It looks like all of this is set up with > gnus-define-group-parameter, and examples with e.g. expiry suggest > you don't want it I'm not sure what you mean. > it still doesn't seem to work for me either way. Now at least > incoming articles get filed properly, but if I find a misclassified > spam article and run 'S x' on it, it gets the 'H' mark but nothing > happens when I exit the group. This happens both with and without > the nnml: prefix in the regexps above. You don't need the prefix. Let's start with just the "spam" groups for spam-contents and spam-process: gnus-spam-newsgroup-contents '(("spam" gnus-group-spam-classification-spam)) gnus-spam-process-newsgroups '(("spam" (gnus-group-spam-exit-processor-ifile))) See if that triggers the ifile spam processing on summary exit. You must have some spam-marked articles. You can test the processing manually with M-: (spam-summary-prepare-exit) - that's the function that gets invoked at summary exit. >> The 'Y' mark stands for a lowered score, right? spam.el only marks >> unread articles as spam on summary entry in a spam group, and only >> processes spam-marked articles with the group's spam processors on >> summary exit (for any group, not just spam groups). > > Aha. This makes it a little trickier for me to test, since most of > my spam happens to have a low score in my spam group. You can customize spam-spam-marks to include the low score mark, not just the spam-mark. > If I mark an article not-spam in the spam group, does it get refiled > to the next best group on exit? No. You have to move it manually (but that functionality could be added). I assume you mean "mark unread," since there is no not-spam mark. An unread article is not ham or spam, it's unclassified. The spam-ham-marks only matter in a ham group, only in such a group are they considered by the ham processor. > Also, part of Jeremy Brown's ifile-gnus distribution is a Bourne > shell script that can scan an nnml directory tree and prime ifile > with your extant messages. It might be good to incorporate this or > something like it into Gnus. I can do that. > (This is especially true for spam-stat; doing this classification > entirely in elisp looks like it might be a big performance win over > ifile, I haven't tested the performance, but ifile definitely has better lexing than spam-stat according to the documentation. Ted