11892 - [dogfood] When Name or Address of a recipient includes 8-bit characters address is incorrectly formed

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect, P3)

Description

[Katsuhiko Momoi]

** Observed with 8/13/99 Win32 build **

This problem was found while trying to verify Bug 10419.

I sent a message to this type of address:

Måleviçh <[e-mail]>

This never got through SMTP server and got bounced with an error
msg:

-----
Each of the following recipients was rejected by a remote mail server.
The reasons given by the server are included to help you determine why
each recipient was rejected.

    Recipient: <"="@netscape.com>
    Reason:    <"="@netscape.com>... User unknown
-----

Looking at the source of the bounced message, you can see why
this occurred:

--===========================_ _= 801086(24804+6684808)
Content-Type: message/delivery-status
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Reporting-MTA: dns; dredd.mcom.com
Received-From-MTA:dns; iqax2 (208.12.36.168)
Arrival-Date: Fri, 13 Aug 1999 19:17:14 -0700

--===========================_ _= 801086(24804+6684808)
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Return-Path: <iqax2>
Received: from iqax2 ([208.12.36.168]) by dredd.mcom.com
          (Netscape Messaging Server 4.1) with ESMTP id FGFNOQ00.D09 for
          <"=">; Fri, 13 Aug 1999 19:17:14 -0700
Message-ID: <[e-mail]>
Date: Fri, 13 Aug 1999 19:24:13 -0700
From: [e-mail]
Organization: Netscape.com
User-Agent: Mozilla 5.0 [en] (Win32; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "=?iso-8859-1?Q?M=E5levi=E7h?= 1" <[e-mail]>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 2" <[e-mail]>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 3" <[e-mail]>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 4" <[e-mail]>
Subject: =?iso-8859-1?Q?M=E5levi=E7h?=
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
------------------------------------------------------------

Some items of note:

1. We are quoting an encoded-word. This should not be done.
2. But otherwise, the structure seems to be OK.
   It is mysterious that the server could not handle this.

In any case the format "8-bit_name <[e-mail]>" should
not cause any trouble with our servers and it does not
when we use 4.7.

Comment 1

[Katsuhiko Momoi]

It turns out that [e-mail] type of address without the
real name also causes the same problem. Accordingly I modified the
summary slightly. (See Bug 5328)

Comment 2

[Phil Peterson]

B1 stopper. Reassigning to jefft

Comment 3

[marina]

Kat, i guess it's a DUP of bug #10294.

Comment 4

[Katsuhiko Momoi]

No. This is not a duplicate of Bug 10294. We should keep these
two separate.

Comment 5

[Katsuhiko Momoi]

However, we should do regression check next week to see if the
problem is still there.

Comment 6

[Phil Peterson]

Jeff's on vacation; moving his M10 bugs to M11

Comment 7

[leger]

Adding [e-mail] to cc list.

Comment 8

[nhottanscp]

This is now easier to reproduce by using address book.
Create an ab entry name contains 8 bit characters (e.g. á alt+0225) then
"NewMsg" button from address book.

Comment 9

[lchiang]

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

Comment 10

[jefft]

Couple problems found here: 1) name part of an address shouldn't be requoted
which violate the rfc822 spec - msg_parse_Header_addresses(); for example
ÉéÇÅÆÂâ <[e-mail]> shouldn't be requoted with
"ÉéÇÅÆÂâ" <[e-mail]> 2) nsSmtpUrl->m_toPart is wrongly initialized
with base class GetFileName() when the address is an encoded word. For 1) I kind
of have a solution. For 2) I don't at the moment.

Comment 11

[jefft]

Fix checked in. nsMsgHeaderParser.cpp & nsSmtpUrl.cpp modified.

Comment 12

[pmock]

changing QA assigned to [e-mail]

Comment 13

[Katsuhiko Momoi]

** Checked with 11/9/99 Win32 build (1999110911) **

We had 2 problems:

1. Address was mal-formed when the Addressee name contained 8-bit characters.
2. Encoded wordw were quoted.

Both of these problems are now gone with the above build. I tried
the original problem address as well as several other types which
contained 8-bit characters in the names. They all worked OK and
mail was delivered properly.

Marking if verified/fixed.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aa32b8ca0c25
[components] For https://github.com/mozilla-mobile/android-components/issues/11892 - Pass ParsedStructure as bytearray instead of as parcelable
https://hg.mozilla.org/integration/autoland/rev/fabff0a13206
[fenix] For https://github.com/mozilla-mobile/fenix/issues/11892: Remove dynamic calls to setupNavigationToolbar