Last Comment Bug 11892 - [dogfood] When Name or Address of a recipient includes 8-bit characters address is incorrectly formed
: [dogfood] When Name or Address of a recipient includes 8-bit characters addre...
Product: MailNews Core
Classification: Components
Component: MIME (show other bugs)
: Trunk
: x86 Windows NT
P3 major (vote)
: M11
Assigned To: jefft
: Katsuhiko Momoi
Depends on:
Blocks: 11091 12907
  Show dependency treegraph
Reported: 1999-08-13 19:42 PDT by Katsuhiko Momoi
Modified: 2017-02-03 12:24 PST (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Katsuhiko Momoi 1999-08-13 19:42:47 PDT
** 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 <>

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

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: <"=">
    Reason:    <"=">... 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;
Received-From-MTA:dns; iqax2 (
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 ([]) by
          (Netscape Messaging Server 4.1) with ESMTP id FGFNOQ00.D09 for
          <"=">; Fri, 13 Aug 1999 19:17:14 -0700
Message-ID: <>
Date: Fri, 13 Aug 1999 19:24:13 -0700
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" <>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 2" <>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 3" <>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 4" <>
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 <>" should
not cause any trouble with our servers and it does not
when we use 4.7.
Comment 1 User image Katsuhiko Momoi 1999-08-13 20:01:59 PDT
It turns out that type of address without the
real name also causes the same problem. Accordingly I modified the
summary slightly. (See Bug 5328)
Comment 2 User image Phil Peterson 1999-08-19 16:31:59 PDT
B1 stopper. Reassigning to jefft
Comment 3 User image marina 1999-08-19 16:52:59 PDT
Kat, i guess it's a DUP of bug #10294.
Comment 4 User image Katsuhiko Momoi 1999-08-19 18:52:59 PDT
No. This is not a duplicate of Bug 10294. We should keep these
two separate.
Comment 5 User image Katsuhiko Momoi 1999-08-19 18:53:59 PDT
However, we should do regression check next week to see if the
problem is still there.
Comment 6 User image Phil Peterson 1999-08-27 13:12:59 PDT
Jeff's on vacation; moving his M10 bugs to M11
Comment 7 User image leger 1999-08-30 15:25:59 PDT
Adding to cc list.
Comment 8 User image nhottanscp 1999-08-31 17:05:59 PDT
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 User image lchiang 1999-09-20 15:57:59 PDT
(target milestone is M11 or M12 - add to mail beta tracking bug)
Comment 10 User image jefft 1999-10-21 21:41:59 PDT
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
ÉéÇÅÆÂâ <> shouldn't be requoted with
"ÉéÇÅÆÂâ" <> 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 User image jefft 1999-10-22 14:01:59 PDT
Fix checked in. nsMsgHeaderParser.cpp & nsSmtpUrl.cpp modified.
Comment 12 User image pmock 1999-10-22 19:22:59 PDT
changing QA assigned to
Comment 13 User image Katsuhiko Momoi 1999-11-10 00:13:59 PST
** 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.

Note You need to log in before you can comment on or make changes to this bug.