GNOME Bugzilla – Bug 600386
Do not use charset on messages with UNICODE body fetched
Last modified: 2010-09-01 06:18:43 UTC
Email from one of my colleagues comes through with a lot of his paragraphs looking like this in evolution --------------------- Hei [?] [?] [?] [?] [?] [?] [?] [?] [?] [?] mvh [?] ------------------- Some paragraphs here and there are readable. So far I have only seen this with this one sender, but in several messages from him. He sends from outlook using the same exchange server that I am connected to. Please tell me what kind of info I can provide to help debugging the issue. :-)
After killing all evolution-related processes and starting evolution again, formatting the first message takes a looong time, as if something times out and dies. After that response is quick, but messages from this one sender are as above. I just switched to contacs, then to calendar, and back to email, and again formatting the current message took a loooong time. Are these two related? Or two separate bugs?
Could you please attach a sample mail after removing confidential information. If you cann't provide sample mail, we would need gdb traces when application hangs. see http://live.gnome.org/GettingTraces/Details#gdb-not-yet-running for details about how to do this)
Created attachment 146821 [details] Email saved from Evolution Would it be helpful to save the same message from Outlook, or obtain it using some other means?
(In reply to comment #3) > Created an attachment (id=146821) [details] > Email saved from Evolution > > Would it be helpful to save the same message from Outlook, That would be very helpful.
Created attachment 149824 [details] New message saved from evolution in mailbox format New message saved from evolution in mailbox format
Created attachment 149825 [details] New message as seen in evolution
Created attachment 149826 [details] New message saved from outlook in mht format
I get this problem in all paragraphs containing non-ascii characters when the message is sent from outlook. It does not happen if I send from the web interface of the same exchange server.
I have seen that together with message about can'n decode CP20866 encoding. like: Could not open converter for 'CP20866' to 'UTF-8' charset And yes, messages have CP20866 encoding but iconv have no idea what is cp20866 (actually there is old commented code that notice cp20866 as alias for koi8-r encoding) $ iconv -f cp20866 -t koi8-r < /etc/hosts iconv: conversion from cp20866 unsupported iconv: try 'iconv -l' to get the list of supported encodings $ Looks like either we need teach iconv again about this encoding or map it in evolution. Issue looks serious for me (MAJOR severity) big percent of mails sent with outlook + HE have such encoding.
Example of such message source: To: <vova@...> Date: Fri, 25 Dec 2009 11:58:20 +0300 User-Agent: KMail/1.8 References: <200912251137.46223.irozet@...> In-Reply-To: <200912251137.46223.irozet@...> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200912251158.20144.irozet@...> Return-Path: irozet@... Subject: Re: upgrade Reply-To: Irina Rozet <irozet@...> From: Irina Rozet <irozet@...> Content-Type: multipart/related; type="multipart/alternative"; boundary="=-lNDZshN76IPWt6zY+r/3" --=-lNDZshN76IPWt6zY+r/3 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="CP20866" now have error when create new context. Old contexts work ...
*** Bug 604753 has been marked as a duplicate of this bug. ***
Created attachment 159795 [details] [review] proposed ema patch for evolution-mapi; It seems the 'charset' parameter for a content-type is not needed when the message body was received as a unicode version, thus I removed it from there. The problem is that I cannot reproduce the issue with missing whole paragraphs with actual master of gtkhtml, evolution*. Could anybody of you give a try to this, please? The only problem is that the local cache should be erased, thus the message will be regenerated, and the old "broken" version of it will not be used. It's enough to remove all files under ~/.evolution/mail/mapi/<account>/folders/ or in the respective folder. Thanks in advance.
Milan, is there any chance you could build a custom package for Fedora 13 and I'll test it at the office?
Interesting, I'm using a Fedora 13 nightly build from 20100501 and this is working fine for me now. The packages I'm using are the following: evolution-mapi-0.30.1-1.fc13.i686 evolution-2.30.1-2.fc13.i686 evolution-exchange-2.30.1-1.fc13.i686 evolution-data-server-2.30.1-2.fc13.i686 Can anyone confirm this? I just realized another problem: I can't select text by double clicking, I can select text while dragging with the mouse though. Obviously this is totally unrelated to this bug report.
(In reply to comment #9) > I have seen that together with message about can'n decode CP20866 encoding. > > like: > Could not open converter for 'CP20866' to 'UTF-8' charset > > > And yes, messages have CP20866 encoding > > but iconv have no idea what is cp20866 (actually there is old commented code > that notice cp20866 as alias for koi8-r encoding) > > $ iconv -f cp20866 -t koi8-r < /etc/hosts > iconv: conversion from cp20866 unsupported > iconv: try 'iconv -l' to get the list of supported encodings > $ > > Looks like either we need teach iconv again about this encoding or map it in > evolution. > > Issue looks serious for me (MAJOR severity) big percent of mails sent with > outlook + HE have such encoding. same problem in evolution 2.29.92
(In reply to comment #14) > Interesting, I'm using a Fedora 13 nightly build from 20100501 and this is > working fine for me now. The packages I'm using are the following: > > evolution-mapi-0.30.1-1.fc13.i686 Hmm, there doesn't seem to be any custom message for evolution-mapi in F13 and rawhide as of now. Something else fixed it for you probably, maybe server returned other values for you. Anyway, I'm committing this to master and stable, I do not see anything wrong on it (I see correctly, hopefully).
Created commit 663ae2b in ema master (0.31.2+) Created commit 2421f3a in ema gnome-2-30 (0.30.2+)
*** Bug 621300 has been marked as a duplicate of this bug. ***
*** Bug 628435 has been marked as a duplicate of this bug. ***