5315 - MIME-2: don't decode (or encode) in addr-spec part

Status: RESOLVED WORKSFORME

(MailNews Core :: Internationalization, defect, P2)

Description

[Jamie Zawinski]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #51321
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=51321
Imported into Bugzilla on 04/20/99 13:01)

(Not sure exactly who to report this to.)

Keith Moore <[e-mail]> wrote:
>
>  From: =?iso-8859-1?B?WU9VUi5NQUlMRVIuSVMuQlJPS0VO?=@cs.utk.edu
>
> If the From: field as displayed contains the address
>
>        [e-mail]
>
> then your mail reader is improperly treating addresses that contain
> =? ... ?= as if they were encoded-words.

Apparently the rule is that 1522-encoding is only to be decoded in
the "phrase" and "comment" segments of the "mailbox" rule.  It is
not to be decoded in the "addr" or "addr-spec" portions.

Comment 1

[Jamie Zawinski]

Also, we shouldn't do this at encode-time either -- if a user-ID contains
characters which can't be represented in ASCII, then that's an illegal
address.  However, there is no mechanism to encode it, so I guess the
only reasonable thing is to send it out raw.

See also related bug 51325.

Comment 2

[Frank Tang]

For decoding- I agree we should not decode it, but, even we decode it, so
what ? If the address is already broken, we cannot make it worst!!!

For Encoding, we should not check it in the encoding time. We should check when
the user type the address. Once it get typed, it is too late.

Comment 3

[Jamie Zawinski]

> For decoding- I agree we should not decode it, but, even we decode it, so
> what ? If the address is already broken, we cannot make it worst!!!

The address is not broken.  Silly maybe, but not illegal.
According to the RFCs,

  From: =?iso-8859-1?B?WU9VUi5NQUlMRVIuSVMuQlJPS0VO?=@cs.utk.edu

indicates a user at host "cs.utk.edu" whose user-id is (literally)
"=?iso-8859-1?B?WU9VUi5NQUlMRVIuSVMuQlJPS0VO?=".

This is a rather unlikely user-id, but it is nevertheless a legal one.

Comment 4

[Katsuhiko Momoi]

Per 6/30 I18n Latered Bug Meeting, this bug is moved to 6.0 for review.
It will be reviewed as part of the overall RFC spec Review.
A new RFC Review (75280) was created.
 *** This bug has been marked as a duplicate of 75280 ***

Comment 5

[jeffu]

Duplicate bug, bulk Verified

Comment 6

[Katsuhiko Momoi]

We are clearly in violation of Section 5-(3) of RFC 2047
when we use encoded words in add-spec.

I checked Communicator 4,51 and we turn the following input into
the "To:" filed:

To: "MOMO"@polyglot.mcom.com (where MOMO is a Japanesestring)

into:

To: =?iso-2022-jp?B?GyRCJGIkYhsoQkBwb2x5Z2xvdC5tY29tLmNvbQ==?=

In 5.0 we should not violate RFC 2047's prohibition against "encoded-
word" in the addr-spec.

Re-opening it and moving it to 5.0.

Comment 7

[Katsuhiko Momoi]

Initially assigned to nhotta.

Comment 8

[Katsuhiko Momoi]

There are 2 things we should do with regard to this bug:

1.If a user inputs incorrect addr-spec header, we should not encode
  it at all, or prevent users from completing such input.
2. If we receive such an incorrectly formed-header, instead of
   decoding it, we should display it as if it were a string
   of ASCII characters.

These 2 should put us in compliance with the relevant section of
RFC 2047.

Comment 9

[nhottanscp]

I think we'll do encoding check only.

Comment 10

[nhottanscp]

>1.If a user inputs incorrect addr-spec header, we should not encode

>  it at all, or prevent users from completing such input.

Regarding prevent input, does this mean validation on input? May be this should

be a part of name completion feature.

Regarding should not encode, does this mean we send the wrong address as is or

remove from the sending list?

Comment 11

[Katsuhiko Momoi]

When I wrote "should not encode at all...", I was echoing what JWZ said on 3/19/97.
Basically, his opinion was that since we can't encode it, we should send it out in
raw 8-bit. This, however, conflicts with the requirement of RFC 822 which lists such
characters as illegal in addr-spec.  I vote for not doing this.

I woud rather warn the user that there are illegal characters in addr-spec and should be
corrected and refuse to send out the message until it is corrected even if the message contains
other legal addresses.  This could be part of name completion check -- or more appropriately
validation check.

Comment 12

[nhottanscp]

Reassigning to [e-mail]
I think the same kind of bug was reassigned to phil. I don't remember the bug
number.

Comment 13

[Phil Peterson]

I think Rich owns this code now. Reassigning to [e-mail]

Comment 14

[rhp (gone)]

I have an idea on this one, but with all else that needs done, I am pushing
this one off.

- rhp

Comment 15

[lchiang]

(target milestone is M11 or M12 - add to mail beta tracking bug)

Comment 16

[rhp (gone)]

Bugsplat bug #51321...need I say more :-)

- rhp

Comment 17

[Katsuhiko Momoi]

QA contact to ji if this bug gets worked on in the future.

Comment 18

[scottputterman]

reassigning to ducarroz

Comment 19

[Joshua Cranmer [:jcranmer]]

The jsmime-based RFC 2047 engine does not attempt to encode the localparts or domains of email addresses. While we're still not fully EAI-compliant, this bug is effectively fixed.