GNOME Bugzilla – Bug 604082
Some attached emails (ie MIME digest) are empty when downloaded from IMAP
Last modified: 2011-03-21 07:46:38 UTC
Created attachment 149337 [details] screenshot of empty attachments Binary package hint: evolution Ubuntu Jaunty 9.04, Evolution 2.26.1 I am subscribed to a few Mailman powered email lists which send MIME digests (individual emails sent as attachments) to my Gmail account. I access this account using IMAP with Evolution and some of the attached emails contain empty headers, with no actual email text. These emails display fine in Gmail. This problem only showed up when I switched from POP to IMAP and I have had to set the list to send as plain text which displays fine, but makes replying to individual messages a pain as I need to copy and paste the quote, recipient, and subject text. Here's the contents of one of the "empty" email attachments if I open it in GEdit (*** substituted for addresses, etc): <------------------------------------------------------------------------------------ Content-Transfer-Encoding: quoted-printable From: ************************************** Precedence: list MIME-Version: 1.0 (Apple Message framework v935.3) To: ************** References: ************************************** ************************************** ************************************** In-Reply-To: ************************************** Date: Thu, 23 Jul 2009 14:19:03 +0200 Reply-To: ************** Message-ID: ************************************** Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Subject: Re: ********************** Message: 1 ------------------------------------------------------------------------------------> And here's the header for an attachment evolution can read from the same list: <------------------------------------------------------------------------------------ From: ************************************** Precedence: list MIME-Version: 1.0 To: ************************************** Date: Tue, 21 Jul 2009 13:13:59 -0400 Reply-To: ************************************** Message-ID: ************************************** Content-Type: multipart/alternative; boundary=0016e644ddfc652f84046f3a6187 Subject: [************************************** Message: 3 --0016e644ddfc652f84046f3a6187 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (... begin message ...) ------------------------------------------------------------------------------------>
Created attachment 149338 [details] screenshot of empty attachments with bottom attachment displayed correctly
Downstream bug report: https://bugs.launchpad.net/evolution/+bug/403682
I have the same problem with several digests/attachments. I can view them okay in Google web mail but not in Google Imap. Thunderbird imap can see them fine. Evolution displays: "mail message attachment" but when I open in an editor, I get e.g. Date: Wed, 09 Dec 2009 18:26:37 +1100 Subject: No Subject Message-ID: <1260343597.7451.135.camel@jannote> Mime-Version: 1.0 From: and that's it!
Also note that e-mail with an attachment are correctly displayed in digests.
Thanks for a bug report. I was just testing some digit issues, thus I received one and it is shown properly for me, with 2.91.91 version of evolution. I'm not sure whether was done anything directly related to this issue between 2.32.2 (actual stable) and this development version, but I suppose if yes, ten probably unintentionally. So, could you try with 2.32.2 or later version and if it'll be still reproducible, then attach here a test message, please? To avoid any previous caching issues, please remove the message from your local imap cache, located in ~/.local/share/evolution/mail/imap/<account>/... the message will be stored there in parts, but it should be enough to delete only its main part, the one with a number as a file name.
I tested with the few digest messages I still got and could not reproduce the bug either with Evolution 2.32.2 as packaged by Debian. All messages parts display correctly.
Thanks for the update. I'm closing this then.