Sending again, slightly edited... my message from 11:09 -0700 this morning hasn't arrived at the list, though a later one did...
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 significant local processing time. 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. It's not reasonable to expect me to delete and expunge the Junk folder every time I leave Evolution. I guess if that were an option I might be a little happier. 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. _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
