If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Folder fallback encoding does not work if message contains charset=""

NEW
Unassigned

Status

MailNews Core
MIME
--
enhancement
a year ago
9 months ago

People

(Reporter: Lu Wei, Unassigned)

Tracking

Trunk

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

I have a notification e-mail that always displays properly only after I select character encoding manually. I checked the headers:
....
Subject: =?utf-8?B?5Lit5Zu95Yac5Lia6ZO26KGM6YeR56mX6LS36K6w5Y2h55S15a2Q5a+56LSm5Y2V?=
MIME-Version: 1.0
Content-Type: Text/HTML;
  charset=""
From: =?UTF-8?B?5Lit5Zu95Yac5Lia6ZO26KGM?= <e-statement@creditcard.abchina.com>
Content-Transfer-Encoding: base64
....

From above I see charset is null, so that should be the cause of the problem. Fill in it "gbk" will correct it. But I have "fallback text encoding" of Inbox set to "gbk" already. So does this setting not function anymore?



Actual results:

the text in the mail is scrambled 


Expected results:

It should display the mail as GBK encoded.

Comment 1

a year ago
The fallback character set for the folder works for me. Here is what I've done.
I created a plain-text UTF-8 encoded message. I changed
Content-Type: text/plain; charset=UTF-8; format=flowed
  to
Content-Type: text/plain; format=flowed

I created myself two folders, one with fallback UTF-8 and one with Western (Windows-1252).
When I move the message to the UTF-8 folder it displays OK, in the Western folder it's garbled.

We would have to see the entire message to investigate this further. The message you mention is text/html and base64 encoded. We need to see the charset in the HTML:
<meta http-equiv="content-type" content="text/html; charset=???????">

If this message contains personal information and you don't want to attach it there, visit this website
https://www.base64decode.org/
and decode the base64 part and paste the relevant meta data into the bug.

In further testing with a HTML message I also removed the charset from the HTML and the message still gets displayed correctly if the removed HTML charset matches the folder's fallback charset.

How do you know which charset in really used in the HTML of your message? Perhaps it's not GBK. What happens if you view the message with a different text encoding from the view menu?
(Reporter)

Comment 2

a year ago
(In reply to Jorg K (GMT+2, PTO during summer) from comment #1)

I noticed you removed line (charset=""). I tried it and the message displayed correct. So the problem is located to lines:

Content-Type: Text/HTML;
  charset=""

Is that splitting of Content-Type to 2 lines illegal?

Comment 3

a year ago
Headers can be "folded", see https://tools.ietf.org/html/rfc2822#section-2.2.3.
However, charset="" seems illegal.

Thunderbird could deal which the empty value better, hence: enhancement.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: fallback encoding not work → Folder fallback encoding does not work if message contains charset=""

Updated

a year ago
Component: Untriaged → MIME
Product: Thunderbird → MailNews Core
Version: 47 Branch → Trunk

Comment 4

9 months ago
This bug appears to be a special case of bug 251634 - Illegal charset spec prevents autodetect/fallback to default charset.
You need to log in before you can comment on or make changes to this bug.