Comment 27 for bug 13983

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.