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.
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? Cheers Michael, AfC -- Andrew Frederick Cowie OPERATIONAL DYNAMICS Operations Consultants and Infrastructure Engineers http://www.operationaldynamics.com/
Attachment:
signature.asc
Description: This is a digitally signed message part