Closed Bug 10419 Opened 21 years ago Closed 21 years ago

Messenger should not use us-ascii as a default encoding for sending out mail

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: marina, Assigned: nhottanscp)

Details

Steps to reproduce:
-bring up a new mail composition window;
-click Address icon;
-select a card with high ascii in the Display Name (Márína
Måleviçh<marina@netscape.com>);
- type something in the subject and body field;
-send out and get it:
//note: non-ascii are displayed OK in the thread pane but are garbled in the
message header.
In case you don't specifically choose ISO-8859-1 even though you don't need it
for Subject and body encoding it will default to us-ascii
(How we will handle multiple encodings: in case adressee name and message body
will require different encodings?)
Status: NEW → ASSIGNED
Target Milestone: M10
Marina, could you try this with "intl.character_set_name" set to ISO-8859-1?
Currently, we use us-ascci if no pref is specified. I think we need to change
this to ISO-8859-1.
It does make a difference, i believe it just should be a defaultas it was in 4.x
I will use ISO-8859-1 instead of us-ascii in case "intl.character_set_name" is
not specified.
> (How we will handle multiple encodings: in case adressee name and message body
> will require different encodings?)
4.5 does not support this and we do not plan to support this in 5.0. Charset of
the menu selection to be applied for all addressees.
I have some questions about this bug.

1. Will there be a case where we don't have a charset menu item
   not initialized to some charset in Mail Compose window? I thought
   it was just because of a bug we don't have a charset menu
   selection showing when a new compose window is opened.
   We should always have a default charset specified somewhere.
   Amd the default charset should not be something which
   is not included in the Charset menu. This excludes US-ASCII
   from consideration. So,it seems to me that once you
   associate a compose charset to what is availavle in the
   Compose window charset menu, this kind of problem should not
   happen.

   So does your change simply supply the default charset to be
   ISO-8859-1 when the default charset line does not exist?
   Is that what this bug is about?


2. If you see the problem message header with 4.7, you can actually
   display it correctly:

   =?us-ascii?Q?R=E9gions?=

   In 5.0, can we deal with kind of header in such a way as to
   map non-ASCII characters to ISO-8859-1 in this kind of case?

   Also,I think we agreed to allow an override of header
   display by a prefs50.js setting.
The first question, the only problem is a menu check mark, we always have
charset set by the pref or the default (hard coded).
The second quesion is a viewing and a separate issue from this compose bug. But
I think the MIME decoder can decode it.
With regard to the 2nd question, as I remember the original example
for this bug, the thread pane header display of US-ASCII encoded
MIME header does not display correctly under 5.0. And the body will not
display correctly, either, since it would have a content-type header
US-ASCII and QP encoding rather than HTML entities.

I think I'll file another bug on this. Since 5.0 generated messages
will not bear this kind of structure once ths bug is fixed.
There might be other mailers which would do this, however.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
The fix was checked in yesterday (8/9) for #11496.
** Checked with 8/13/99 Win32 build **

This fix is hard to verify at this point because of another bug.
When 8-bit characters are included in the address-to field,
we seem to be using an incorrect header fro addressing.

See this error msg I received from the SMTP server when I entered
the following into the Subject field:

Måleviçh <momoi@netscape.com>)

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


I received an eeror message from the server and it quotes
the original message. Here's what that the headers look like:

---------
--===========================_ _= 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: <37B4D34D.7000502@nsmail-2.mcom.com>
Date: Fri, 13 Aug 1999 19:24:13 -0700
From: iqax2@nsmail-2.mcom.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" <momoi8@kaze.mcom.com>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 2" <momoi@netscape.com>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 3" <momoi8@polyglot.mcom.com>,"
        =?iso-8859-1?Q?M=E5levi=E7h?= 4" <iqax2@netscape.com>
Subject: =?iso-8859-1?Q?M=E5levi=E7h?=
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

-----------------------------------

You can see that the charset used is as intended by nhotta's
fix. Based on this, I'm inclined to mark this fix verified,
but I'll wait until the other bug is fixed and mail can
pass through an SMTP server.
QA Contact: momoi → marina
This should have been verified a long time ago.
As of M14 today, the default charset is ISO-8859-1, L10n
should be able to change this for different locales.
In the meantime, there is now a send default charset setting
menu at the bottom of Mail Composer charset menu. Users can use
that to set the default choice.
For vacatoning Marina, marking it verified as fixed. 
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.