Closed Bug 252240 Opened 20 years ago Closed 20 years ago

"From:" incomplete and different in listview and "from" field for big5 encoding

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 156588

People

(Reporter: burnus, Assigned: sspitzer)

Details

This is the mozilla-1.8a2-0.1 build of SUSE.

I got an email from

From: "=?big5?B?IkhzdSwgSmVubnkgW659pk6sTF0i?=" <yyy@xxx.tw>

The listview shows this sender:  ""Hsu
While the From box above the displayed body shows: Jenny [zzz]"" <yyy@xxx.tw>
(The zzz are Chinese characters and the "" appear like thus.)

If I hit reply, I'm composing a message
To: ""Hsu
To: Jenny [zzz]"" <yyy@xxx.tw>

Expeced: The name appears in all cases the same and complete,
especially, the reply shall contain only one To: field!
Possible dupe of bug 231732; a comment there refers to bug 122972.  Those bugs 
are about detecting an encoded address string as multiple addresses.

The base-64 encoded name is both enclosed in quotes *and* decodes to a string 
that contains quotes, resulting in:  ""Hsu Jenny [###]""
I'm not sure if the doubled quotes themselves are a problem, but see bug 168204.

See also bug 115240, bug 156588, which are about the problem of a single From 
line containing multiple addresses being displayed inconsistently between the 
thread pane's Sender column and the envelope panel's From: line.
OK, I've done a little more work with this.
First, the decoded address includes a comma, which I neglected to include; so 
with both the encoded and unencoded quote marks, the address parses as
  From:  ""Hsu, Jenny [###]"" <yyy@xxx.tw>

The pairs of quotes essentially do nothing!  Result:
  From:  Hsu, Jenny [###] <yyy@xxx.tw>

Per RFC822, this is a From: line specifying two senders -- commas are the 
delimiter, unless quoted.  Performing the reply, Mozilla puts each sender on a 
separate line.  While not desired, this is correct per spec.  
Bug 122972, bug 249626 and bug 254519 are similar reports that all come down to 
the same issue: the header is misconfigured to include an unquoted comma, and so 
is being treated as multiple addresses.  The header is malformed; this part of 
the bug report is therefore Invalid.

Note per RFC2047, the encoded portion of an address header MUST NOT appear 
within quotes (i.e., the encoding must include the entire quoted portion of the 
string, including the quotes).


Second issue, about the two parts of the From: line appearing differently in the 
message envelope and in the thread pane's Sender column, is bug 156588.  I'll 
dupe this bug to that one, since it's the valid part of the report.


A third issue, not mentioned in the original report: I am currently seeing that 
when I reply to the message containing this From: header, the second line 
appears as:
  Jenny [®}¦N¬L]"" <yyy@xxx.tw>

That is, the Chinese characters are not decoded properly before getting copied 
to the address field.  (I am pretty sure that the first time I attempted to 
debug this problem, I did not see that symptom.  I don't know, yet, what is 
different.)  Bug 231732 is about this symptom.

*** This bug has been marked as a duplicate of 156588 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
I need to revise my comment 2.  Altho the use of quotes is incorrect, the 
embedded comma should not be an issue -- this header should appear as a single 
address.  See the discussion in bug 254519.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.