From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/49294 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: spam filtering using IMAP ? Date: Thu, 16 Jan 2003 06:22:17 -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: <4ny95l7312.fsf@lockgroove.bwh.harvard.edu> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1042716116 1546 80.91.224.249 (16 Jan 2003 11:21:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 16 Jan 2003 11:21:56 +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 18Z85q-0000Om-00 for ; Thu, 16 Jan 2003 12:21:54 +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 18Z86c-00060w-00; Thu, 16 Jan 2003 05:22:42 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 16 Jan 2003 05:23:38 -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 FAA12817 for ; Thu, 16 Jan 2003 05:23:25 -0600 (CST) Original-Received: (qmail 79307 invoked by alias); 16 Jan 2003 11:22:24 -0000 Original-Received: (qmail 79302 invoked from network); 16 Jan 2003 11:22:24 -0000 Original-Received: from clifford.bwh.harvard.edu (134.174.9.41) by 66.230.238.6 with SMTP; 16 Jan 2003 11:22:24 -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 h0GBMHW13260; Thu, 16 Jan 2003 06:22:17 -0500 (EST) Original-Received: (from tzz@localhost) by lockgroove.bwh.harvard.edu (8.11.6+Sun/8.11.0) id h0GBMH522428; Thu, 16 Jan 2003 06:22:17 -0500 (EST) Original-To: Mats Lidell 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: Mats Lidell , ding@gnus.org In-Reply-To: (Mats Lidell's message of "Thu, 16 Jan 2003 11:43:31 +0100") User-Agent: Gnus/5.090013 (Oort Gnus v0.13) Emacs/21.2 (sparc-sun-solaris2.8) Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:49294 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:49294 On Thu, 16 Jan 2003, matsl@contactor.se wrote: > I haven't designed the details (much less tested it) but what I > envision is to move an article that is spam and not classified as > such to one folder, lets say mark-as-spam, and move good articles > that are classified as spam to another folder, lets say > mark-as-ham. How do you know if an article is spam or ham? The user has to determine that, right? Or are you talking about automated server-side classification? I'm a little confused, maybe it would help if you did a scenario of what happens to a message on the mail server and on the client machine - what programs get invoked, what the user has to do... > Then I would have some server code that feeds these articles to the > spam statistics engine and at the same time move the mark-as-spam > articles to the spam folder and the mark-as-ham articles to the > inbox(!?). I'm not sure how doing this on the server makes a big difference. spam.el supports all that on the client side, and the only penalty you pay is retrieving the article body. Maybe you want to have a single place to store message statistics? You could run Gnus on the server, I guess... > It is here that spam.el comes in for supporting this scheme in > gnus. If I get how this works it uses different marks to > intelligently find out whether articles need reclassification based > also on normal operations on the article. (Philosophy: If I do this > with the article then it must be spam or it must be ham.) > On the other hand a very natural thing to do with ham found in the > spam folder is to move them directly to the folder where they should > be. This deletes the article in the spam folder and I don't know if > spam.el on exit from the summary buffer will be able to access the > article so that it could be copied to the mark-as-ham folder for > later statistics processing. There's the spam-process-destination and ham-process-destination group parameters, which let you move spam or ham articles at summary exit. You can set them for a group, a topic, or a regex matching the group name. They are set to nil by default, which means "expire spam, leave ham alone." When you set those parameters, spam articles get moved from any group into a spam-process-destination group. Ham articles must be in a spam group to be moved to a ham-process-destination. Is that helpful? Or do you have something else in mind? You should probably look at the CVS Gnus manual if you haven't already. It explains all the spam.el behavior and parameters. Thanks Ted