Re: [Evolution] Spamassassin, Junk/Not-Junk, Training

[Eric Lambart <ximian nomeaning net>]

On Tue, 2004-03-30 at 03:12 +0800, Not Zed wrote:
> You can do this already, simply set-up a filter where you filter on the
> x-spam* header, as appropriate.
>
> The junk/not junk will run through the sa-learn stuff, it doesn't
> actually move the mail anywhere, the junk folder is only a vfolder.

Well, I just learned that this makes the Junk folder concept rather
useless to me.  I fired up my laptop this morning, which is still using
Evo 1.4.6, and every damned "junk" message of the last week appeared in
my INBOX, and I had to delete them all manually.  I'm not sure if
running 1.5.x on all machines would cause the local Junk vFolder on
every system to contain the same messages (how could it--aren't vFolders
local to the machine they're created on?), but I'm certain that it won't
have any effect on my Squirremail webmail system, which I also depend
on.

Since I haven't yet found the time to set up any server-side spam
solution, I was looking forward to using the integrated spam filtering
in Evolution 1.5.x, but it appears to be rather pointless to me.  SO
many people access their email via multiple methods/machines these days,
I don't see how you expect this to result in much more but a lot of
confused and frustrated users complaining on the list and bad-mouthing
the (otherwise so great) software.

What is the Ximian fascination with vFolders, anyway?  They certainly
can be useful for organizing one's mail on a specific machine, but AFAIK
they have no relation to the IMAP standard and thus just remind me of
some sort of MS-style proprietary invention that leaves everyone else
(who uses different software) in the dark.  I realize they slightly
speed up some actions like deleting, etc. but with a multi-threaded app
is it really that much slower to command the IMAP server to copy deleted
messages into a REAL Trash folder, and copy "junked" messages into a
REAL Junk folder?  After all, that's a server-side action and doesn't
require local processing time at all.  This would make the system much
more useful in the real world, where people don't have the luxury (even
if they wanted to) of using the same mail client on every machine.

Via Squirrelmail, when I delete messages, it doesn't appear to happen
any slower than Evolution's misguided and controversial idea of having a
"virtual Trash" folder, which I and many others have complained about
before.  When Evolution automatically filters messages from my INBOX to
one of my numerous subfolders, the messages get copied very
quickly--and, as they should be with IMAP, they are merely *marked*
"to-be-deleted" in the source folder.

I guess claiming Evolution 2.0 that has support for built-in "spam
filtering" will look good in a Novell Press Release, but I'm sad to see
it's been implemented in a way that seems so useless, at least to me
personally.

I'm sorry if this has been discussed extensively on the list, I haven't
kept up with all the posts of the past few months, and just searched for
subjects matching "junk" before writing this message.

All complaints aside, Evolution 1.5 seems to be surprisingly stable and
an excellent update of the best GUI email client I've ever known.  It
also seems significantly faster.  Kudos to the team for the great
work.  
Now if we could only convince the design team that management of
vFolders, as great a concept as they are, is best left to individual
users, and trash (and now, deleting "junk") is a concept best left to
"tradition".

Eric

-- 
This message was created in a Microsoft-free computing environment.