Sebastien is correct that Carl's message is missing information.  Evo
most definitely DOES mark messages as deleted and does NOT expunge them
(unless you use the Expunge action of course; the keybinding for this is
CTRL-E so it's possible Carl hit it by accident).  The entire concept of
storing your email in your main INBOX, marked as deleted, but wanting to
keep it around, is fraught with danger--it takes only a slip of a finger
to delete all those messages.  Hopefully Carl will choose a more
reliable and less dangerous method of storing wanted email in the
future, such as moving it to a folder: that's why people use IMAP after
all, for the folder support.

I don't know about the search feature issue; if it's a feature of only
newer IMAP servers it's possible Evo doesn't support it.

However, I don't think Sebastien's characterization of the bug is
correct either.  People don't want delete to erase emails.  What this
bug is asking for is that delete should actually move the emails to
another physical folder on the IMAP server, rather than what it does
now, which is mark the email as deleted on the server (and make it
visible in the virtual folder Trash).

Just to be clear, the way Evo works is the way the IMAP standard intends
IMAP to be used.  There is absolutely no question about that.  I don't
understand Busby's comment: I think he's just raising a straw man.  The
way the IMAP standard intended email moves to be done is exactly how Evo
does it: you copy the message to the target folder, then mark the
original for deletion.

IMAP is a very problematic protocol, because it lets the underlying
implementation, which is often counter-intuitive to people, show through
into the standard.  This not only means that the behavior of the server
(what things are easy and what things are hard) is visible through the
protocol, but it also biases the implementation in various ways.  For
example, IMAP assumes that it's very difficult to delete messages from a
folder: this is because many implementations of mail servers keep all
mail in a given folder in one long file: deleting a message out of the
file involves rewriting the whole file... and even for medium-sized
folders that's expensive.  Even if your IMAP server implementation used
something more intelligent such as one file per email with directories
for folders, or if it used a database backend, or whatever, so that
deletes are cheap, the IMAP standard carries with it the baggage of the
early implementations.

This also proscribes the way IMAP is intended to be used.  The model
IMAP intends is that you "save up" your deletions for a while, then do
them all in bulk.  Thus, the standard creates a "/deleted" flag (flags
are typically kept in a metadata file or even a database on the server,
that is much cheaper to manipulate than the very large raw email file).
The idea is you delete messages, and copy-then-delete messages, etc. and
at the end of these operations you run the "expunge" command and all
those deletes finally take effect.  The model is that you run "expunge"
regularly (maybe every time you exit your mail client, or maybe after
every "session" of using email), but NOT after every single delete or
copy operation (TB by default does it this way).  The way Evo works is
perfectly in line with the standard.

The standard assumes that the client has some intelligence behind the
way it handles messages marked with the /Deleted flag.  Evo uses a
virtual folder for this (I understand and agree with the issues of the
virtual folder hiding real folders with the same name: that's truly a
bug).  I've used lots of IMAP clients and I've never seen one that
didn't offer some kind of "Hide deleted messages by default" option.
Maybe there are such out there, and if so that definitely sucks for
people forced to use them.  Also apparently there are servers that
overload the /Deleted flag for other purposes that are not compliant
with the standard, such as spam, which also sucks (of course it really
sucks that IMAP was developed without, and has not been enhanced to
provide, any support for managing spam directly).

If people want to use Evo, regardless of whether you use it by itself or
with other email clients, you have to get into the habit of expunging
regularly (not after every delete, mind you, but _regularly_).  If you
do that, then switching to a different client will be no problem.  I do
it all the time with various different webmail and other IMAP clients,
including Evo, and I never have any issues.  If you don't expunge
regularly, then nothing works well.  You can say it's Evo's fault, but
it's not really: that's the way IMAP was designed to be used and that's
the best way to use it.

All that being said, I'm definitely a fan of choice and I'd dearly love
for someone to implement a solution that lets "the other side", who
can't or won't use IMAP as designed for whatever reason, have what they
want (if nothing else so we don't have to have this conversation every
few frakking months).  My personal choice would be to add new entries to
the "Defaults" tab in the Account Editor, that lets users choose a
different folder for both trash and spam, just like it currently allows
a choice of folder for drafts and sent email: the default would be the
virtual folder as it is today, but users could choose a "real" folder
instead.

As long as the default behavior is left the way it is now: the way that
the IMAP standard intends for things to work, and the way they work best
with the IMAP server, I'll be happy.

-- 
Evolution virtual trash / "real" trash on IMAP server
https://bugs.launchpad.net/bugs/13983
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to