Closed Bug 117975 Opened 23 years ago Closed 22 years ago

Mishandling escaped characters in display-name token

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 134277

People

(Reporter: irabinovitch, Assigned: sspitzer)

Details

BuildID:    20011221

An rfc2822-compliant address often contains a display-name token. The RFC 
specifies that this should be either a single word or a quoted-string, though 
most mailers (including Mozilla) also accept a multi-word string, provided 
there are no metacharacters. If display-name contains  metacharacters (quote or 
backslash) than the whole thing must be a quoted-string, with the 
metacharacters each escaped with a backslash. 

Mozilla follows this last rule when it creates a FROM header. For example if 
your identity has the following fields:

Mail address: bill@tombstone.com
Your name: William "Wild Bill" Hickcock

Then your messages go out with this header:

From: "William \"Wild Bill\" Hickcock" <bill@tombstone.com>

But if your recipient is also using Mozilla, address is displayed *exactly* as 
it appears in the header. This looks uncool, and is seriously non-compliant 
with the RFC, which states that the backslash is "semantically invisible".

Just as Mozilla adds the backslashes when it creates the header, it should 
remove them when it interpretes it.

D

Reproducible: Always
Steps to Reproduce:
1. Set your identity as described above.
2. Send yourself an email.
3. View the message and click on the return address.
4. Choose "add to address book"

Actual Results:  Sender display name is ugly. And backslashes get added to the 
address book name.

Expected Results:  Sender display and address book entry should both match the 
original Identity Your Name field.
I can confirm the behaviour here, and can't find a dupe.

related: bug 134277 (FIXED)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Bug 134277 describes this same problem in a different context. If it's not a
dup, it's close enough. In any case, the build I'm running (20020721) does not
have the bug as I reported it. In short, it's now fixed -- thanks!

*** This bug has been marked as a duplicate of 134277 ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.