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)
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!
Comment 1•20 years ago
|
||
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.
Comment 2•20 years ago
|
||
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
Comment 3•20 years ago
|
||
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.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•