* spam.el: generic bayes interface?
@ 2004-01-20 21:17 Reiner Steib
2004-01-21 0:08 ` Ted Zlatanov
0 siblings, 1 reply; 6+ messages in thread
From: Reiner Steib @ 2004-01-20 21:17 UTC (permalink / raw)
Hi,
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).
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?
Bye, Reiner.
[1] E.g. for training spam, he has to use "sa-learn --spam".
[2] M-x apropos-variable RET spam-bogofilter- RET
--
,,,
(o o)
---ooO-(_)-Ooo--- PGP key available via WWW http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: spam.el: generic bayes interface?
2004-01-20 21:17 spam.el: generic bayes interface? Reiner Steib
@ 2004-01-21 0:08 ` Ted Zlatanov
2004-01-21 4:02 ` Hubert Chan
0 siblings, 1 reply; 6+ messages in thread
From: Ted Zlatanov @ 2004-01-21 0:08 UTC (permalink / raw)
Cc: Hubert Chan
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: spam.el: generic bayes interface?
2004-01-21 0:08 ` Ted Zlatanov
@ 2004-01-21 4:02 ` Hubert Chan
2004-01-21 18:47 ` Ted Zlatanov
0 siblings, 1 reply; 6+ messages in thread
From: Hubert Chan @ 2004-01-21 4:02 UTC (permalink / raw)
>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
[...]
Ted> Yes, spam-use-regex-headers will do the right thing for splitting
Ted> incoming mail, but there's no SA specific backend. Hubert Chan
Ted> wrote a SA backend, and I have been late in replying to his
Ted> questions. It's coming, though.
I see it in CVS now. ;-) I promised to write documentation too, but
that won't happen until at least next week some time. In the mean
time, though, the variable documentation should probably suffice for
most people.
[...]
Ted> The problem is that then you force people into just one Bayesian
Ted> approach (how would SA and bogofilter work together?), and I'm not
Ted> sure it's a good idea. Granted, most people use just one Bayesian
Ted> filter, so it's probably nice to switch filters with just one
Ted> thing.
Well, there are at least some good reasons that someone might want to
use multiple Bayesian filters. For example, one might want to just try
out the effectiveness of one filter, while retaining their original
filter as a backup. Also, if one wishes to switch Bayesian filters,
and does not have a corpus of spam/ham to train the filter, there would
have to be a transition time during which the new filter is trained,
while the old filter is still being used for splitting. And, of
course, during this time, one would still want to keep training the old
filter at the same time.
This got me thinking, though, Ted, that the registration code for the
spam/ham processors is pretty similar. They seem to mostly work in one
of two ways -- either register one at a time, or register multiple
articles at a time in a mbox-style format. I think they all feed the
articles via standard input. I would imagine that we would be able to
share a lot of common code. Maybe write a function that feeds the
article(s) to the registration program, and pass the name of the
program and its arguments as arguments to that function. Then the
registration functions just have to call that function with the
appropriate arguments. Hmm. I'll have to look at the code to see if
that would actually work...
--
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: spam.el: generic bayes interface?
2004-01-21 4:02 ` Hubert Chan
@ 2004-01-21 18:47 ` Ted Zlatanov
2004-01-21 20:24 ` Hubert Chan
0 siblings, 1 reply; 6+ messages in thread
From: Ted Zlatanov @ 2004-01-21 18:47 UTC (permalink / raw)
Cc: Hubert Chan
On Tue, 20 Jan 2004, hubert@uhoreg.ca wrote:
> Well, there are at least some good reasons that someone might want
> to use multiple Bayesian filters. For example, one might want to
> just try out the effectiveness of one filter, while retaining their
> original filter as a backup. Also, if one wishes to switch Bayesian
> filters, and does not have a corpus of spam/ham to train the filter,
> there would have to be a transition time during which the new filter
> is trained, while the old filter is still being used for splitting.
> And, of course, during this time, one would still want to keep
> training the old filter at the same time.
I'm OK with that, we can add a spam-use-generic-bayesian if it's
necessary. I just think customization, registry tracking, and other
things won't work so well when we generalize the interface too much.
If you or someone else produces that generic-bayesian backend, I
don't see a problem with putting it in. We can't anticipate the new
bayesian filters people might want to use, after all.
> This got me thinking, though, Ted, that the registration code for
> the spam/ham processors is pretty similar. They seem to mostly work
> in one of two ways -- either register one at a time, or register
> multiple articles at a time in a mbox-style format.
Yes, I've noticed that too after the 3rd time I wrote that code :)
> I think they all feed the articles via standard input. I would
> imagine that we would be able to share a lot of common code. Maybe
> write a function that feeds the article(s) to the registration
> program, and pass the name of the program and its arguments as
> arguments to that function. Then the registration functions just
> have to call that function with the appropriate arguments. Hmm.
> I'll have to look at the code to see if that would actually work...
It could work. I've been trying to make the functions generic on the
API side, now it's time to make them generic on the backend side as
well. I'm afraid it will make the code more complex, but adding new
backends should be significantly easier.
I'll work on gnus-encrypt.el first though, so feel free to start on
this if you have the interest :)
Thanks
Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: spam.el: generic bayes interface?
2004-01-21 18:47 ` Ted Zlatanov
@ 2004-01-21 20:24 ` Hubert Chan
2004-01-22 18:23 ` Ted Zlatanov
0 siblings, 1 reply; 6+ messages in thread
From: Hubert Chan @ 2004-01-21 20:24 UTC (permalink / raw)
>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
[...]
Ted> If you or someone else produces that generic-bayesian backend, I
Ted> don't see a problem with putting it in. We can't anticipate the
Ted> new bayesian filters people might want to use, after all.
I don't plan on doing that. I can't see any good way to generalize the
interfaces in any way that makes sense.
[...]
Ted> I'll work on gnus-encrypt.el first though, so feel free to start on
^^^^^^^^^^^^^^^
Oooh. Cool... ;-) ... What would this do?
Ted> this if you have the interest :)
I won't have time to do anything until at least next week. Possibly
even later. And then there are a few things that I want to work on
first -- documentation, the email forwarding backend. Maybe we can
have a race to see who's able to scrape up some free time first. ;-)
Hubert
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: spam.el: generic bayes interface?
2004-01-21 20:24 ` Hubert Chan
@ 2004-01-22 18:23 ` Ted Zlatanov
0 siblings, 0 replies; 6+ messages in thread
From: Ted Zlatanov @ 2004-01-22 18:23 UTC (permalink / raw)
Cc: Hubert Chan
On Wed, 21 Jan 2004, hubert@uhoreg.ca wrote:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
>
> Ted> I'll work on gnus-encrypt.el
> ^^^^^^^^^^^^^^^
> Oooh. Cool... ;-) ... What would this do?
Encrypt and decrypt files such as .authinfo and .newsrc.eld. I'll
have something ready for testing soon.
Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-22 18:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-20 21:17 spam.el: generic bayes interface? Reiner Steib
2004-01-21 0:08 ` Ted Zlatanov
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
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).