Re: [Evolution] Spamassassin, Junk/Not-Junk, Training
- From: Jeffrey Stedfast <fejj ximian com>
- To: Eric Lambart <ximian nomeaning net>
- Cc: Evolution <evolution ximian com>
- Subject: Re: [Evolution] Spamassassin, Junk/Not-Junk, Training
- Date: Thu, 20 May 2004 14:38:08 -0400
On Mon, 2004-04-26 at 11:09 -0700, Eric Lambart wrote:
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.
you mean like physical Trash and Junk folders would be on IMAP as
different clients will have different names for those physical folders
as well, so what you are arguing for is just as broken as what you are
And... the author of the IMAP specification actually envisioned "Trash"
not being a physical folder anyway (hence why the IMAP spec does not
define one) and that clients would either display a message-list with a
flag set (a strike-through in our case) or provide a virtual Trash
folder (which we also provide).
if you read the whole discussion on the IMAP forums from years back,
there were some complaints by IMAP client authors because they weren't
as ingenious as we (mostly Zucchi) were and so weren't able to implement
vTrash as efficiently as we did :-)
Just because other IMAP client authors were incompetant doesn't mean we
should implement it the same way they did :-)
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
yes, because the IMAP backend can only process one thing at a time
(hence only one thread can be doing something with the IMAP server at a
, and copy "junked" messages into a
REAL Junk folder?
same as above
After all, that's a server-side action and doesn't
require local processing time at all.
but it does require more round trips and can indeed require client-side
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.
this is all in your head (and/or crap IMAP clients)
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,
squirrelmail is a local process on the IMAP server itself. Evolution
does not have that luxury. so this isn't really a fair comparison.
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
useless to you does not mean useless to everyone else. Mozilla works
similarly to Evolution, as does Apple's Mail.app as far as spam
filtering. They don't move messages to another folder either, they
simply flag the message and leave it in the INBOX (or where ever).
Since there's no universally accepted IMAP flag for "spam", each client
is on its own.
Evolution Hacker - Novell, Inc.
fejj ximian com - www.novell.com
] [Thread Prev