Last Comment Bug 333880 - Attachment message/rfc822 in base64 not decoded for inline display
: Attachment message/rfc822 in base64 not decoded for inline display
Status: NEW
: testcase
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 4 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 399451 (view as bug list)
Depends on:
Blocks: 269826 425455
  Show dependency treegraph
 
Reported: 2006-04-13 10:31 PDT by Mike Cowperthwaite
Modified: 2015-09-25 05:48 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
First test case (8.81 KB, message/rfc822)
2006-04-13 10:34 PDT, Mike Cowperthwaite
no flags Details
Second test case (8.82 KB, message/rfc822)
2006-04-13 10:35 PDT, Mike Cowperthwaite
no flags Details
A regularly attached email that works fine. (2.14 KB, application/octet-stream)
2011-06-01 23:35 PDT, Michael
no flags Details
A base64-encoded attached email that doesn't work. (2.56 KB, application/octet-stream)
2011-06-01 23:36 PDT, Michael
no flags Details
An email in EML format that does trigger the error (open as file in TB) (2.75 KB, text/plain)
2012-09-19 07:13 PDT, Christian Schmidt-Guetter
no flags Details
The email as added before (changed a bit), but with NO error while opening. (2.74 KB, text/plain)
2012-09-19 07:21 PDT, Christian Schmidt-Guetter
no flags Details
Raw message source of a message illustrating the problem. (2.47 KB, application/octet-stream)
2013-01-08 14:10 PST, Mark Sapiro
no flags Details

Description Mike Cowperthwaite 2006-04-13 10:31:01 PDT
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
Comment 1 Mike Cowperthwaite 2006-04-13 10:34:12 PDT
Created attachment 218311 [details]
First test case

This case shows only the message body inline in the message window.
Comment 2 Mike Cowperthwaite 2006-04-13 10:35:58 PDT
Created attachment 218312 [details]
Second test case

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.
Comment 3 Mike Cowperthwaite 2006-04-13 10:41:50 PDT
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.
Comment 4 Mike Cowperthwaite 2006-04-24 22:28:27 PDT
(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.
Comment 5 Magnus Melin 2007-10-12 10:30:29 PDT
*** Bug 399451 has been marked as a duplicate of this bug. ***
Comment 6 Stephen Bosch 2009-07-10 15:26:45 PDT
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.
Comment 7 Mariusz Dykierek 2011-05-18 03:34:51 PDT
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.
Comment 8 Michael 2011-06-01 23:35:38 PDT
Created attachment 536827 [details]
A regularly attached email that works fine.
Comment 9 Michael 2011-06-01 23:36:27 PDT
Created attachment 536828 [details]
A base64-encoded attached email that doesn't work.

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.
Comment 10 Curtis 2011-10-27 13:41:48 PDT
(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.
Comment 11 Carlos G Mendioroz 2012-01-28 03:16:47 PST
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!
Comment 12 Christian Schmidt-Guetter 2012-09-12 04:49:35 PDT
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.
Comment 13 Christian Schmidt-Guetter 2012-09-19 07:13:44 PDT
Created attachment 662545 [details]
An email in EML format that does trigger the error (open as file in TB)
Comment 14 Christian Schmidt-Guetter 2012-09-19 07:21:13 PDT
Created attachment 662547 [details]
The email as added before (changed a bit), but with NO error while opening.

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.)
Comment 15 Mark Sapiro 2013-01-08 14:10:06 PST
Created attachment 699425 [details]
Raw message source of a message illustrating the problem.

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.
Comment 16 Christian Schmidt-Guetter 2013-01-21 05:42:23 PST
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).
Comment 17 Michael 2013-05-23 02:19:44 PDT
(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.
Comment 18 Christian Schmidt-Guetter 2013-08-27 09:16:58 PDT
(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)...
Comment 19 Ralf Hauser 2014-01-02 04:10:56 PST
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"
Comment 20 Ludovic Hirlimann [:Usul] 2015-09-25 05:48:02 PDT
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Note You need to log in before you can comment on or make changes to this bug.