GNOME Bugzilla – Bug 451232
Sent folder mail silently lost after IMAP server change
Last modified: 2008-07-14 08:14:14 UTC
Please describe the problem: I recently had to change the hostname of the IMAP server I use at my hosting provider - this was a complete server name change, not just e.g. a subdomain. However, the IMAP server itself remained the same - it was a load balancing / DNS change. Prefernces -> (Account) Edit -> Receiving Mail I changed the "Server" field to the new server name (and also changed the outgoing SMTP server) but kept all other account settings the same. A few days later I noticed my sent mail had not been saved to the Sent folder on my IMAP server (as it was configured to do, and previously had done). Re-selecting the Sent (and Drafts) folder in the Account Preferences fixed this (though the resulting folder name looked the same (e.g. "INBOX/Sent") I presume the underlying implementation has an INBOX/Sent for both the old and new server name). Steps to reproduce: 1. Set sent folder to a folder on an IMAP server 2. Change the server name 3. Send an email - the copy is no longer placed in the sent folder; there is no error message. The Sent email is lost. Actual results: Sent email copies are lost. Or at least I can't find them - is there anywhere else I can look? (I'd quite like them back!) Expected results: I can see how, from Evolutions perspective, the mail server has changed - so it can't save to the previously configured Sent folder (which, being tied to the old serve name, no longer exists). However, it should at least produce a warning at some point - not just silently fail. Perhaps when the server name is changed a warning should be shown? Or when Evolution tried to save to a now non-existant folder? Also, because Evolution only displays the folder name - not the server name - in the Defaults Preference dialogue (e.g. "INBOX/Sent" rather than "INBOX/Sent (oldimap.example.com)" ), there's no indication that the Sent folder is now invalid. Does this happen every time? Yes. Other information:
There is definitely a duplicate of this lying around.
It's probably bug #349870, where the results are same, only the circumstances are a bit different. But some fix there will fix this too. Thus marking as duplicate. *** This bug has been marked as a duplicate of 349870 ***