From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57677 Path: main.gmane.org!not-for-mail From: "Ted Zlatanov" Newsgroups: gmane.emacs.gnus.general Subject: Re: Gnus SPAM support, and email based reporting. Date: 24 May 2004 09:44:28 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4naczyj5xf.fsf@lifelogs.com> References: <87isfy7p6a.fsf@enki.rimspace.net> <1xmm1vhg.fsf@random.localnet.unwireduniverse.com> <4nzn95gwu7.fsf@lifelogs.com> <87lljt2534.fsf@enki.rimspace.net> <4nfz9xbirq.fsf@lifelogs.com> <87d64uaxpg.fsf@enki.rimspace.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1085407344 28586 80.91.224.253 (24 May 2004 14:02:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 May 2004 14:02:24 +0000 (UTC) Cc: ding@gnus.org Original-X-From: ding-owner+M6217@lists.math.uh.edu Mon May 24 16:02:14 2004 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 1BSG1u-0008Lr-00 for ; Mon, 24 May 2004 16:02:14 +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 1BSG1A-0008DT-00; Mon, 24 May 2004 09:01:28 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BSG15-0008DO-00 for ding@lists.math.uh.edu; Mon, 24 May 2004 09:01:23 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BSG14-0007fm-OZ for ding@lists.math.uh.edu; Mon, 24 May 2004 09:01:22 -0500 Original-Received: from mail.bwh.harvard.edu (sysblade0.bwh.harvard.edu [134.174.9.44]) by justine.libertine.org (Postfix) with ESMTP id 422CF3A0036 for ; Mon, 24 May 2004 09:01:20 -0500 (CDT) Original-Received: (qmail 24282 invoked from network); 24 May 2004 13:55:37 -0000 Envelope-Sender: tzz@lifelogs.com Envelope-Recipients: daniel@rimspace.net, ding@gnus.org, Original-Received: from asimov.bwh.harvard.edu (HELO asimov) ([134.174.9.63]) (envelope-sender ) by mail.bwh.harvard.edu (qmail-ldap-1.03) with SMTP for ; 24 May 2004 13:55:36 -0000 Mail-Followup-To: "Daniel Pittman" , ding@gnus.org Original-To: "Daniel Pittman" 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" In-Reply-To: <87d64uaxpg.fsf@enki.rimspace.net> (Daniel Pittman's message of "Mon, 24 May 2004 21:09:15 +1000") User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57677 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57677 On Mon, 24 May 2004, daniel@rimspace.net wrote: On 19 May 2004, Ted Zlatanov wrote: >> I'm planning to do a major overhaul (version 3 of spam.el, so to >> speak) where a lot of the unnecessary complexity is at least only >> done once. Probably by the end of the year. > > It struck me that there was an awful lot of writing of wrapper functions > around what is, at heart, pipe to command A to learn as spam, or command > B to learn as ham. > > OTOH, I don't really understand your code so well and I am probably > missing the reason why a bunch of this complexity exists. The complexity is necessary to accomodate all the spam detection and training backends. BBDB, for instance, is VERY different from Bogofilter. Some backends don't detect incoming spam (the reporters), others don't learn (spam-use-blackholes). Like I said, I'll try to simplify it, but the code will have to remain very abstract to handle all the possible backends. There will probably be spam-register-backend which will handle all the various types of backends. >> With spam.el, you just make (spam spam-use-resend) the exit >> processor of the group. All spam articles will be processed >> through it. > > That didn't work. I needed to add to the group parameters: > > (spam-process (gnus-group-spam-exit-processor-report-resend)) > > The other one didn't trigger, for some reason. Looks like a bug in my code, because gnus-group-spam-exit-processor-report-resend is supposed to be no longer necessary. I'll look today. > Er, and finally, I think that it would be better to set `defcustom > spam-report-resend-to' to `nil' by default. > > Then, in the report function we could test that address and if it was > `nil', display an error to the user and instruct spam.el to mark the > article as "not processed" > > That seems more user-friendly to me. Alternately, we could actually > prompt for the destination and save that with custom, but I don't know > how to do that - custom is still a mysterious (and probably explosive) > black box to me. :) The resend-to address should be a Gnus group/topic variable that overrides the default spam-report-resend-to, I think. What do you think? I applied your bug fix, thanks! Ted