The following issue has been RESOLVED. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=777 
====================================================================== 
Reported By:                idk
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   777
Category:                   IMAP daemon
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     resolved
target:                      
Resolution:                 fixed
Fixed in Version:           3.0.0-final
====================================================================== 
Date Submitted:             06-Mar-09 02:14 CET
Last Modified:              20-Feb-12 10:39 CET
====================================================================== 
Summary:                    wrong mime conversion in  BODY[HEADER.FIELDS]
Description: 
I used a 2.2.7-RC4 for a long time. Recently I have update from the Fedora
repository to 2.2.9 first, then 2.2.11. Now I have tried latest 2.2 branch
(because stable source for 2.2.11 has a compile bug - crypt). All three
versions has the same bug.

All messages arrived before the update have a format [u...@example.com] or
[Real Name <u...@example.com>] in a fromfield, but after the update, the
second format is ["Real Name" <u...@example.com>] (a real name is quoted),
which can be okay.

If the Real Name contains non-ascii characters, response to IMAP FETCH
(BODY[HEADER.FIELDS (From)]) is like this:

* 18 FETCH (UID 1445906 BODY[HEADER.FIELDS (from)] {58}
from: "Accent =?iso-8859-1?b?QeEi?= <m...@example.com>

 )

(the Real Name was [Accent Aa], where last character is "a" with an
accent). The second quotation mark is encoded into mime string (you can
decode it into [Aa"]).

For example Squirrelmail shows ["Accent =?iso-8859-1?b?QeEi?=
<m...@example.com>] in the from field in a messages list

====================================================================== 

---------------------------------------------------------------------- 
 (0002806) idk (reporter) - 06-Mar-09 05:55
 http://www.dbmail.org/mantis/view.php?id=777#c2806 
---------------------------------------------------------------------- 
I made an investigation. In a file dbmail-imapsession in a function
_fetch_headers at line 1263 db_get_result(i,2) returns a correct value (in
a native utf-8 coding), but call into a function dbmail_iconv_db_to_utf7
breaks it. This function is trivial and it forward call only into a mime
function g_mime_utils_header_encode_text.

* I (and all Fedora users) may have wrong mime lib
* this mime function isn't perfect for email addresse's headers
* removing quota marks from the db cache dbmail_headervalue (e.g. there is
no quotas in dbmail_fromfield values) can solve the issue 

---------------------------------------------------------------------- 
 (0002828) idk (reporter) - 01-Jul-09 16:05
 http://www.dbmail.org/mantis/view.php?id=777#c2828 
---------------------------------------------------------------------- 
bump...

There is possible nobody has the same problem such as one I've described? 

---------------------------------------------------------------------- 
 (0002829) maenaka (reporter) - 07-Jul-09 09:39
 http://www.dbmail.org/mantis/view.php?id=777#c2829 
---------------------------------------------------------------------- 
Hi idk. I had digged into these issues months ago.

The former issue is caused by dbmail:misc.c:imap_cleanup_address(). In the
middle of the function, it explicitly quotes a MIME encoded string
regardless of how a string is originally written.

The latter issue is caused by
gmime:gmime/gmime-message.c:write_addrspec(). At some point of its
development (maybe gmime-2.2.1x), the function was changed to call a series
of internet_address_*() functions.

IIRC, internet_address_parse_string() converts a MIME encoded string to
UTF-8 and internet_address_list_writer() re-converts UTF-8 to MIME encoded
string. The former conversion loses the charset information and the latter
tries to guess based on a string given but likely to fail.

The attached patch is for gmime-2.2.23 which partially reverts the changes
of the function may help. 

---------------------------------------------------------------------- 
 (0003405) idk (reporter) - 18-Feb-12 23:16
 http://www.dbmail.org/mantis/view.php?id=777#c3405 
---------------------------------------------------------------------- 
Now I'm using 3.0.0 and such problem isn't there anymore. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
06-Mar-09 02:14  idk            New Issue                                    
06-Mar-09 05:55  idk            Note Added: 0002806                          
01-Jul-09 16:05  idk            Note Added: 0002828                          
07-Jul-09 09:39  maenaka        File Added: patch-gmime_gmime-message.c         
          
07-Jul-09 09:39  maenaka        Note Added: 0002829                          
18-Feb-12 23:16  idk            Note Added: 0003405                          
20-Feb-12 10:39  paul           Status                   new => resolved     
20-Feb-12 10:39  paul           Resolution               open => fixed       
20-Feb-12 10:39  paul           Fixed in Version          => 3.0.0-final     
======================================================================

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev

Reply via email to