Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
Cc: Ding Mailing List <ding@gnus.org>
Subject: Re: should gnus-registry.el be in the manual for Oort Gnus?
Date: Mon, 05 Jan 2004 13:51:19 -0500	[thread overview]
Message-ID: <4nd69yut3s.fsf@collins.bwh.harvard.edu> (raw)
In-Reply-To: <87hdzet3mu.fsf@daphne.gnuu.de> (Thomas =?iso-8859-1?q?H=FChn's?= message of "Fri, 02 Jan 2004 23:11:36 +0100")

On Fri, 02 Jan 2004, ding@daphne.gnuu.de wrote:

> Also sprach Ted Zlatanov <tzz@lifelogs.com>:
> 
>> - tracking of spam processor invocations
> 
> I know this isn't really spam.el-specific, but does that mean that
> one could force spam.el not to register a mail with bogofilter
> twice?

Yes, with registry tracking.  If you limit the number of registry
entries, however, you will eventually lose that tracking information.

I could add a flag to the registry "preferentially keep messages with
tracking information" if this is a problem.

> I'm still playing around with my spam.el-configuration.
> Actually I'd like to have something like this:
> 
- new mail arrives
- fancy splitting (with spam-split at the beginning)
- spam goes into "nnml:spam", everything else into it's folder
- ham in the spam group is un-registered and moved into a suitable
  nnml-group
- spam in any "normal" group is registered and moved to spam where it
  expires

I think your setup is almost exactly like mine, which is in the latest
Gnus manual.  Check mine out and let me know if something is unclear.

> Am I right about that re-registering of good mails when I classify
> all of my normal mail groups as ham or have I understood something
> wrong?

You're right, you would re-register without the gnus-registry
tracking.

> And that's where your registry comes into play? With that one could
> avoid this and classify almost everything as ham groups?

Yes.  I would advise, however, that you check registrations to make
sure things are working correctly.  They should, but it does not hurt
to be cautious.

> BTW, the spam.el-specific part of my .gnus begins thus:
> 
> (spam-initialize)
> (setq spam-install-hooks t)
> ;(spam-install-hooks-function)
> (setq spam-use-bogofilter t)
> (setq spam-mark-ham-unread-before-move-from-spam-group t)
> (require 'spam)
> 
> I think that the Info indicated that one should put in
> spam-install-hooks (which resulted in an error) before you
> commited your big doc patch.
> 
> So can I leave out everything except spam-initialize and
> spam-use-bogofilter?

This should be sufficient:

(setq spam-use-bogofilter t)
(setq spam-mark-ham-unread-before-move-from-spam-group t)
(spam-initialize)

Ted



      reply	other threads:[~2004-01-05 18:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-18 10:03 Ted Zlatanov
2004-01-02 21:43 ` Lars Magne Ingebrigtsen
2004-01-02 22:11 ` Thomas Hühn
2004-01-05 18:51   ` Ted Zlatanov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4nd69yut3s.fsf@collins.bwh.harvard.edu \
    --to=tzz@lifelogs.com \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).