GNOME Bugzilla – Bug 536773
Evolution Mail and Calendar: Encoding of mail's subje...
Last modified: 2008-06-12 10:40:06 UTC
Encoding of mail's subjects in Table View Distribution: Ubuntu 8.04 (hardy) Gnome Release: 2.22.2 2008-06-03 (Ubuntu) BugBuddy Version: 2.22.0
In the table view encoded email-adresses/names are not correctly decoded: An example: 1: In the table view (from): =?ISO-8859-1?Q?Michal_=3Fiha=3F_ 2: In the message preview (from): Michal Čihař 3: In the message window (from): Michal Čihař 4: In the message raw text / headers (from): From: Michal =?UTF-8?B?xIxpaGHFmQ==?= Expected: The table view (1) should show the name correctly (as in 2,3). I do not understand why it converts from UTF8 to ISO8859 and still uses mail header encoding - it should convert it to plain text (as correctly done in 2,3). Thanks for looking into that, I am not yet able to provide a patch on my own.
is this about IMAP or POP? this is fixed in 2.22, but you probably need to remove the index file.
Thank you André, but I could not solve it. this happens on IMAP-folders (Sorry, I cannot counter-check with POP). I removed the ~/.evolution/mail/local/Inbox.ev* files, also the summary* and cmeta file in .../mail/imap/*/folder/* resides, but that did not change it. Thank you for giving me a hint how to rebuild the index. Jonas
you need to delete .evolution/mail/imap/<account>/folders/INBOX/summary replacing INBOX with whatever folder it is.
probably duplicate of bug 523259, found the comment in bug 527504.
Sorry, deleting .evolution/mail/imap/<account>/folders/INBOX/summary does not help. Another example: =?ISO-8859-1?Q?Matthias_B=FCrker_ (message preview shows it correctly as Matthias Bürker, message list shows the above) I wonder if the format is RFC-konform but it looks OK to me. Also, The message preview is able to decode it correctly.
I found out via the duplicate marking that it is related to googlemail.com IMAPs only. Thanks for your help. ets wait for gmail to fix that.
*** This bug has been marked as a duplicate of 536457 ***
Re comment #7: based on my investigation, I'd say this is a (UI) bug in Evolution's (or evolution-data-server's) handling of IMAP messages (see my comments in Bug #523259). There's no need to blame Gmail's IMAP servers for this bug too.
I can confirm that this happens not with all IMAP-servers. I have this bug on gmail-IMAP. It happens in To and From columns in the table view. Test messages from and to my employer's IMAP-server show correctly. (They use CommuniGate Pro 5.0.14).
Some more info: I connect to imap.gmail.com and have a @googlemail.com adress. Today I try with Evolution 2.10.1 I can reproduce this bug also by copying/moving RFC-encoded-header mails (within Evolution) from one IMAP server to gmail (bug appears ALWAYS) and from gmail to the other (bug SOMETIMES away). The headers do not change in this process: From: "=?ISO-8859-1?Q?Eric_Br=E9hault?=" <ebrehault@gmail.xxx> persists on both servers, but is differently rendered (one correct, gmail "=?ISO-8859-1?Q?Eric_Br=E9hault _ <ebrehault@gmail.xxx>"). Some more examples of problematic headers: From: "=?ISO-8859-1?Q?Jonas_H=E4ggqvist?=" <rasher@gmail.xxx> From: =?ISO-8859-1?Q?Martin_M=FClller-Hermann_<mmherm@t-online.xxx>?= From: =?ISO-8859-15?Q?Marcel_Lucas_M=FCller?= <marcel.mueller@uniklinik-freiburg.xxx> From: =?UTF-8?Q?Klaus_M=C3=BCller?= <k.mueller@vimedia.xxx> To: =?ISO-8859-1?Q?nana_r=E4msenberg_<raemsi-03@gmx.xxx>?= From: =?ISO-8859-1?Q?Silvana_D=FCrschmied_<nana22@gmx.xxx>?= From: =?iso-8859-1?Q?ZfS_Universit=E4t_Freiburg?= <verena.saller@zfs.uni-freiburg.xxx> From: =?iso-8859-15?Q?Marcel_Vi=EBtor?= <marcelvietor@web.xxx> From: =?WINDOWS-1252?Q?Koch_Milo=9A_<miloskoch@upcmail.xxx>?= From: =?iso-8859-1?Q?lisa_meyer-sch=F6nbohm?= <lisa_m-s@web.xxx> Some 10% of my mails have encoded to/from adresses! I hope this helps. Will try to figure out this behaviour with 2.22 the next days. But I am quite sure it will be similar.
No need to test with 2.22.x. My comment #9 was incorrect. I tested it with an (yet unknown) imapd on a personal NAS/server/whatever box. The bug didn't occur with messages read through that IMAP server. So, this seems yet another Gmail IMAP bug.