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

[Not Zed <notzed ximian com>]

This is a bizarre email.  What are you on about?  1.4.x doesn't support junk, so what has 1.4.6 got to do with it at all?

Very strange, you appear to be quite confused.

Anyway just use filters then, evo gives you the choice.  If you choose not to use it thats your problem.


On Mon, 2004-04-26 at 11:09 -0700, Eric Lambart wrote:
> 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

Michael Zucchi <notzed ximian com> Ximian Evolution and Free Software Developer

Novell, Inc.