Comment 23 for bug 365270

I'm loathe to get involved here since Knut seems intent on flaming and not so interested in understanding, but reading the comments here I've been struck by a great attention to irrelevant details and not much clear description of the real issue.

Knut continually makes reference to a "MOVE" operation, as if such a thing existed. But it doesn't. If it did, you can be sure that Evolution would use it.

Why can't Evolution create that operation? Because Evolution is a mail CLIENT. It talks to mail SERVERS. Evolution does not implement and cannot influence the servers. The only operations that the client can perform are those that the server supports. The servers implement the IMAP standard, and the IMAP standard does not define a MOVE operation. So, no IMAP server supports a MOVE operation, and so no IMAP client can use a MOVE operation.

So good, there's no MOVE operation. The only way an IMAP client can effect a move from one folder to another is by first doing a COPY, then marking the original message as deleted, and this is what Evolution and ALL OTHER IMAP CLIENTS (yes, including Thunderbird) do. That by itself is enough to blunt some of Knut's criticisms, since no client will ever be able to avoid the creation of a new message via the COPY command.

Similarly, the IMAP standard does not provide any way to delete a single message. The ONLY way to actually cause messages to disappear out of an IMAP folder is by an EXPUNGE, which takes all the messages that have been marked as deleted and removes them (not just one, but ALL of them). This is a very expensive operation, typically, for your server (as opposed to marking a message as deleted which is typically very fast). After the expunge is done, then often the client has to re-read and re-index the messages, because its local cache of which messages are marked deleted and which aren't might be wrong. The whole thing is very labor intensive on both the client and server, as well as the network.

Evolution works the way that the IMAP standard writers intended clients to work: it hides deleted messages and leaves the decision about when to expunge them up to the user.

The problem is that many other clients don't work like this. They don't hide the deleted messages, which leads to lots of confusion about duplicated messages, and they also expunge messages "for" you. For example other IMAP clients implement the semantics of MOVE by doing a COPY, marking the original as deleted, then running EXPUNGE. For every single email you delete. This is a big load on both clients and servers, AND it means that your email that you might have deleted but not wanted expunged yet, is deleted for you.

This is a shame because if all clients worked the way the standard expected them to then they'd work together well. However, just like Evolution cannot change the way servers work, so it cannot change the way other clients work. So, or course Evolution should have an option to behave the way other clients do and have a physical trash folder and implement the COPY/delete/EXPUNGE semantics that other clients favor. You won't need this if you only ever use Evolution as a client but if you switch between different clients you may need it, and Evolution should provide that support. I believe they intend to but obviously this is a low priority, based on how long these bugs have been open. That's definitely a shame.

As for Knut's other comments, he implies above that he read and understood the RFC Marc mentioned but that is clearly not the case. There's no such thing as "cardinality of indexes" in email, and there's no chance that searches will skip anything. When you do the COPY the message number on the copy is the next number in a monotonically increasing index, it is NOT "inserted" into the middle. When you EXPUNGE all deleted messages disappear and their numbers are gone, and NEVER re-used. There is no chance for confusion of duplicate message numbers, etc. during sorting or searching.