Closed Bug 249626 Opened 20 years ago Closed 20 years ago

RFC 2047 encoded To personal name with commas incorrectly interpreted

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 254519

People

(Reporter: mallen, Assigned: mscott)

Details

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322) Build Identifier: I have an RFC 2047 encoded personal name in the To: line of an email. The personal name, when decoded, contains commas. The commas are incorrectly interpreted as mail address separaters, and thus the To: line in the message pane has three clickable links for the three different, comma delimited sections. Here is the To: line: To: =?UTF-8?B?TWljaGFlbCBBbGxlbiwgXCJTZW1pIEdlbml1c1wiLCDvvo/vva/vvoc=?= <mike@pgpqafullsail.com> Reproducible: Always Steps to Reproduce: 1. Send a mail with the above To: line to a user with Thunderbird as their mailer. 2. Use Thunderbird to retrieve this email. 3. Note that the To: line displayed in the message pane has three links Actual Results: The To: line in the message pane has three links, not one. Expected Results: One link should be on the To: line Here is the whole text of the offending email Return-Path: <mike@pgpqatest.com> Received: from fullsail.pgp.com ([unix socket]) by fullsail.pgp.com (Cyrus v2.2.3-Red Hat 2.2.3-11) with LMTP; Fri, 02 Jul 2004 17:55:44 -0700 X-Sieve: CMU Sieve 2.2 Received: from mallenlaptop.pgp.com ([63.251.255.246]) by fullsail.pgp.com (8.12.11/8.12.11) with ESMTP id i630tiqf016181 for <mike@pgpqafullsail.com>; Fri, 2 Jul 2004 17:55:44 -0700 Received: from mallenlaptop.pgp.com (localhost [127.0.0.1]) by mallenlaptop.pgp.com (Postfix) with ESMTP id C151A452A for <mike@pgpqafullsail.com>; Fri, 2 Jul 2004 10:58:33 -0700 (PDT) Received: from mallenlaptop.pgp.com by mallenlaptop.pgp.com (PGP Universal service); Fri, 02 Jul 2004 10:58:33 -0700 X-PGP-Universal: processed Message-ID: <17823274.1088791113395.JavaMail.tomcat4@localhost> Date: Fri, 2 Jul 2004 10:58:33 -0700 (PDT) From: "Mike Allen, PGPQATest" <mike@pgpqatest.com> To: =?UTF-8?B?TWljaGFlbCBBbGxlbiwgXCJTZW1pIEdlbml1c1wiLCDvvo/vva/vvoc=?= <mike@pgpqafullsail.com> Subject: Re: Testing this out Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =2A=20PGP=20Decrypted=20Message On=20Thursday=20July=2001,=202004=20at=202:19=20PM,=20=22Michael=20Allen,= =20\=22Semi=20Genius\=22,=20=EF=BE=8F=EF=BD=AF=EF=BE=87=22 =20=3Cmike=40pgpqafullsail.com=3E=20wrote: Trying=20new=20regexp =3E=20Try=20this =3E
What program created that mail? I think the name is correctly decoded (aside from the missing "" arount Semi Genius). Without "" around the whole name it's normal to get this. I also tested KMail and got the same result. Additionally, the <mike@pgpqafullsail.com> in the line after the To: should start with a space or tab.
This mail was created from a custom JavaMail client.
Any mail client you know of that decodes/displays the To like you expect it?
Unfortunately, no. I would expect that the To: line would come out with one clickable address that contained "Michael Allen, \"Semi Genius\", <three Japanese characters>" as the single display name. Thunderbird can be the first to do this right! :-)
Well, how should the Client (e.g. TB) know that it's one name? Embracing such names with "" don't exist without reason. Why not teach the sending client to encode the field with the double quote? Not to speak from the missing whitespace before the email address (if it's no mistake created by submitting the header to bugzilla).
Christian is correct. The header provided defines multiple addresses, per RFC822. It is necessary to quote the name string in its entirety if commas are desired. Note that if the name string is going to be encoded (as this one is), the quotes must be included in the encoded portion (per RFC2047, section 5 item 3).
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Well, I was mistaken. The arguments for parsing per the desired behavior are well set out in the duplicate. My apologies. *** This bug has been marked as a duplicate of 254519 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.