From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55268 Path: main.gmane.org!not-for-mail From: Xavier Maillard Newsgroups: gmane.emacs.gnus.general Subject: Re: Spam.el tutorial Date: Wed, 17 Dec 2003 23:26:43 +0100 Organization: GNU Rox ! Sender: ding-owner@lists.math.uh.edu Message-ID: References: <87pteok281.fsf@emptyhost.emptydomain.de> <4nn09sbhvy.fsf@collins.bwh.harvard.edu> <87brq8h3g0.fsf@emptyhost.emptydomain.de> <877k0wh39f.fsf@emptyhost.emptydomain.de> <4nekv4be8i.fsf@collins.bwh.harvard.edu> <4n8ylbgzj1.fsf@collins.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1071700008 12773 80.91.224.253 (17 Dec 2003 22:26:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2003 22:26:48 +0000 (UTC) Original-X-From: ding-owner+M3808@lists.math.uh.edu Wed Dec 17 23:26:44 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 1AWk7w-0000aJ-00 for ; Wed, 17 Dec 2003 23:26:44 +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 1AWk7n-0004GE-00; Wed, 17 Dec 2003 16:26:35 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1AWk7i-0004G9-00 for ding@lists.math.uh.edu; Wed, 17 Dec 2003 16:26:30 -0600 Original-Received: from smtp.gnu-rox.org (rms.gnu-rox.org [213.41.134.247]) by justine.libertine.org (Postfix) with ESMTP id 175C93A0039 for ; Wed, 17 Dec 2003 16:26:29 -0600 (CST) Original-Received: from totoz.gnu-rox.org.gnu-rox.org (totoz.gnu-rox.org [10.0.0.3]) by smtp.gnu-rox.org (Postfix) with ESMTP id 9F9D93E5B1 for ; Wed, 17 Dec 2003 23:30:30 +0100 (CET) Original-To: ding@gnus.org X-Whatever: no X-Url-GnusFr: http://www.gnusfr.org X-Url-EmacsFr: http://www.emacsfr.org X-In-No-Sense: Nonsense X-Home-Page: http://www.gnu-rox.org/~zedek/cgi-bin/wiki.pl X-Gpg-Key-ID: 1E028EA5 X-Gpg-Fingerprint: FDB0 EE1F 33E5 8C22 5E3E 96E7 6900 CA9B 1E02 8EA5 X-Gpg-Affinity: Will accept encrypted message for GNUpg X-Face: 63TbQAY?C>dKDtNNr7 (Ted Zlatanov's message of "Wed, 17 Dec 2003 11:49:38 -0500") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55268 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55268 Ted Zlatanov disait r=E9cemment que : >>[...] >>=20 >> Is it recommended to 'mix' the spam methods ? I mean if I want to >> use all spam methods at once, is this supposed to work or may I >> expect some bad side effects (except the slowness of spam detection) >> ? > > No, I encourage it. As long as you call spam-initialize, you don't > ever have to set any spam-use-XYZ variable to t. You can give > specific checks to spam-split also - see the docs. Good to know that then. Until I read this i explicitly set to t all the spam-use-XYZ when I wanted to use them. So if I understand correctly, I can in my split chain do something like=20 (: spam-split 'spam-use-bogofilter) and so on ? > spam-split can also take a group name, which will override > spam-split-group. So your nn{mail,imap}-split-fancy lists can get > pretty complicated, you can for instance send all blackhole-detected > spam to one place and all blacklist-detected spam to another place. Thank you for the tip. [...] >> Are we in the No Gnus development cycle yet ? I asked it not that >> long and nobody answered. > > I defer to the Gnus overlords :) Eh eh ;) >> Does this mean incoming mail splitting for spam will disappear soon >> ? I am currently actively testing your spam autodetection new >> features and it really works/rocks :) > > Well, spam autodetection has these benefits: > > - faster to get mail Correct if and only if you don't do spam-split on your split receipts. =20 > - less complication with the splitting process, which has had some > issues (especially nnimap) > > - easier to customize for particular kinds of splitting you want (with > incoming mail splitting, you can only choose splitting chains based > on the backend essentially) Ok. > - easier to see what's happening Hum how so ? > - it's less problematic to interrupt spam autodetection than mail > splitting Yes. > - you can set spam-process-destination to any group name, across > backends, and the spam will be moved correctly Nice. > - mass autodetection is much easier than mass spam-splitting of > incoming mail Agree. > - all headers, etc. Gnus info is in place whereas with splitting > incoming mail that information is not necessarily available > > - obviously, spam autodetection works for read-only backends Ah here is the point. Since now, I set spam-autodetect even for my normal mail groups (nnml backends) and I just didn't see anything happening except a bunch of CPU used when entering mailing-list groups. > But there are disadvantages: > > - entering a group is slower with autodetection than splitting > incoming mail Clearly.=20 > - spam will not go away, it will still be in the group when you enter > it - this may be annoying. We can actually deal with this pretty > easily, by moving spam explicitly after spam-find-spam is called. > Of course, this will be an option :) > > The best solution, as always, may be a compromise: > > - spam-split in incoming mail will move mail to a temporary queue > folder > > - right afterwards, spam autodetection will be done on the queue > folder > > - ham will be sent to the next item in the nn{mail,imap}-split-fancy > chain Hmmm. I don't think I have correctly understood this part. Best for me is to try that way. > I'm not sure how this may work, and I'm not going to worry about it > until the current Gnus development cycle is done. Fixing the manual > to discuss the current features is much more important. Yes. Thank you for your useful post. zeDek --=20 Xavier Maillard main(){printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}