Last Comment Bug 3994 - Mail- MIME encode for sending a mail
: Mail- MIME encode for sending a mail
Product: MailNews Core
Classification: Components
Component: Internationalization (show other bugs)
: Trunk
: x86 Windows NT
P3 normal (vote)
: M5
Assigned To: nhottanscp
: Katsuhiko Momoi
Depends on:
  Show dependency treegraph
Reported: 1999-03-18 17:08 PST by nhottanscp
Modified: 2008-07-31 01:22 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image nhottanscp 1999-03-18 17:08:55 PST
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 User image nhottanscp 1999-03-23 14:24:59 PST
Reassigning to Jean-Francois, I have sent him diffs to enable MIME encoding.
Comment 2 User image nhottanscp 1999-03-29 17:42:59 PST
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 User image nhottanscp 1999-03-29 17:44:59 PST
Reassingning to myself.
Comment 4 User image bobj 1999-04-05 17:48:59 PDT
Pending on fix for #4393, utf-8 encoder
Comment 5 User image nhottanscp 1999-04-06 14:51:59 PDT
Fixes checked in (utf-8 and libmime), available in 4/7 build.
Comment 6 User image Katsuhiko Momoi 1999-04-08 21:56:59 PDT
** 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:


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 User image nhottanscp 1999-04-09 12:02:59 PDT
As this is not blocking other testing, I mark this as M5.
Comment 8 User image nhottanscp 1999-04-12 10:29:59 PDT
The truncation bug is caused by the utf-8 encoder (#4968).
Comment 9 User image nhottanscp 1999-04-12 15:44:59 PDT
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 User image nhottanscp 1999-04-12 15:55:59 PDT
Adding marina to cc.
Comment 11 User image nhottanscp 1999-04-19 12:22:59 PDT
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 User image nhottanscp 1999-04-19 16:22:59 PDT
>sending Japanese is still not possible because of #4970.
My mistake, #5289 instead.
Comment 13 User image Katsuhiko Momoi 1999-04-20 19:16:59 PDT
** 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.

Note You need to log in before you can comment on or make changes to this bug.