Re: [Evolution] Filtering folders other than INBOX

[Not Zed <notzed ximian com>]

On Fri, 2004-08-13 at 15:04 +1000, Andrew Cowie wrote:
> On Fri, 2004-08-13 at 11:22 +0800, Not Zed wrote:
> > If you already have server-side filtering, why would you want to slow
> > it down and do it on the client too? 
>
> In addition to sorting into a few folders server side, I also have spam
> filtering going on up there.
>
> Recently I've been trying evolution's built in spamassassin support
> [instead], which is ok. I'd like to move it back server. (more spare CPU
> cycles, get it done ahead of time, won't hold up the UI when
> downloading, etc)
>
> In another thread on this list NotZed mentioned that the "Mark as Junk /
> Not Junk" [which is a nice UI front end to sa-learn] could be used even
> if evolution's automatic Junk filter [feed to spamc] wasn't being used.
>
> So, it occurred to me that a good idea would be to use my [now nicely
> initialized] bayes_* word token database on the server side by rsyncing
> them from client to my account on the mail server, whereupon the
> server's SpamAssassin installation can make use of it. I can then
> continue to take advantage of Evolution's wonderful learn/unlearn UI on
> the client side, and then periodically update the bayes files server
> side by rsyncing them up there.
>
> It seems, though, that to work right, I need to have evolution actually
> be the thing which moves spam into its Junk psuedo-vFolder (so that
> "Mark as Not Junk" [unlearn, --ham] will work) - which seems to imply
> that I should *not* be sorting Spam messages server side into some
> separate folder, but instead be letting Evo do it through the status
> junk mechanism.
Whats the problem here, that the ui just doesn't activate since it doesn't know it's spam, I guess?

Since presumably you should be already moving (phyusically) any spam messages to another folder, it should be affecting the normal view/vfolders etc, since it isn't stored in normal folders like evo junk is.  Obviously since they use different mechanisms it wont be perfect, you'll have two junk folders, but it should still work, at that level, at least.

With plugin stuff there's the potential to make this work differently in the future anyway, maybe even different per-server like i was hoping it could be done but we didn't have time this release cycle to do.

> The smart way to actually do that part seems to be to use an evolution
> filter rule, sorting on a header ("X-Spam-Status -> yes", of course),
> and then applying the "Set Status -> Junk" action.
>
> However, only stuff in INBOX will be actioned by that filter rule,
> meaning I still have to manually "Select All ; Apply Filters" ...
>
> ... which is why I'd like to be able to have filters apply across all
> folders when they're processing new messages.
>
> --
>
> I suspect that there may be an easier path through all this. I am
> tempted to just give up and not file [as in route messages] at all on
> the server side so that it would be INBOX only. I already use vFolders
> quite extensively, so that wouldn't be all that bad, but they do
> somewhat rely on the preliminary sorting that happens server side
> [Lists, Boards, Server messages, etc]. It's the Webmail-also-looking-at-
> the-same-mailstore case that I'm worried about.
>
> --
>
> Oh,
>
> > - finding out about new messages is already unreliable at best,
> > searching all folders for them would also impact performance a lot
>
> But evo is already doing that for each IMAP folder. So how much worse
> would it be to then hook up the filter mechanism?
Only if you tell it to.

Filter loops are the real technical issue, the others are performance etc.

-- 







Michael Zucchi <notzed ximian com>

"born to die, live to work, it's all downhill from here"

Novell's Evolution and Free Software Developer