Re: [Evolution-hackers] Spam filtering thoughts

[Christopher Ness <nesscg mcmaster ca>]

On Fri, 2003-08-08 at 17:48, Not Zed wrote:
> On Fri, 2003-08-08 at 16:19, Ettore Perazzoli wrote:
> > For the actual spam detection, I think we should just use Spamassassin. 
> > It works great, is actively maintained, and is very simple to interface
> > to.  It also does a great job without any training, although it does
> > support Bayesan filtering.

I currently use POPFile for Bayesan filtering.  It works great, but I'm
pretty sure that it's only for POP accounts.

> > > (If at some point some better solution shows up, it should be fairly
> > easy to either switch to the new solution, or make the interfaces
> > generic enough to make the system fully pluggable.  However, I don't
> > think pluggability is a must; let's focus on the user experience first.)
> 
> i think pluggability is more important but whatever ... it would be
> cheap with a decent design anyway (as opposed to a nasty quick-hack).

Ok, here's the kicker.  What is the most important thing that we know
about SPAM. It changes faster than developers can produce solutions.

Spamassassin is a great product, but a year from now something else may
come along that is better (even if SA tries to adapt, who knows what the
future holds!).

The *most* important part of this feature should be it's
"pluggability".  Do not ruin a good product by bloating it.

If I'm working in an Intranet only station/email, why would I need a
spam filter to slow things down or to confuse the user?  It's just silly
and frivolous bloating of the product.

I'd like to see this feature go in the direction like Gpilot's
conduits.  A separate package that _can_ be installed, but isn't hard
coded into Evo.

Please modularize because things _are_ going to change.  Come up with a
well defined interface between Evo and SPAM filters (try to make it
generic because not everyone uses the same filters [allow more than one
filter for a message?]).  This way it doesn't matter what's on either
side of the interface, only that each module knows what to expect of
each other in every case.

> 
> >       * We give the user a way to say what happens to messages detected
> >         as spam; i.e. whether they should stay in the folder, or moved
> >         to a "Junk" folder or deleted.  (This should probably be
> >         separate from the general filter dialog, because this choice
> >         should be available without the user having to understand
> >         filters.)
> 
> >       * We put a button in the mail toolbar to mark a message as spam or
> >         not spam.  When a message gets marked by the user as spam or not
> >         spam, Evolution sends it to Spamassassin to train the filter
> >         accordingly.

Please don't clutter the toolbar.  Why should a button exist if it does
not do anything.  Such is the case of a basic user not having or using
SPAM protection?

Your above statement leads me to believe that Spamasassin is going to
become a dependency for Evo, is this your intention?

> 
> a lot of toolbar buttons already ...
> 
> >       * As an additional aid to the user, messages detected as spam
> >         could be displayed with a header saying "this message is spam,
> >         if it's not click here to mark it as non spam", like in Apple
> >         Mail:
> > 
> >                 http://www.apple.com/macosx/jaguar/images/mainmailbox.jpg
> >                 
> >         This button would behave exactly like the "not spam!" toolbar
> >         button.

If you used a Vfolder I don't think this would be necessary.

> if we do that i dont know whether we should bother with a toolbar item
> 
> >       * We add a command to delete all the messages marked as spam in
> >         the current folder.
> > 

-- 
Christopher Ness
Software Engineering IV,
McMaster University
http://nesser.homelinux.org 

sketchy running 2.4.20-18.9 kernel on Red Hat Linux release 9 (Shrike).
16:01:05 up 1:59, 1 user, load average: 0.62, 0.40, 0.39 

My Jukebox is currently playing...
Weezer Across The Sea