GNOME Bugzilla – Bug 666325
[IMAP] doesn't display messages correctly on specific server
Last modified: 2012-04-18 08:49:20 UTC
I have three IMAP accounts added to Evolution 3.2.2 on Fedora 16. Of these three, Evolution can't handle one specific IMAP account, which is my mail account for the University of Leiden. I have attached screenshots demonstrating the problem. I emphasize that Evolution is the only e-mail client giving problems, Kontact and Thunderbird (screenshots for comparison) have no problems with it at all. Some messages on this account do not show problems, but Evolution displays HTML-tags on certain messages as plain text and it tries to display a PDF-document which is attached to a certain e-mail as garbled text. Compare the first e-mail, *mail_1. Thunderbird displays it correctly, Evolution doesn't. However, I figured out that if in Evolution when I go to Edit, Preferences, Mail Preferences, HTML Messages and set HTML mode to 'Show plain text if present' (as far as I know 'Show HTML if present' is the default) then Evolution can display the first e-mail correctly. However, changing that makes no difference for the second e-mail, *mail_2, which Thunderbird displays correctly but Evolution doesn't.
Created attachment 203607 [details] First e-mail displayed in Evolution.
Created attachment 203608 [details] First e-mail displayed in Thunderbird.
Created attachment 203609 [details] Second e-mail displayed in Evolution.
Created attachment 203610 [details] Second e-mail displayed in Thunderbird.
The messages probably have an incorrect Content-Type header. Can you post the raw messages here so I can take a look at the headers?
Created attachment 203779 [details] mbox file of second e-mail (with PDF attached) as seen by Evolution
Created attachment 203781 [details] mbox file of second e-mail (with PDF attached) as seen by Evolution
Created attachment 203782 [details] mbox file of second e-mail (with PDF attached) as saved by Thunderbird
Created attachment 203783 [details] mbox file of another e-mail (with only text) as seen by Evolution
Created attachment 203784 [details] mbox file of another e-mail (with only text) as saved by Thunderbird
To be clear, the second e-mail I mention in the second series of attachments is also the second e-mail mentioned in the first series of attachments, i.e. the e-mail with the PDF attached. I also added mbox files of 'another' e-mail (not part of the first series of attachments which are screenshots) which does not have any attachment. This e-mail is also displayed as unintelligible text by Evolution, but is displayed correctly by Thunderbird. It seems I discovered a second problem when I tried to save the mbox files of the two e-mails attached here in Evolution. I selected the e-mail in Evolution, chose View → Message Source and then chose File → Save as mbox... in the window that displayed the message source. The mbox files saved by Evolution only contained the 'From' header and nothing else, however. So I had to copy and paste the text in the message source window manually to save it to the mbox files. It seems that if Evolution can't display the e-mails correctly, it also can't save them correctly to mbox (what you see in the message source window is not what you get in the saved mbox file). Thunderbird did not have this problem, not only did it display the e-mails correctly, it also saved them correctly to mbox files.
I forgot to mention, I just compared the content type headers of attachment #5 [details] and attachment #6 [details], but it seems to me like they are a match. Yet, even though the content type headers match, Evolution can't display the message correctly while Thunderbird can; this seems to indicate that nothing is wrong with the e-mails, but that something is wrong with Evolution?
Thanks for a bug report. I took the later message (saved from Thunderbird) and imported it into my evolution, under On This Computer, where it is shown correctly. Then I right-clicked on that message and chose "Copy to Folder" where I selected a folder in my IMAP account. The message have been copied and I opened it. I saw correct message again. Then I let the message refetch from my server again, and even tried my IMAP+ account for the same folder, and both read the message properly. I guess there is something going wrong while the message is received from your server. Checking the difference on the message saved from evolution (by the way, you can right-click the message in the main Mail view, where is also shown "Save as mbox", but it will probably do the same issue for you, which I agree is most-likely caused by incorrectly downloaded message) and the one from Thunderbird, and even they have the main message content-type same, then in evolution is missing the first subpart, which is multipart/alternative, which basically instructs the mime reader that it should use the best part for viewing it can from those present here. The part's content-type in Evolution is text/plain, thus it behaves just like that, showing the content as plain text, instead of dealing with subparts as subparts. Are you using IMAP or IMAP+, and if IMAP+, what are the Receiving Options in the account, please? Also, could you try to reload the message from the server, please? You can do that by closing evolution, and then open ~/.local/share/evolution/mail/<imap-account-id>/folders/Inbox , where are stored all the messages currently downloaded from the server. Finding the one might be tricky, thus I suggest to take all files from there and move them to another folder, and after test is finished then return them back (again while evo is closed). Picking the right <imap-account-id> might be tricky too. I see from your screenshot that this account has no subfolders under Inbox, thus it should be the one which has ~/.local/share/evolution/mail/<imap-account-id>/folders/Inbox/subfolders folder empty. Anyway, these files, for IMAP account, are just local copies of server data, thus if anything happens to them then the worst would be that you might need to redownload them all from the server again. Then run evolution and pick the message and see, whether it'll be incorrectly downloaded.
Thank you very much for looking into this Milan, and sorry for my late reply. The account uses plain IMAP. I followed you instructions and moved the INBOX directory of the account to another location so that Evolution had to re-download all messages. Unfortunately nothing changed. To be thorough I also decided to use my laptop which has the Fedora 17 Alpha installed to test this. This installation was a blank slate and the Evolution 3.4.0.1 installation on it wasn't used before, but there the same thing happened when I added the offending e-mail account. Some of the e-mail messages still don't download and display correctly. If it proves difficult to pinpoint the problem in this case, I'm willing to provide the Evolution developers with my username and password if it makes it easier to find the problem.
Thanks for the update. As the simplest test, could you try to change your account to IMAP+, restart evolution and check whether it'll help in any way, please? These two are behaving differently with respect of message fetching, thus it can be that the other will fetch messages properly. If not, or you still want to give a try to the IMAP provider, then you can get a log of its operations by running evolution like this: $ CAMEL_DEBUG=all evolution &>log.txt Beware, the log can contain private information, from server names and user names up to passwords. And the log will be pretty large. You may want to do the cache cleanup again, thus the log will show what was downloaded when you selected the message to be shown. I prefer to use 3.4.0, if you do not mind, as it's the most recent code.
Switching the account to IMAP+ fixed it, e-mails render fine now. After reading up on what IMAP+ is [1] and considering that 15 months ago it was already planned that it would replace the existing IMAP backend, I wonder what the status of the replacement plan is? I hope IMAP+ becomes the default soon, I had the fortune to report this as a bug and to be informed here that switching it to IMAP+ might fix it, but other users might be left clueless if Evolution gives them problems like this. I'm not sure if I should mark the bug as fixed, because technically there still is a bug in that Evolution doesn´t work well with that specific IMAP server if I choose the default IMAP backend. Thank you so much for your advice Milan. If we ever the opportunity to meet at the Desktop Summit or GUADEC I'll certainly buy you a beer. [1] http://chenthill.wordpress.com/2010/01/11/evolution-with-improved-imap-support-imapx/
(In reply to comment #16) > Switching the account to IMAP+ fixed it, e-mails render fine now. After reading > up on what IMAP+ is [1] and considering that 15 months ago it was already > planned that it would replace the existing IMAP backend, I wonder what the > status of the replacement plan is? They are coexisting currently, because there are features which IMAP has and IMAP+ not (and vice versa, but the transition should be IMAP -> IMAP+, not the opposite). > I hope IMAP+ becomes the default soon, I had the fortune to report this as a > bug and to be informed here that switching it to IMAP+ might fix it, but other > users might be left clueless if Evolution gives them problems like this. It is a default already, when you do Edit->Preferences->mail Accounts->Add, then the preselected account type is IMAP+. I agree it's rather confusing to provide IMAP and IMAP+ providers for regular users, but I prefer IMAP personally. > I'm not sure if I should mark the bug as fixed, because technically there still > is a bug in that Evolution doesn´t work well with that specific IMAP server if > I choose the default IMAP backend. That's the problem, it's that specific server. I think it's related to functionality of IMAP, which downloads message parts on demand, not at once, and thus the server may not support it properly or something. Public servers like GMail don't have issue with this approach. Nonetheless, I'm only guessing here. Anyway, even not fixed, I'll close this as WontFix, in a meaning of "will not fix the issue in IMAP provider, because IMAP+ works fine with the same server and because it had been found/reported only for one specific server so far" (though the first 'because' is more relevant). Thanks for all the testing of this.