214510 - corrupt display of non-ascii in mail header lines

Status: RESOLVED DUPLICATE of bug 90584

(MailNews Core :: Internationalization, defect)

Description

[Peter Kirk]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

When the subject line of a received message contains non-ascii characters, when
that subject line is displayed in the list of messages and in the header of the
individual message, the non-ascii characters and any subsequent characters are
replaced in the display only by black diamonds with white question marks inside.

Possibly the same bug, possibly different (also reported under bug 145293 but
probably doesn't belong there): something similar happened with a from line but
I get a Chinese character.

Reproducible: Always

Steps to Reproduce:
Source line from message 1:
Subject: [SPAM8] FREE ÿFFFFA325 TO SPEND @ ARGOS

Source line from message 2:
Subject: Re: [b-hebrew] “stones”_in_Exodus_1:16

Source line from message 3 (x's replace name):
From: =?8859_1?B?S2FybGr8cmdlbg==?= Xxxxxxxxx <[e-mail]>

Actual Results:  
Display of source line from message 1:
"[SPAM8] FREE " followed by 26 illegal character symbols

Display of source line from message 2:
"Re: [b-hebrew] " followed by 23 illegal character symbols

Display of source line from message 3:
A Chinese character, 翽, which is U+7FFD meaning "sounds of wings flapping",
followed by " Xxxxxxxxx <[e-mail]>"


Expected Results:  
For messages 1 and 2, displayed the subject lines as in the source.

For message 3, I would expect ISO 8859-1 characters, not a Chinese one!

Comment 1

[Matthias Versen [:Matti]]

-> Int

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 4

[Peter Kirk]

This bug is still apparent in Thunderbird 1.0.6 (20050716). At least, the sender
of my message 3 is still incorrectly displayed, but now, rather than the Chinese
character, I see an illegal character symbol (a diamond with a question mark in
it). But I think message 2 is now displayed correctly. And I can no longer find
message 1.

Comment 5

[Jungshik Shin]

This is probably a dupe of bug 90584 (or invalid). Note that raw 8bit bytes are not allowed in the message header.

Comment 6

[Peter Kirk]

This is certainly a similar issue to bug 90584, not sure if it is quite a duplicate.

The remaining issue seems to be with the message with the line "From: =?8859_1?B?S2FybGr8cmdlbg==?= Xxxxxxxxx <[e-mail]>" Is this correct syntax to indicate that this should be ISO 8859-1 encoding? If so, why is this not taken as ISO 8859-1? If not, surely it should be taken as a literal string and displayed as shown rather than as an illegal character.

Comment 7

[Mike Cowperthwaite]

(In reply to comment #6)
> The remaining issue seems to be with the message with the line 
> "From: =?8859_1?B?S2FybGr8cmdlbg==?= Xxxxxxxxx <[e-mail]>" 

> Is this correct syntax to indicate that this should be ISO 8859-1 encoding?
> If so, why is this not taken as ISO 8859-1?
 
This is not correct syntax -- it ought to read
  =?iso-8859-1?B?S2FybGr8cmdlbg==?=
    ~~~~~~~~~~

With this change, the encoded part displays as "Karljürgen".

> If not, surely it should be taken as a literal string and displayed as shown
> rather than as an illegal character.

I don't think the literal encoding string is any more useful than the illegal character; in fact, I think it'd be more confusing to most users.  And it takes almost 30 characters to indicate the same thing the single illegal-char symbol does: "This message was created by broken software."

But if you're inundated by broken messages like this and think it needs to be addressed, please go ahead an open an RFE for it.

*** This bug has been marked as a duplicate of 90584 ***