The following issue has been ASSIGNED.
======================================================================
http://www.dbmail.org/mantis/view.php?id=345
======================================================================
Reported By: kaname
Assigned To:
======================================================================
Project: DBMail
Issue ID: 345
Category: IMAP daemon
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
======================================================================
Date Submitted: 10-May-06 09:55 CEST
Last Modified: 10-May-06 20:23 CEST
======================================================================
Summary: The attached file name of the multipart mail becomes
UTF-8 from the base64 encoding.
Description:
I'm sorry in poor English.
It requests it as follows by the IMAP protocol.
A001 UID FETCH 12345 (FLAGS BODYSTRUCTURE)
Then, _structure_part_multipart() of dm_imaputil.c passes.
The imap_append_hash_as_string() is called, and refer to the value
of type->param_hash in that.
The value of this hash table is not value of former mail,
and might been converted into UTF-8.
It is done in the gmime library, and filename happens when
it is encoding in base64.
It is in decode_param() of gmime-param.c.
In DBMail, the return value of gmime is returned
as a return value of the IMAP protocol.
The part of filename of multipart mail has replaced UTF-8.
The mailer that cannot understand UTF-8 to filename is garbled.
To begin with, is it correct to return filename UTF-8?
I do not understand how to evade this phenomenon with DBMail.
Please give a good hint.
======================================================================
----------------------------------------------------------------------
paul - 10-May-06 14:54
----------------------------------------------------------------------
These strings should be utf7 encoded. Will fix.
----------------------------------------------------------------------
kaname - 10-May-06 16:46
----------------------------------------------------------------------
I think that it doesn't convert into utf7 but
I should return an original string.
(In this case, it is string of the filename parameter of Content-Type
of the multipart mail)
Actually, Japanese is used for the file name in Japan.
The encoding of the filename is MIME encoding of iso-2022.
If it is MIME encoding, most mail clients can correctly display Japanese.
However, a part of mail client cannot correctly display Japanese
with UTF-8 and UTF-7. (For instance, squirrelmail etc)
There is no necessity for converting code of filename,
and I think that you should return an original string.
----------------------------------------------------------------------
paul - 10-May-06 20:22
----------------------------------------------------------------------
Returning the original string as-is is not an option. Gmime converts all
strings to utf8 internally, but *does* provide a simple interface for
converting them back to the correct encoding:
g_mime_utils_header_encode_text
Could you please test rev 2114?
Issue History
Date Modified Username Field Change
======================================================================
10-May-06 09:55 kaname New Issue
10-May-06 14:54 paul Note Added: 0001160
10-May-06 16:45 kaname Note Added: 0001161
10-May-06 16:46 kaname Note Edited: 0001161
10-May-06 20:22 paul Note Added: 0001162
10-May-06 20:23 paul Status new => assigned
10-May-06 20:23 paul Projection none => tweak
10-May-06 20:23 paul ETA none => < 1 day
======================================================================
