Re: [Evolution-hackers] Spam filtering thoughts

[Christopher Ness <nesscg mcmaster ca>]

Wow, it's early and I haven't had a coffee yet, why am I replying??...

On Sun, 2003-08-10 at 23:47, Rodney Dawes wrote:
> On Sun, 2003-08-10 at 16:22, Christopher Ness wrote:
> > On Fri, 2003-08-08 at 17:48, Not Zed wrote:
> > > On Fri, 2003-08-08 at 16:19, Ettore Perazzoli wrote:

<snip />

> > Your above statement leads me to believe that Spamasassin is going to
> > become a dependency for Evo, is this your intention?
> 
> If the spam filter integration stuff gets implemented for 2.0, the Evo
> packages will depend upon Spamassassin in some manner. If we get a
> plug-in framework going, beyond the bonobo cruft that we need to work
> around already, then whatever plug-in for the spam filtering will depend
> on Spamassassin (as well as be part of the default install). The way

What should the default be?  Do you plan to install this pluggin by
default or will the user have to install the package to get this
feature?

Why Spamassassin?  Is it because it will be easier to support for the
masses?  Should it not be possible to allow any filter to be used?

> the gnome-pilot plug-ins work, is that they are actually plug-ins for
> gnome-pilot, and not Evolution, and depend on both to work. They are
> never actually loaded into the evolution binary to get something done.

TRUTH:  I'm not very knowledgeable about Evo's API's or backends, but
I'm working on it.

> They use the CORBA and whatever APIs there are for the components, to
> get the needed information for syncing to the hardware. The current
> evolution packages (rpms), are built such that it is possible to install
> a minimal amount of necessary pieces to get evolution running.

Good, what is *your* idea of the minimal pieces?

> Unfortunately, some people have different ideas about what is "minimal"
> than others do. In the future, more decentralization of the evolution
> components should happen, such that the plug-in usage actually makes
> more sense. :)

I've heard talk of decentralization with the contact list.  I like those
ideas.

<snip />

> > If you used a Vfolder I don't think this would be necessary.
> 
> If you don't have a method of saying a piece of mail that was classified
> as spam, is not spam, how do you expect to train the filter such that it
> would know that something is not spam, or move the mail back to it's
> original folder. The point of a "VSpam" folder, is similar to that of

Good point, I don't know if the toolbar is aware of which folder is open
(I would think it is, but maybe not for Vfolders).  If it is then the
button could be made to identify HAM when in the VSpam folder.  This is
assuming the plugin can change the GUI and add the toolbar button.

> how the "VTrash" works. It contains all the messages marked as spam,
> that are in your folders, and these messages are hidden from view in the
> original folders. This makes it easier to determine where a message came
> from, when you retrain the filter to see that it is not spam. In a
> bayesian classification system, you need a method for the user to say
> whether or not a message is spam, to the backend, in a reasonable UI. A
> button is the only reasonable UI for doing so, that I have seen, or can
> think of. Moving things around manually and running sa-learn on the
> various mailboxes is very non-optimal. :)
-- 
Christopher Ness

sketchy running 2.4.20-18.9 kernel on Red Hat Linux release 9 (Shrike).
07:20:06 up 14 min, 1 user, load average: 0.13, 0.22, 0.20