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)
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
Comment 1•20 years ago
|
||
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.
Reporter | ||
Comment 2•20 years ago
|
||
This mail was created from a custom JavaMail client.
Comment 3•20 years ago
|
||
Any mail client you know of that decodes/displays the To like you expect it?
Reporter | ||
Comment 4•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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
Updated•20 years ago
|
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 7•20 years ago
|
||
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 ago → 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•