3994 - Mail- MIME encode for sending a mail

Status: VERIFIED FIXED

(MailNews Core :: Internationalization, defect, P3)

Description

[nhottanscp]

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

Comment 1

[nhottanscp]

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

Comment 2

[nhottanscp]

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.

Comment 3

[nhottanscp]

Reassingning to myself.

Comment 4

[bobj]

Pending on fix for #4393, utf-8 encoder

Comment 5

[nhottanscp]

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

Comment 6

[Katsuhiko Momoi]

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

Comment 7

[nhottanscp]

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

Comment 8

[nhottanscp]

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

Comment 9

[nhottanscp]

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.

Comment 10

[nhottanscp]

Adding marina to cc.

Comment 11

[nhottanscp]

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.

Comment 12

[nhottanscp]

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

Comment 13

[Katsuhiko Momoi]

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