** 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 <email@example.com> 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 (188.8.131.52) 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 ([184.108.40.206]) 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: <37B4D34D.firstname.lastname@example.org> Date: Fri, 13 Aug 1999 19:24:13 -0700 From: email@example.com 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" <firstname.lastname@example.org>," =?iso-8859-1?Q?M=E5levi=E7h?= 2" <email@example.com>," =?iso-8859-1?Q?M=E5levi=E7h?= 3" <firstname.lastname@example.org>," =?iso-8859-1?Q?M=E5levi=E7h?= 4" <email@example.com> 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 <firstname.lastname@example.org>" should not cause any trouble with our servers and it does not when we use 4.7.
It turns out that email@example.com type of address without the real name also causes the same problem. Accordingly I modified the summary slightly. (See Bug 5328)
B1 stopper. Reassigning to jefft
Kat, i guess it's a DUP of bug #10294.
No. This is not a duplicate of Bug 10294. We should keep these two separate.
However, we should do regression check next week to see if the problem is still there.
Jeff's on vacation; moving his M10 bugs to M11
Adding firstname.lastname@example.org to cc list.
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.
(target milestone is M11 or M12 - add to mail beta tracking bug)
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 ÉéÇÅÆÂâ <email@example.com> shouldn't be requoted with "ÉéÇÅÆÂâ" <firstname.lastname@example.org> 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.
Fix checked in. nsMsgHeaderParser.cpp & nsSmtpUrl.cpp modified.
changing QA assigned to email@example.com
** 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.