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.