From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55265 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Spam.el tutorial Date: Wed, 17 Dec 2003 11:49:38 -0500 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: <4n8ylbgzj1.fsf@collins.bwh.harvard.edu> 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> 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 1071679855 5863 80.91.224.253 (17 Dec 2003 16:50:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2003 16:50:55 +0000 (UTC) Original-X-From: ding-owner+M3805@lists.math.uh.edu Wed Dec 17 17:50:51 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 1AWess-0007M8-00 for ; Wed, 17 Dec 2003 17:50:51 +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 1AWesk-0003F9-00; Wed, 17 Dec 2003 10:50:42 -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 1AWesc-0003F3-00 for ding@lists.math.uh.edu; Wed, 17 Dec 2003 10:50:34 -0600 Original-Received: from clifford.bwh.harvard.edu (clifford.bwh.harvard.edu [134.174.9.41]) by justine.libertine.org (Postfix) with ESMTP id 416F73A0039 for ; Wed, 17 Dec 2003 10:50:33 -0600 (CST) Original-Received: from collins.bwh.harvard.edu (collins [134.174.9.80]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id hBHGnd700168 for ; Wed, 17 Dec 2003 11:49:39 -0500 (EST) Original-Received: from collins.bwh.harvard.edu (localhost [127.0.0.1]) by collins.bwh.harvard.edu (8.12.9+Sun/8.11.0) with ESMTP id hBHGncuB003031 for ; Wed, 17 Dec 2003 11:49:38 -0500 (EST) Original-Received: (from tzz@localhost) by collins.bwh.harvard.edu (8.12.9+Sun/8.12.9/Submit) id hBHGncHf003028; Wed, 17 Dec 2003 11:49:38 -0500 (EST) Original-To: ding@gnus.org 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: ding@gnus.org In-Reply-To: (Xavier Maillard's message of "Wed, 17 Dec 2003 06:29:09 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55265 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55265 On Wed, 17 Dec 2003, zedek@gnu-rox.org wrote: > Ted Zlatanov disait r=E9cemment que : >> You can still use spam-use-BBDB, spam-use-blacklist, >> spam-use-blackholes, etc. >=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. 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. >> I've promised I'll stop adding spam.el features, so I won't do this >> for No Gnus, but the next features of spam.el will be mass spam >=20 > Are we in the No Gnus development cycle yet ? I asked it not that > long and nobody answered. I defer to the Gnus overlords :) > 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 - 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) - easier to see what's happening - it's less problematic to interrupt spam autodetection than mail splitting - you can set spam-process-destination to any group name, across backends, and the spam will be moved correctly - mass autodetection is much easier than mass spam-splitting of incoming mail - 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 But there are disadvantages: - entering a group is slower with autodetection than splitting incoming mail - 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 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. Ted