Closed Bug 425455 Opened 14 years ago Closed 10 years ago

Forwarding inline or replying to a base64-encoded rfc822 attachment results in garbled text


(Thunderbird :: Mail Window Front End, defect)

Not set


(Not tracked)

Thunderbird 15.0


(Reporter: chris, Assigned: mkmelin)


(Depends on 1 open bug, Blocks 1 open bug)


(Keywords: testcase)


(5 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20080311 Firefox/
Build Identifier: Thunderbird version (20080213)

Opening a message/rfc822 message that was attached to an email, then attempting to reply to it gives you garbled text in the composition window.

This occurs in the case that the attached rfc822 message has a Content-Transfer-Encoding of base64.

Reproducible: Always

Steps to Reproduce:
1. Send the attachment below to your self (i.e. place it in your maildir, or SMTP it to yourself)
2. View this new mail in your inbox
3. Double click the attachment "Original base64 email.eml" to open it
4. This attached opens in a standalone message window
5. Press "Reply" on the toolbar
Actual Results:  
A composition window appears with garbled text.

If "Reply" was pressed, the garbled text consists of the attachment's text being base64-decoded (again).

If "Forward As" -> "Inline" is chosed, the garbled text consists of the same as "Reply", but is truncated, seemingly after 

Expected Results:  
The original text of the attached message/rfc822 attachment should be in the composition window.

i.e. That text should not be base64-decoded twice.

Is possibly related to bug 173012, however that didn't seem to relate to attached messages.
A minimal test case consisting of an email containing a message/rfc822 attachment which has a base64-encoded body.
Also similar is bug 383118, but that one appears to be stalled due to lack of a clear test case attached.

As for comment 0, I inadvertantly made a stupid number of spelling mistakes and truncated my text about using inline forwarding being truncated(!)

If "Forward As" -> "Inline" is chosen, the garbled text consists of the same as when pressing "Reply", but the garbled text is truncated, seemingly after the first non-ISO-8859-1 character.
Trying to reply to "Original bas64 email.eml" gives me a blank window on trunk. Forward inline gives me the text, non-garbled though. 

For this test case, I don't know what you mean with the truncating, there is no  non-ISO-8859-1 character in the test case.
Hi Magnus,

When I reply, the string "You have decoded this text from base64." from the attached email gets base64-decoded (unnecessarily) and put into the composition window.

So the composition window says: wrote:
> b��j�y�y�a��^���f?"

Where that string is the set of bytes beginning: 62 8b a1 6a f7 9d 79 ca.

When I forward inline, the composition window says:
-------- Original Message --------
Subject: Original base64 email
Date: Thu, 27 Mar 2008 17:50:00 +0000


So the message (although incorrect) appears to be truncated after the first code point, 62 ('b').  My *guess* is that happens because the second character is non ISO-8859-1 (which is my default composition encoding).

Anyway, that's not the main issue here, but thought I'd try and clarify a bit more. :)  I'll try and reproduce this with a nightly build.

The exact same behaviour occurs for me on both "Reply" and "Forward inline" using the latest-trunk nightly build, which in this case was version 3.0a1pre (2008032802).
I see the same symptoms as you.
From the source:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64


However, if I encode the string "You have decoded this text from base64."
I get the result:

So, my thinking is that this is INVALID do to incorrect base64 encoding.
Not sure if the charset="utf-8" has anything to do with that conclusion though.
Joe, when you say you have the same symptoms, do you mean you also suffer the original problem with a recent build?

I'm not sure how you did your base64-encoding, but if I *decode* what you just posted, I get "You%20have%20decoded%20 ...", i.e. you've first URL-encoded the original text, and *then* base64-encoded it.

Indeed the UTF8 charset has no bearing on this; the text, being only 7-bit ASCII, is valid UTF8.

Either way, the issue is that the reply composition window should *not* be doing any base64-decoding, as it has already been done.
Attached image Reply window
Attached file eml with base64
The problem seems to have nothing to do with errors in base64 encoding.
But everything to do with how we handle eml's

Simplified steps to reproduce:
 Save attachment id=329175 to disc.
 Open it with TB (note that the base64 encoding has been converted to text)
 Create a new mail and attach that eml to it and save it.(send later)
 Open that mails attachment and reply.(note that TB has re-converted base64 data)

Ever confirmed: true
Looks a lot like bug 333880
Keywords: testcase
Duplicate of this bug: 383118
Duplicate of this bug: 538602
Blocks: 269826
Duplicate of this bug: 540739
I can not reproduce this issue with attachment 329175 [details] on trunk build.
Yes, this is working. Let's keep it that way.
Comment on attachment 617329 [details] [diff] [review]
mozmill test to ensure we don't regrress

Tests only.
Attachment #617329 - Flags: review?(mbanner)
Comment on attachment 617329 [details] [diff] [review]
mozmill test to ensure we don't regrress

Review of attachment 617329 [details] [diff] [review]:

Looks great, thanks for the test.
Attachment #617329 - Flags: review?(mbanner) → review+ -> WFM
Closed: 10 years ago
Flags: in-testsuite+
OS: Windows XP → Windows 2000
Hardware: x86 → All
Resolution: --- → WORKSFORME
Target Milestone: --- → Thunderbird 15.0
Assignee: nobody → mkmelin+mozilla
OS: Windows 2000 → All
I am currently seeing this bug with Thunderbird 31.2.0 on Ubuntu 14.04 (User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0); on Mac OSX 10.6.8 (User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.2.0), and on Windows 7 (User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0)

Steps to reproduce:
1) open the attached msg.eml file in Tbird
2) save the test.eml file from the message to disk
3) view the saved test.eml file - you will see that 
the message body of the test.eml message has been decoded from the base64 encoded:


to the text

This is a test message.

but the

Content-Transfer-Encoding: base64

header remains.
Does Magnus's test case use a single-part message?  Both this report and bug 844208 refer to a multi-part message.
Flags: needinfo?(mkmelin+mozilla)
Yes. Note that this bug is closed.
Flags: needinfo?(mkmelin+mozilla)
You need to log in before you can comment on or make changes to this bug.