249626 - RFC 2047 encoded To personal name with commas incorrectly interpreted

Status: RESOLVED DUPLICATE of bug 254519

(Thunderbird :: Mail Window Front End, defect)

Description

[Michael Allen]

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=?= 
<[e-mail]>



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: <[e-mail]>
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 <[e-mail]>; 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 <[e-mail]>; 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" <[e-mail]>
To: =?UTF-8?B?TWljaGFlbCBBbGxlbiwgXCJTZW1pIEdlbml1c1wiLCDvvo/vva/vvoc=?= 
<[e-mail]>
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

Comment 1

[Christian Eyrich]

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 <[e-mail]> in the line after the To: should
start with a space or tab.

Comment 2

[Michael Allen]

This mail was created from a custom JavaMail client.

Comment 3

[Christian Eyrich]

Any mail client you know of that decodes/displays the To like you expect it?

Comment 4

[Michael Allen]

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!  :-)

Comment 5

[Christian Eyrich]

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).

Comment 6

[Mike Cowperthwaite]

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).

Comment 7

[Mike Cowperthwaite]

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 ***