Mail- MIME encode for sending a mail

VERIFIED FIXED in M5

Status

MailNews Core
Internationalization
P3
normal
VERIFIED FIXED
19 years ago
9 years ago

People

(Reporter: nhottanscp, Assigned: nhottanscp)

Tracking

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

19 years ago
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).
(Assignee)

Updated

19 years ago
Target Milestone: M4
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Summary: MIME encode for sending a mail → Mail- MIME encode for sending a mail
(Assignee)

Updated

19 years ago
Assignee: nhotta → ducarroz
Status: ASSIGNED → NEW
(Assignee)

Comment 1

19 years ago
Reassigning to Jean-Francois, I have sent him diffs to enable MIME encoding.
(Assignee)

Comment 2

19 years ago
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.
(Assignee)

Updated

19 years ago
Assignee: ducarroz → nhotta
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

19 years ago
Reassingning to myself.

Comment 4

19 years ago
Pending on fix for #4393, utf-8 encoder
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 5

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

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 6

19 years ago
** 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.
(Assignee)

Updated

19 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 7

19 years ago
As this is not blocking other testing, I mark this as M5.
(Assignee)

Comment 8

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

Comment 9

19 years ago
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.
(Assignee)

Comment 10

19 years ago
Adding marina to cc.
(Assignee)

Updated

18 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago18 years ago
(Assignee)

Comment 11

18 years ago
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.
(Assignee)

Comment 12

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

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 13

18 years ago
** 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.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.