Closed
Bug 5315
Opened 28 years ago
Closed 10 years ago
MIME-2: don't decode (or encode) in addr-spec part
Categories
(MailNews Core :: Internationalization, defect, P2)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Future
People
(Reporter: jwz, Unassigned)
References
Details
(Keywords: intl)
(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.
Reporter | ||
Comment 1•28 years ago
|
||
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•28 years ago
|
||
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.
Reporter | ||
Comment 3•28 years ago
|
||
> 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•28 years ago
|
||
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 6•26 years ago
|
||
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•26 years ago
|
||
Initially assigned to nhotta.
Updated•26 years ago
|
QA Contact: 1308
Comment 8•26 years ago
|
||
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.
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6
Comment 9•26 years ago
|
||
I think we'll do encoding check only.
Comment 10•26 years ago
|
||
>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•26 years ago
|
||
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.
Updated•26 years ago
|
Assignee: nhotta → phil
Status: ASSIGNED → NEW
Comment 12•26 years ago
|
||
Reassigning to phil@netscape.com
I think the same kind of bug was reassigned to phil. I don't remember the bug
number.
Updated•26 years ago
|
Assignee: phil → rhp
Comment 13•26 years ago
|
||
I think Rich owns this code now. Reassigning to rhp@netscape.com
Updated•26 years ago
|
Status: NEW → ASSIGNED
Updated•26 years ago
|
Target Milestone: M6 → M12
Comment 14•26 years ago
|
||
I have an idea on this one, but with all else that needs done, I am pushing
this one off.
- rhp
Comment 15•25 years ago
|
||
(target milestone is M11 or M12 - add to mail beta tracking bug)
Updated•25 years ago
|
Target Milestone: M12 → M20
Comment 16•25 years ago
|
||
Bugsplat bug #51321...need I say more :-)
- rhp
Updated•25 years ago
|
Target Milestone: M20 → Future
Comment 17•24 years ago
|
||
QA contact to ji if this bug gets worked on in the future.
QA Contact: momoi → ji
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•20 years ago
|
Product: MailNews → Core
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•16 years ago
|
QA Contact: ji → i18n
Updated•12 years ago
|
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Comment 19•10 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•