From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/57932 Path: main.gmane.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.gnus.general Subject: Re: wallowing out of the spam quagmire Date: Mon, 21 Jun 2004 20:21:00 -0500 Organization: Still searching... Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1087867360 11417 80.91.224.253 (22 Jun 2004 01:22:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 22 Jun 2004 01:22:40 +0000 (UTC) Original-X-From: ding-owner+M6473@lists.math.uh.edu Tue Jun 22 03:22:33 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 1BcZzc-0006Xp-00 for ; Tue, 22 Jun 2004 03:22:32 +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 1BcZyS-0000eN-00; Mon, 21 Jun 2004 20:21:20 -0500 Original-Received: from util2.math.uh.edu ([129.7.128.23]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1BcZyN-0000eI-00 for ding@lists.math.uh.edu; Mon, 21 Jun 2004 20:21:15 -0500 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by util2.math.uh.edu with esmtp (Exim 4.30) id 1BcZyM-0003uO-Ef for ding@lists.math.uh.edu; Mon, 21 Jun 2004 20:21:14 -0500 Original-Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by justine.libertine.org (Postfix) with ESMTP id B9E723A003A for ; Mon, 21 Jun 2004 20:21:11 -0500 (CDT) Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BcZyI-0001DD-00 for ; Tue, 22 Jun 2004 03:21:10 +0200 Original-Received: from adsl-68-74-182-61.dsl.emhril.ameritech.net ([68.74.182.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 03:21:10 +0200 Original-Received: from reader by adsl-68-74-182-61.dsl.emhril.ameritech.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Jun 2004 03:21:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-To: ding@gnus.org Original-Lines: 91 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: adsl-68-74-182-61.dsl.emhril.ameritech.net User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:YYO9aXd7/sK91OrNpMWaf8HpTU8= Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:57932 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:57932 Jonas Steverud writes: > Harry Putnam writes: > >> Listening to various posts on that it seems have all the earmarks of >> being a pain in the butt. > > Both yes and no. The problem is to understand how spam.el works. It is > not complex, the documentation is simply not yet complete. Read it > before you continue with this email. I'm not sure we're from the same planetary system... or as bare minimum you must have a rather bizarre notion of what `not complex' means. I went glassy eyed after the first couple hundred lines. I'm introduced to black lists, black holes, hash-cash payments, bogofilters, on line data bases, bbdb as white list, some absolutely convoluted processing that seem to require `split fancy' which I've never used. Some use of gnus registry, which I also have never messed with. Many lines of variable discussion which apparently is supposed to spell out what 2780 lines of elisp in spame.el do. In my world, this is quite `complex'. > >> 1) procmail/SpamAssassin based pre filtering (before gnus) > > I assume it places all spam in a specific group, lets for the > discussion call it nnfolder:Spam. No, but sort of similar. I used plain splitting inside gnus for a few years but gave it up a couple years ago in favor of procmail. For some time now I've left all splitting to procmail/SpamAssassin. What gets past procmail/sa ends up in a single inbox where I deal with all of it by hand. That inbox is getting an increasing amount of spam. Stuff that is hard to indentify etc. So to summarize. I let procmail/sa do most splitting and culling out of spam. When that is done, the rest comes to my inbox and I deal with it by hand. I hoped to introduce bogofilter at that stage. Many thanks for posting your setup... However it seems fantastically complicated to me. I had visions of leaving all spam that spamassasin and procmail find out of the equation. Then whatever gets to my single inbox, I had visions of marking any spam as such and moving it to a spam group. Maybe copy ham to a ham group. Then let these messages be the training tools for bogofilter. After showing bogofilter enough examples isn't is supposed to take it from there? As training begins I'd introduce splitting into my single inbox as the tools learn what is what. I'm not sure what this training actually does in practice, but it sounds like bogofilter begins to know what is spam. If so, then I'd tell bogofilter to remove what it thinks is spam. No other splitting would be needed. Not at all clear why a fancy-spit is required to do that. In fact its kind of hard to imagine a spit rule at all. Seems like one would just invoke bogofilter on each message and send each one to spam or ham. Technically a split, I guess but not very complicated. The complicated part seems to be what goes on inside bogofilter. The messages it will be seeing have already skirted SA's complex set of interrelated rules, plus my own homeboy procmail rules and tweaks to SA. So this mail will be hard to find a pattern or some other thing to help indentify it. The above semi-diagram seems fairly simple to me. But I don't see how it can be done with the current documentation. I have no idea how to implement this. I've probably talked myself right into a hole but how can I set up the simple system described above? Have I over looked step by step instructions? I'm assuming by documentation people mean the stuff at: Filtering Spam Using The Spam ELisp Package I haven't found a step by step there. I guess ...Spam ELisp Package Sequence of Events is as close as it gets.. Sounds like I need the auto-detect method and would set G p on my single inbox group to something that tells spam.el to `auto-detect' in it. My case should be the simplest possible example of using spam.el and bogofilter, but I'm not sure about involving gnus registry etc. Or what `exactly' needs doing. I'm going to look for Teds patch to docs right now.