Someone in mozilla.support.thunderbird was complaining about not being able to see images in a forwarded message. I got a copy of that failing message, and was able to distill the problem to a simple testcase. The message was part of a forward-chain of "funny photos." Someone had forwarded as attachment, and three subsequent people had forwarded inline. One of those clients took the attachment and converted it to base64. In the version I received (the reporter's original message, forwarded-as-attachment to me using TB 1.5), the base64 text appeared *as* base64 text in the message window (with Display Attachments Inline turned on). I reduced the data into the following testcases. Reporter also had a problem with saving the attachment, getting the error "Unable to save the attachment. Please check your file name and try again later." I'm unable to reproduce this with the message as sent. Interestingly: the reporter originally forwarded me the message inline -- and that forwarded version displayed the attachment as expected. It had been decoded back to plain text during TB's compose/send. This is reproduceable with both of the following testcases. Steps to reproduce: 1) Set View | Display Attachment Inline 2) Open either of the messages attached to this bug with Thunderbird (File | Open). 3) Select Message | Forward as | Inline 4) Forward the message (or just Send Later) to any convenient address 5) View the forward in the Sent (or Unsent) folder 6) In the original message, select the .EML file in the attachment pane and save to disk 7) Open the saved .EML file with Thunderbird Actual results: 2) Either nothing is displayed inline for the attachment (first case) or raw base64 data is displayed inline 5) The attachment is displayed inline (an HTML with some small embedded images) 7) The saved EML is nothing but raw base64 Expected results: 2) The attached message is displayed inline 7) The saved EML is displayed like a message

This case shows only the message body inline in the message window.

This message shows raw base64 data inline. The difference between this and the previous case is, there's a second blank line in the MIME part between the headers and the data. However, if this message is forwarded inline, it will be decoded properly, just as the first test case is.

Incidentally, the display issue of this occurs in TB 1.0, 1.5, 2a1-0328 and 3a1-0412, Win2K. Forwarding from an opened .EML requires 2a1 or later.

(In reply to comment #2) > The difference between this and the > previous case is, there's a second blank line in the MIME part between the > headers and the data. See bug 335189: this blank line between the headers and the data is a general issue with inline base64.

I have a similar problem with Thunderbird 2.0.0.22 in Windows, but the saved .eml file is readable and behaves normally. The main e-mail appears fine. It contains an attachment with an .eml extension. When I double-click on that attachment, a new window opens up which has the header information but is otherwise completely blank. I cannot look at the message source. If I right click on the original .eml attachment and save it somewhere, then open it from the operating system, Thunderbird loads the message, and both the contents and the attachments are visible and accessible. That's an ugly workaround. The setting of "Show attachments inline" doesn't make any difference.

My colleagues and I are getting dozens of "message/rfc822" with "base64" encoding from Outlook users via GMail commercial accounts. They cannot be open by TB 3.1.10 - show "This attachment appears to be empty" instead. Despite it is illegal encoding for this kind of attachments, looks like other clients (tested KMail) cope with that somehow.

Thought I'd add in my +1. Django seems to encode attached emails in this fashion, which causes some problems! I've been able to replicate the issue with Evolution as well (although the examples given do not even load in Evolution at all), but messages encoded like this work fine in mutt and Apple Mail. I've added a couple more test cases which caused problems for me, the 8bit encoded email works fine, but the base64 one does not (despite it having identical content inside). Thunderbird instead returns: """This attachment appears to be empty. Please check with the person who sent this. Often company firewalls or antivirus programs will destroy attachments.""" Viewing the source of the email in Thunderbird shows the base64 blob in tact. I've filed a similar bug on the Gnome Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=651197 Mariusz, I was wondering what reference you have for this being an illegal way to encode the attachment? Not that it helps with proprietary email clients that encode in this fashion, but it may be helpful if something needs to be changed in Django.

(In reply to Michael from comment #9) > ... > Mariusz, I was wondering what reference you have for this being an illegal > way to encode the attachment? From http://www.faqs.org/rfcs/rfc2046.html: ----- 5.2.1. RFC822 Subtype ... No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. ----- Given the popularity of Outlook's message/rfc822 base64-encoded attachments, perhaps Thunderbird should go ahead and decode/display them, despite being non-standard. One workaround is to view the message source and manually select/decode the base64 text (e.g. via the Mnenhy addon) but this kind of manual workaround quickly gets quite tedious with multiple attachments.

I've just encountered this after upgrading from TB2.0 to 9.0.1 (If it works, don't fix it ? :) An attachment does not even show as being there in the main window. But interestingly, if you "open message as new", it shows as attached and you can access the content from there!

Startingn with an automatically triggered Thunderbird update I'm no longer able * to view emails with base64 encoded parts (blank screen) * open emails send with Outlook from some Window clients (with base64 coded "multipart/alternative" parts). Error message: "Der Schlüssel- oder Verzeichnisname ist fehlerhaft: »/desktop/gnome/url-handlers/UTC+01/command«: Das Zeichen »+« ist in Schlüssel- und Verzeichnisnamen nicht zulässig Der Schlüssel- oder Verzeichnisname ist fehlerhaft: »/desktop/gnome/url-handlers/UTC+01/command«: Das Zeichen »+« ist in Schlüssel- und Verzeichnisnamen nicht zulässig" The very same emails (stored in an archive folder) WAS displayed with earlier versions of Thunderbird ! Please fix that - it is a stopper for me.

I could track down the problem to a test case (2 attachments). The difference between the 2 emails I added is this string: (UTC+01:00) I did checked out this for multiple emails: That string does trigger the bug. To proof this, just store the attachments as EML files and open with Thunderbird. (I'm using version 15.0.)

I'm just confirming that this bug still exists in Thunderbird 17.0.2. The attached message was saved from my Thunderbird inbox. The test_message.eml message/rfc822 part is displayed by Thunderbird 17.0.2 as the raw base64 encoding. If the 'attachment' is saved, it is saved as the raw base64 encoding, not decoded. Based on comments in this bug report, I tried removing one of the two empty lines between the part headers and the base64 encoded text. The only change with this is that Thunderbird displays no content for the test_message.eml part. It still saves this part as undecoded base64 encoded text.

This bug seems to be dependent on operating system environment. For me this bug is present until today - useing Ubuntu Linux "Ubuntu 10.04.4 LTS" with Thunderbird 17.0.2. My collegue did receive the same email from same sender, useing same Thunderbird 17.0.2 - but a Linux distribution identified as "Frugalware 1.8rc1.398.gff42fb5 (Cinna)" (cat /etc/frugalware-release).

(In reply to Christian Schmidt-Guetter from comment #14) > Created attachment 662547 [details] > The email as added before (changed a bit), but with NO error while opening. Christian, it appears the mails you've attached are completely unrelated to this bug. Neither of them contain a base64-encoded message/rfc822 part.

(In reply to Michael from comment #17) > (In reply to Christian Schmidt-Guetter from comment #14) > > Created attachment 662547 [details] > > The email as added before (changed a bit), but with NO error while opening. > > Christian, it appears the mails you've attached are completely unrelated to > this bug. Neither of them contain a base64-encoded message/rfc822 part. Yes, you are right. Sorry. I did proof it now: The original error causing email *DID* contain base64-encoded parts. But while stripping down to a simple test case, I did remove them all - not realizing, that there are now no such attachments at all. I will search for a better suitable Bug or report a new on (the error is still enabled for me)...

a quick and dirty fix (especially if you are on the sending side and still want to "protect" an "inner" digital signature with base64) appears to be to change the Content-Type to "application/octet-stream"

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.