User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13 Build Identifier: Thunderbird version 2.0.0.12 (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: chris@orr.me.uk 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 From: chris@orr.me.uk To: chris@orr.me.uk b 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. Thanks.

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 WW91IGhhdmUgZGVjb2RlZCB0aGlzIHRleHQgZnJvbSBiYXNlNjQu However, if I encode the string "You have decoded this text from base64." I get the result: WW91JTIwaGF2ZSUyMGRlY29kZWQlMjB0aGlzJTIwdGV4dCUyMGZyb20lMjBiYXNlNjQu 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.

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)

Looks a lot like bug 333880

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.

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.

http://hg.mozilla.org/comm-central/rev/28380252259ecaefc75ffdaa826f8408d6538187 -> WFM

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: VGhpcyBpcyBhIHRlc3QgbWVzc2FnZS4K 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.

Yes. Note that this bug is closed.