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
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<email@example.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?)
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 <firstname.lastname@example.org>) ----- 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 ([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.email@example.com> Date: Fri, 13 Aug 1999 19:24:13 -0700 From: firstname.lastname@example.org 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" <email@example.com>," =?iso-8859-1?Q?M=E5levi=E7h?= 2" <firstname.lastname@example.org>," =?iso-8859-1?Q?M=E5levi=E7h?= 3" <email@example.com>," =?iso-8859-1?Q?M=E5levi=E7h?= 4" <firstname.lastname@example.org> 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.
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
You need to log in before you can comment on or make changes to this bug.