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

RESOLVED WORKSFORME

Status

defect
--
major
RESOLVED WORKSFORME
11 years ago
3 years ago

People

(Reporter: chris, Assigned: mkmelin)

Tracking

(Depends on 1 bug, Blocks 1 bug, {testcase})

unspecified
Thunderbird 15.0
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments)

Reporter

Description

11 years ago
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.
Reporter

Comment 1

11 years ago
A minimal test case consisting of an email containing a message/rfc822 attachment which has a base64-encoded body.
Reporter

Comment 2

11 years ago
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.
Assignee

Comment 3

11 years ago
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.
Reporter

Comment 4

11 years ago
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.
Reporter

Comment 5

11 years ago
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.
Reporter

Comment 7

11 years ago
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.
Posted image Reply window
Posted 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)

 
 
Status: UNCONFIRMED → NEW
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.
Assignee

Comment 16

7 years ago
Yes, this is working. Let's keep it that way.
Assignee

Comment 17

7 years ago
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+
Assignee

Comment 19

7 years ago
http://hg.mozilla.org/comm-central/rev/28380252259ecaefc75ffdaa826f8408d6538187 -> WFM
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
OS: Windows XP → Windows 2000
Hardware: x86 → All
Resolution: --- → WORKSFORME
Target Milestone: --- → Thunderbird 15.0
Assignee

Updated

7 years ago
Assignee: nobody → mkmelin+mozilla
OS: Windows 2000 → All

Comment 20

5 years ago
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.

Comment 21

3 years ago
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)
Assignee

Comment 22

3 years ago
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.