* dar...@chaosreigns.com <dar...@chaosreigns.com>: ...
> One of my questions is, does it make sense to continue to maintain bayesian > stuff within SA at all? Or should we drop it, and encourage people to run > a pure bayesian classifier before SA (like spamprobe), then have rules that > read the headers from those classifiers? Are there options better than > spamprobe? > > On one hand, spamprobe has been around forever, and almost certainly does > bayes at least as well as SA is ever likely to, it's pretty easy to run it > before SA, and creating the rules to read those scores would be easy. >From a short glance it doesn't look as if spamprobe could be run in a pre-queue setup. In Germany, for legal purposes, pre-queue filtering is a must. Can it be? > On the other hand, keeping the bayes functionality within SA provides a > tidier package, a little easier to set up, one fewer process spawned per > email, and adding these two features really shouldn't be hard. Without > even breaking any backward compatibility (with the existing database > format). I hope. Personally, as a sysadmin, I'd prefer to get most of what I need from one tool. I'd favour enhancing SA. > The reason I'm playing with bayes is my interest in the possible usefulness > of shared bayes data. > > I want to do more testing of using other people's bayes data on > my corpora. My assumption is that most end users don't do their own > training. So I haven't been using bayes, for some time, in an attempt Most users use their computers to do gain something else. They don't want to deal with computers. Training personal bayes filters is undesirable to them. p@rick -- state of mind () http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563
