GNOME Bugzilla – Bug 351413
Trashed IMAP mail seam to get lost when read by other mail clients
Last modified: 2009-09-04 03:55:26 UTC
Please describe the problem: I would like use Evolution to read my IMAP (cyrus) mail from Evolution from my desktop, and to use Squirrelmali to get web access when I am on the road. If I Trash a message in Evolution, and later decide to untrash it from Squirrelmail it simply doesn't show up in the Squirrelmail trash folder, and if I go back to Evolution the mail is gone. Meaning that you can't undelete it, and the mail is gone for ever. Other mail clients like e.g. Thunderbird doesn't seam to have the same problem, so I assume Evolution is the culprit. Steps to reproduce: 1. Trash a mail in Evolution by selecting it and hit the Trash icon in the panel. 2. Read your mail in Squirrelmail 3. Fail to find the the trashed mail in the squirrelmail mailbox 4. Read mail in Evolution 5. Verify that the mail now is gone from the Evolution mailbox as well. Actual results: I can't recover a Trashed mail. Expected results: Mail should be moved to the INBOX/Trash folder and stay there until I empty the trash regardless of what client I use. Does this happen every time? Yes Other information: This basically renders Evolution useless to us, which is pity as it otherwise integrates well with the Gnome Desktop and are otherwise more or less enterprise ready.
disable syncing evo's mailbox with the IMAP server's mailbox then. ;-)
(In reply to comment #1) > disable syncing evo's mailbox with the IMAP server's mailbox then. ;-) > Not really a working solution. Sure, it prevents mail from being accidentally deleted, but it also makes IMAP with multiple clients totally unworkable. It means that I have to delete messages twice, once in evo and once in my webmail client. If I delete a message in evo and then use in squirrelmail, the message is still there. If I then delete it in squirrelmail the message is moved to the folder INBOX.Trash. Then if I get back to evo the message is now not in the evo trash, but in yes. you guessed it, INBOX.Trash and will not be emptied if I do empty trash from evo. What if I want to move the message to some other folder, If I move it in evo, it will still be unmoved when I look at it in squirrelmail. What if I then decide to move it again from squirrelmail, but this time happens to classify the message differently this time and decide to move it to a different folder. If I do I will end up with two copies of the message. The real problem here, seam to be that evo handles Trash differently than most other IMAP clients. Other clients move messages to a real serverside IMAP mailbox while evo keeps it on the client side. This also causes other these serious interoperability issues. For one thing, it makes it impossible for the server to move things to the (evolution) trash with a script on the server side. In a world where people are more and more connected using various tools (e.g web, PDAs, Evolution,..) depending on their current situation. Being able to access mail from different clients is very important. As far as I know there is no way to make Evolution handle Trash like a standard IMAP forlder. This should be the fix for this problem, not turning off synchronization.
well, depends on what trash means for other IMAP client. Evolution's trash is a (virtual) folder that only displays messages with the "deleted" flag on the server. This means that until the server decides to make some space it will remain in evolution trash folder. Some IMAP clients just move the mail to the an IMAP folder named trash so that it has the same behavior as whatever OS you are using. I bet that squirrelmail is automatically "compacting" IMAP folders (removing "deleted" flaged messages) for you which is in fact the problem. Thunderbird has a setting to does this for you when it saves more than X kb on the server but it might be disabled iirc. I won't conclude on which approach is the best since I think both have pros and cons but here, the problem is most likely that squirrelmail does something in your back that evolution doesn't expect.
(In reply to comment #3) > well, depends on what trash means for other IMAP client. > > Evolution's trash is a (virtual) folder that only displays messages with the > "deleted" flag on the server. This means that until the server decides to make > some space it will remain in evolution trash folder. Some IMAP clients just > move the mail to the an IMAP folder named trash so that it has the same > behavior as whatever OS you are using. Being able to do things in the same way regardless of OS or client is quite important for an application like e-mail. As far as I can tell, the majority of all IMAP clients handles trash as a serverside folder. Having a clientside folder is sort of not in the spirit of IMAP where things are supposed to be handled on the server side. > > I won't conclude on which approach is the best since I think both have pros and > cons but here, the problem is most likely that squirrelmail does something in > your back that evolution doesn't expect. > This is the root of the problem. Evolution shouldn't have to expect anything. Especially, it shouldn't expect something that in 9 cases out of 10 will be wrong if people sometime tries to access their mail with other clients than Evolution.
> (In reply to comment #3) > > well, depends on what trash means for other IMAP client. > > > > Evolution's trash is a (virtual) folder that only displays messages with the > > "deleted" flag on the server. This means that until the server decides to make > > some space it will remain in evolution trash folder. Some IMAP clients just > > move the mail to the an IMAP folder named trash so that it has the same > > behavior as whatever OS you are using. > > Being able to do things in the same way regardless of OS or client is quite > important for an application like e-mail. As far as I can tell, the majority > of all IMAP clients handles trash as a serverside folder. Having a clientside > folder is sort of not in the spirit of IMAP where things are supposed to be > handled on the server side. > I agree that interoperability is good. Nevertheless (and this is my own pov, not necesseraly evo's devs pov), trash is trash and I think that evo is doing the right thing here. If you are not sure that you will want the message you just trashed later, then don't trash it. Backup it somewhere else but just don't use the trash as a last chance folder for your mails. Btw, the trash system that evolution uses is serverside since it shows also mails marked as deleted on the _server_ so it's perfectly in the "spirit" of IMAP.
I agree with Uno that this is a bug. I use 1und1.com, and I'm not sure what Webmail server they use, but I see similar behaviour as Uno. For example, if a delete a mail in Evolution and then open Webmail (while Evo is still running), the mail is permanently gone from Evo. Gilles proposed Semantics of the Trash is possible, but inconsistent with almost all other Trash folder semantics in other mailclients and also OS's. People expect their Trash to hold deleted things until deleted from there, possibly with an option to empty trash automatically on specified intervals, or automatically deleting items which are older than a given value. Evolution's Trash semantics is unique to it (again, among popular mail clients and OS's), and I think this is a bad thing.
The real problem is that there is no move command in IMAP. Evolution implements move as copy to destination folder, followed by "mark for deletion" of the original. Most other e-mail client implements it as copy, mark for deletion and expunge. The expunge part will no only erase the last moved mail but also all other mails marked for deletion in the same folder. Then, each time one will move a mail from a folder in another client, all mails trashed in Evolution (marked for deletion) in the same folder are lost. The problem is reinforced by the fact that nearly all other clients implements delete by "move to trash". Each time a mail is trashed in the other client, mails trashed from Evolution (in the same folder) are lost. Some clients (especially web mails) may also delete (expunge) automatically all mail marked for deletion. They are after all "marked for deletion" which many interprets as "not to be archived, not yet deleted only for performance reasons". Finally, although I have no example, one could imagine an IMAP server deleting mails marked for deletion regularly to compact mailboxes (e.g. when quota is exhausted). Another problem with the Evolution's approach is that moved mail are duplicated (as they remain in source folder), which quickly leads to quota problems when one is not willing to expunge (I archive trashed mails for two years). This duplication is also visible with the Trash virtual folder which is also confusing. Although one may argue that Evolution's behaviour is the 'right' one, this behaviour prevents the use of Evolution with other mail clients, with limited quota IMAP servers, and continuously confuses users as attested by the numerous bug reports for these two issues. So, I am strongly in favour of: 1. A real move to trash which moves to trash rather than mark for deletion. 2. A move commands which expunge in the source folder (in order to reduce mailbox space consumption).
This is bug 206061 again. It's been open for 7 years now! At one point a couple of years ago people (apparently even including some Novell evolution developers) appeared to agree that it should be fixed, but nothing ever came of it. Evolution is clearly the odd-MUA-out WRT trash handling.
*** This bug has been marked as a duplicate of bug 206061 ***