Re: [Evolution-hackers] Spam filtering thoughts

[Ettore Perazzoli <ettore ximian com>]

> >       * Support black lists and white lists.  (This could be optional.)
> 
> So we need to write a gui editor for a spamassisn config file and crap
> like that ?

No, it should just have the options that make sense, and we should keep
it really simple.

> i think pluggability is more important but whatever ... it would be
> cheap with a decent design anyway (as opposed to a nasty quick-hack).

I'm not talking about a quick hack here.  :)

> > >From the mail side of things, we could do something like this:
> > 
> >       * We add a way for Camel to mark a message as spam or not.  It
> >         should probably have to be a bit in the summary, the same way we
> >         handle things like colors/labels.
> 
> Nothing needs to be done to camel to support this (other than the
> detection, which can also be done without camel changes).

Great!

> >       * We invoke Spamassassin in spam detection mode every time a new
> >         message goes through the mailer, and set the corresponding bit
> >         in Camel according to what it tells us about the message.
> 
> it should really only be new inbox mail.  if people do server-side
> filtering they should also do server-side spam detection.

But then, if we actually add Sieve support, the user will be in a
situation where she can control server side filtering but cannot control
the spam filtering...

> have 2 bits one for 'spam checked' and one for 'spam status', yuck.

Why is this bad?  Having three states seems fine to me, and you probably
need to do that anyways -- because when you get the list of new messages
in an IMAP folder they must first be in the "unknown" state and then
turn into the "spam" or "not spam" state once the actual message gets
downloaded and evaluated.

> >       * 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.)
> 
> Not sure I agree here.  Another ui for the same thing?  It also has to
> integrate with filters for when filtering is requested.

We could have an option for specifying the default action (and that
would be something simple: "keep where it is", "move to junk folder",
maybe nothing more than that), then we could have a "message is spam"
rule in the 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.
>
> a lot of toolbar buttons already ...

Yeah we have way too many buttons -- this gives us a chance to get rid
of a few of them.  :)

> >                 http://www.apple.com/macosx/jaguar/images/mainmailbox.jpg
> >                 
> >         This button would behave exactly like the "not spam!" toolbar
> >         button.
> 
> if we do that i dont know whether we should bother with a toolbar item

Because in the case where the message is spam there is not going any
notice in the mail display, so you need a "mark as spam" button.

(The toolbar button would toggle between "mark as spam" and "mark as not
spam" depending on the status of the current selected message.)

> >       * We would probably want it to automatically recognize messages
> >         that went through a spam filter in the server already.  I.e.
> >         Evolution could recognize the X-Spam headers and turn the "this
> >         is spam" bit on automatically when appropriate?
> 
> Yeah, easy.  Although then we run the risk of people who aren't using
> spam filters being duped by spam adding that header and saying it isn't
> spam.  So it would probably have to be an explicit option for
> environments where the x-spam-status can be trusted.

Hmm good point.  I guess we could have a "trust existing message spam
status" setting?  It might be confusing though.

-- Ettore