Gnus development mailing list
 help / color / mirror / Atom feed
From: Ted Zlatanov <tzz@lifelogs.com>
Cc: Hubert Chan <hubert@uhoreg.ca>
Subject: Re: spam.el: generic bayes interface?
Date: Tue, 20 Jan 2004 19:08:14 -0500	[thread overview]
Message-ID: <4nptdei2oh.fsf@collins.bwh.harvard.edu> (raw)
In-Reply-To: <v9broy1fsd.fsf@marauder.physik.uni-ulm.de> (Reiner Steib's message of "Tue, 20 Jan 2004 22:17:06 +0100")

On Tue, 20 Jan 2004, 4.uce.03.r.s@nurfuerspam.de wrote:

> in the German Gnus group someone asked how to use the
> SpamAssassin/Bayes (see sa-learn(1)) thingie with Gnus.  I happily
> pointed him to `spam.el' and the fine manual.  But it turned out
> that there is no interface for SpamAssassin/Bayes in `spam.el' (or
> at least I couldn't locate it).

Yes, spam-use-regex-headers will do the right thing for splitting
incoming mail, but there's no SA specific backend.  Hubert Chan wrote
a SA backend, and I have been late in replying to his questions.
It's coming, though.

> I assume that SpamAssassin/Bayes works very similar to bogofilter
> [1], so it probably works by abusing the `spam-bogofilter-*' [2]
> variables.  But this is a quite dubious approach, IMHO.  Wouldn't it
> make sense to add a generic bayes interface with say
> `spam-bayes-...' variables (similar to the `browse-url-generic*'
> variables) instead of adding a set of variables for each (new)
> Bayesian filter?

The problem is that then you force people into just one Bayesian
approach (how would SA and bogofilter work together?), and I'm not
sure it's a good idea.  Granted, most people use just one Bayesian
filter, so it's probably nice to switch filters with just one thing.

But consider that the registry must track which Bayesian backend has
registered which message.  Let's say the registry knows that
spam-use-bayesian has registered message A, and that was Bogofilter at
the time, but the user switches to SA later.  Now the registry doesn't
know that SA has not registered message A, and spam.el will
not re-register message A.  It's just an example, but things will be
slightly harder to track in general.

Also, I can't drop the current Bayesian spam-use-* backends that users
are using.  So now we will have the general case of spam-use-bayesian
plus the specific backends.  Seems pretty confusing.

I would prefer to make adding new Bayesian backends easy, but give
them separate spam-use-BACKEND symbols.  Hubert's work will be
helpful here, because I've been too lazy/busy to write a good
example :)

Ted



  reply	other threads:[~2004-01-21  0:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-20 21:17 Reiner Steib
2004-01-21  0:08 ` Ted Zlatanov [this message]
2004-01-21  4:02   ` Hubert Chan
2004-01-21 18:47     ` Ted Zlatanov
2004-01-21 20:24       ` Hubert Chan
2004-01-22 18:23         ` Ted Zlatanov

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=4nptdei2oh.fsf@collins.bwh.harvard.edu \
    --to=tzz@lifelogs.com \
    --cc=hubert@uhoreg.ca \
    /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).