(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 <moore@cs.utk.edu> wrote: > > From: =?iso-8859-1?B?WU9VUi5NQUlMRVIuSVMuQlJPS0VO?=@cs.utk.edu > > If the From: field as displayed contains the address > > YOUR.MAILER.IS.BROKEN@cs.utk.edu > > 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.

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.

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.

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

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

Duplicate bug, bulk Verified

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.

Initially assigned to nhotta.

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.

I think we'll do encoding check only.

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

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.

Reassigning to phil@netscape.com I think the same kind of bug was reassigned to phil. I don't remember the bug number.

I think Rich owns this code now. Reassigning to rhp@netscape.com

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

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

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

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

reassigning to ducarroz

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.