Open Bug 392545 Opened 17 years ago Updated 2 years ago

bad display of base64 email (Thisbodypartwillbedownloadedondemand instead of body)

Categories

(MailNews Core :: MIME, defect)

x86
Windows XP
defect

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: yan_robert_fr, Unassigned)

References

()

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6 Build Identifier: 2.0.0.6 (20070728) Since i upgrade from Thunderbird 1.5 to 2.0.0.6 for security reasons, i notice the display of some mails is very "strange". (see link). This kind of strange display doesn't exist with Thunderbird 1.5, Webmails (yahoo, hotmail,stalker communigate), outlook express, outlook. I paste in the linked webpage the source code of one of the messages which can't be read with thunderbird2 I can display the message normally, but can't reproduce everytime with this procedure : open a jpg in attachment, changing the selected message, go back to the original message : the display is now correct. Reproducible: Always Steps to Reproduce: 1. Receive a mail with body in base64 (mail source in linked webpage) 2. Display it in the main window or in a new window Actual Results: The display is not the body of the mail but a sequence of (random ?) chars Expected Results: The software should display the body contained in the base64 part
Hello, additional information : i realize that the chars are always the same, and not random as I think first. the string is N¬n‡r¥ªíÂ)emçhÂyhi×¢w^™©Ý and if i do print(base64_encode("N¬n‡r¥ªíÂ)emçhÂyhi×¢w^™©Ý")); the result will be : Thisbodypartwillbedownloadedondemand the partial solution is that thunderbird doesn't display the html body and want to notidy me about that, but forgot to re-switch to standard encoding rather than base64
Keywords: regression
Summary: bad display of base64 email (random chars instead of body) → bad display of base64 email (Thisbodypartwillbedownloadedondemand instead of body)
Are you using an IMAP server for your incoming e-mail? As described in bug 204350 comment #73 part (1), I've seen this with message attachments that were forwarded and had in turn attachments in them. In that case, using IMAP, the MIME headers were correct, but the body contained the exact string only which you are listing here. The explanation was that the attachments had not been downloaded for viewing the message, and forwarding them did not download them either, instead inserting that placeholder string. Your case is different in that the *main* message body appears to be encoded in base64, not a nested attachment, correct? Thus, assuming you are using IMAP, the message may be considered (and treated) as an attachment for some reason and not downloaded when opening the message. The fact that opening/viewing some JPEG attachments inbetween seems to support that assumption. Unfortunately, I was unable to connect to your given web site to have a closer look at the original e-mail (connection timed out).
This happened to us today, with Thunderbird 3 beta 2, on Windows XP. The problematic part is the body, when sent with base-64 transfer-encoding, and downloaded over IMAP (mentioned in comment #2). Thunderbird can mangle the body, as described in comment #1. Saving the email as a file also saves the mangled body part. I'll also attach the body part, as mangled by Thunderbird, in a followup.
The email in question contained only two parts: The base-64 encoded body (attached in comment #3) and a Word document attachment. If the full eml file is necessary, I will anonymize it for upload.
Component: General → MIME
Keywords: testcase
Product: Thunderbird → MailNews Core
QA Contact: general → mime
Version: unspecified → Trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: