In M3, you can type 8 bit characters (e.g. French accents) in the subject field but it is sent out as 8 bit. We need to apply MIME encoding. In order to do the MIME encoding, we need a charset. There are two bugs files related to this (3965 and 3941). New mail should get a charset from the pref (3965) then map it to a mail charset (3941).

Reassigning to Jean-Francois, I have sent him diffs to enable MIME encoding.

I checked in the code to migrate CSID to charset name, also hooked up the unicode converter. There is one place that I need to change to make it work and I will do that when utf-8 encoder is checked in.

Reassingning to myself.

Pending on fix for #4393, utf-8 encoder

Fixes checked in (utf-8 and libmime), available in 4/7 build.

** Checked with 1999-0408-18 Win32 build ** I'm not able to compose and send body text which will reveal the MIME-encoding status of the 8-bit text in body, but the Subject header for ISO-8859-1 mail is sent using the correct charset name and in MIME encoded format. There are some problems, however. 1. Most headers I tried were truncated. For example, Online-Grüßen und digitalen Fotos This was sent as: =?iso-8859-1?Q?Online=2DGr=FC=DF?= (Online-Grüß) I tried this string and its multiples (repeated once, twice, and three times, etc.), and the results showed that line folding is taking place but the last line is always truncated. For example, ----------------------------------------------------------------------- Subject: =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen F ----------------------------------------------------------------------- ----------------------------------------------------------------------- Subject: =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen ----------------------------------------------------------------------- ----------------------------------------------------------------------- Subject: =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digitalen Fotos =?iso-8859-1?Q?Online=2DGr=FC=DFen?= und digital ----------------------------------------------------------------------- MIME encoder is working but with some problems. I'm going to re-open this bug, but we could separate this bug if we can assume that truncation problem is not part of the MIME encoder.

As this is not blocking other testing, I mark this as M5.

The truncation bug is caused by the utf-8 encoder (#4968).

I checked in files for iso-2022-jp support on 4/9. Although I tested with a hard coded data, the verification in Seamonkey is not possible because of the lack of iso-2022-jp encoder (#4970). As my last change affects iso-8859-1, please regress with Latin1 data using 4/12 build or later. This is the last expected major change in the MIME encoder.

Adding marina to cc.

Checked in a fix for the trucation problem (mozilla/mailnews/compose/src/msgCompGlue.cpp rev=1.25). Note that my fix is a generic error handling in the client. The utf-8 encoder bug (#4968) should still need to be fixed. Also, sending Japanese is still not possible because of #4970. Change status to 'FIXED', Japanese issue may be filed separately.

>sending Japanese is still not possible because of #4970. My mistake, #5289 instead.

** Checked with 4/20/99 Win32 build ** The truncation problem is now gone and I'm able to see the entire MIME-encoded string sent from 5.0 to 4.51 Mail client. As far as 8859-1 MIME headers are concerned, I can tell that proper MIME-encoding is occurring. I'll file iso-2022-jp MIME-encoding as a separate bug -- dependency on the iso-2022-jp converter checkin. Marking the fix verified.