368809 - Prefer Content-Type: from email header over the default encoding of a message folder

Status: RESOLVED INVALID

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Martin Mokrejs]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 SeaMonkey/1.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 SeaMonkey/1.1

I think it is reasonable to override the default, folder-specific encoding with a value specified in an email header. In the following tescase, I want to see the name in From: line decoded as "Jiří Dohnal" which is seemingly in iso-8859-2.
Unfortunately, the default encoding for the message folder is UTF8 in my case
so the display is screwed.

Note: I do understand Subject:, From: and other lines could have a completely
different encoding, actually every character could be in yet anothe rencoding, but that is not an issue here.

I do propose you to trust the user and hope, that the encoding specified in an email header is the one used for all lines in the header.



Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Martin Mokrejs]

Attachment: testcase.eml.gz

BTW, maybe some inspiration for mozilla could be in this perl script which seems to work quite well for me several years (not my work): http://ribosome.natur.cuni.cz/~mmokrejs/procmail/mobiles/dmmh

Comment 2

[Tony Mechelynck [:tonymec]]

In header lines, the standard mandates that only 7-bit US-ASCII can be used in the actual source text. Anything else must be MIME-encoded. For example,

Subject: Réunion de vacances du 18 août

must appear in the message source as (for instance, using ISO-8859-1):

Subject: =?iso-8859-1?Q?R=E9union_de_vacances_du_18_ao=FBt?=

Any byte greater than 0x7F in the headers' source is an error, and IIUC there's no way to predict how it shall be represented, especially since "Content-Type" is usually one of the last lines in the header block.

Resolving INVALID.

Comment 3

[Martin Mokrejs]

Couldn't thunderbird do some effort to render the message AFTER parsing the

Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

lines from email header and try to apply the encoding over the plain body of the message?

Well, truly said, current cvs HEAD build does some magic then, because it just works in this case (From: line decoded as "Jiří Dohnal", the message body is fine as well) regardless the fact what default encoding I enforce over the folder containing this testcase. I selected different folder back and forth to be sure it has re-rendered the messages (at least I hope it did that). However, this testcase triggers the bug #415250 observed so far in browser only, a stacktrace is in #415250 comment #6.