From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/52272 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: A different spam model, which might be possible already Date: Sun, 04 May 2003 18:32:45 -0400 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4nd6iyl4vm.fsf@lockgroove.bwh.harvard.edu> References: <87n0i4g3u2.fsf@egil.codesourcery.com> <87znm2ekdu.fsf@egil.codesourcery.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1052087519 9627 80.91.224.249 (4 May 2003 22:31:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 4 May 2003 22:31:59 +0000 (UTC) Cc: replies@frank-schmitt.net, ding@gnus.org Original-X-From: ding-owner+M815@lists.math.uh.edu Mon May 05 00:31:57 2003 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 19CS1U-0002V9-00 for ; Mon, 05 May 2003 00:31:57 +0200 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 19CS2X-0002BD-00; Sun, 04 May 2003 17:33:01 -0500 Original-Received: from sclp3.sclp.com ([64.157.176.121]) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 19CS2P-0002B7-00 for ding@lists.math.uh.edu; Sun, 04 May 2003 17:32:53 -0500 Original-Received: (qmail 72833 invoked by alias); 4 May 2003 22:32:53 -0000 Original-Received: (qmail 72827 invoked from network); 4 May 2003 22:32:53 -0000 Original-Received: from clifford.bwh.harvard.edu (134.174.9.41) by sclp3.sclp.com with SMTP; 4 May 2003 22:32:53 -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 h44MWjI10481; Sun, 4 May 2003 18:32:45 -0400 (EDT) Original-Received: (from tzz@localhost) by lockgroove.bwh.harvard.edu (8.11.6+Sun/8.11.0) id h44MWjZ08667; Sun, 4 May 2003 18:32:45 -0400 (EDT) Original-To: Zack Weinberg 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: Zack Weinberg , replies@Frank-Schmitt.net, ding@gnus.org In-Reply-To: <87znm2ekdu.fsf@egil.codesourcery.com> (Zack Weinberg's message of "Sun, 04 May 2003 09:39:41 -0700") User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:52272 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:52272 On Sun, 04 May 2003, zack@codesourcery.com wrote: > Ted Zlatanov writes: > >>> * If I do 'B m' on message(s) in the spam group, they >>> automagically get their $ mark removed. >> >> Currently, the behavior is the reverse: if the articles have a >> ham-mark in a spam group (see the ham-marks group parameter) they >> will be moved out of the spam group to the ham-process-destination >> group after being processed with the group's ham processors. What >> you describe could be coded as alternate behavior, but I don't see >> the advantage (see later about article moving and tracking). > > The trouble with ham-process-destination is there isn't just one ham > group. Most of the false positives I get with the current static > database belong to various mailing lists. But I don't use > splitting, so Gnus doesn't have any way of knowing which > mailing-list folder a message belongs to. Hence, I need to specify > it by hand, using 'B m'. We could make ham-process-destination a function in addition to a plain string, and have the function invoked on each spam message to return a string. It can be similar for spam-process-destination and ham messages. Would that help, or must you use manual move? It's unfortunate you don't use splitting, that would make things easier. Anyhow, if none of the suggestions work for you, we can certainly implement the move-then-mark behavior in spam.el. I don't think it will be too hard, in fact it can coexist with the mark-then-move behavior pretty cleanly. >> I'm not sure what's the benefit of doing the article move on the >> server side. Isn't it better to let Gnus do the move, since it >> will involve about the same amount of (minimal) network traffic? >> Or is the nnimap remote article move somehow suboptimal? > > I wasn't suggesting not to let Gnus do the move (I'm not sure > whether nnimap remote move is optimal or not, but that's a separate > problem). What I want to avoid is having Gnus read the entire > message from the server and then feed it into an ssh pipe straight > back to the server. Hence the dance with the IMAP UIDs and the > remote script needing to know which group the messages are in at the > time it runs. Hmm. We could hook into the gnus-summary-article-move-hook and have it save the UIDs to a file, and then you can run the script that batch-processes all the UIDs, interactive or hooked on summary exit for example. Ted