GNOME Bugzilla – Bug 523259
Problem with subject header
Last modified: 2008-06-11 16:36:59 UTC
Please describe the problem: Sometimes when I get an e-mail Subject header has a kind of wrong encoding. For example, I get "=?UTF-8?Q?vy=C5=BEkou=C5=A1=C3=ADme =C4=8Do to um=C3=AD?=" instead of "vyžkoušíme čo to umí". This is in Evolution 2.12. Evolution 2.22 doesn't show anything on subject line. List of all headers of that message is: Received: from <jiri@eischmann.cz> for <jiri.eischmann@mail255.centrum.cz> Received: from piper.aerohosting.cz ([217.11.249.9]) by mail7.centrum.cz (Centrum Mailer) with ESMTP ;Tue, 18 Mar 2008 20:09:25 +0100 X-CentrumSpamScore: +06 X-SpamDetected: 0 X-VirusDetected: 0 X-Virus-Scanner: This message was checked by NOD32 Antivirus system NOD32 for Linux Mail Server. For more information on NOD32 Antivirus System, please, visit our website: http://www.nod32.com/. X-ZMailerMID: RTJYGIy09f90bd947e01364 Received: from localhost (127.0.0.1 [127.0.0.1]) by piper.aerohosting.cz (Top MailServer v3.1) with SMTP id YYB78938 for <jiri.eischmann@centrum.cz>; Tue, 18 Mar 2008 20:09:38 +0100 Datum: Tue, 18 Mar 2008 20:09:38 +0100 Od: jiri@eischmann.cz Odpovědět-komu: jiri@eischmann.cz Komu: jiri.eischmann@centrum.cz Předmět: Message-ID: <5fc3c82d95104b52c3b0d4350e27f570@eischmann.cz> X-Mailer: IceWarp Web Mail 5.6.7 X-Originating-IP: 146.102.105.5 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Evolution-Source: imap://jiri.eischmann@imap.centrum.cz/ Steps to reproduce: 1. sometimes when I get an e-mail (i.e. from Merak webmail or some generated mails like bank, airlines etc.) 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Could you please attach an example message?
Created attachment 107582 [details] message where this problem occurs
Created attachment 107583 [details] Another messager where this problem occurs
Thanks for the quick response!
Ahoj, could be related to bug 315513. both subject lines are invalid, so this is not an evolution bug. Subject: =?UTF-8?Q?vy=C5=BEkou=C5=A1=C3=ADme =C4=8Do to um=C3=AD?= displays nothing in 2.22.0. mixing up 7bit characters with utf-8 tokens is incorrect. this is not RFC 2047 conformant. Subject: **SPAM** =?utf-8?Q?Discover Istanbul - the gate to the Orient?= displays "**SPAM** " in 2.22.0. "=?utf-8?Q?Discover Istanbul - the gate to the Orient?=" is just plain wrong, i don't see *any* encoded tokens after the ?Q?. please complain to skyeurope to respect RFC 2047.
I was confused because Thunderbird and my webmail show it properly.
Adjusting Product. This is libcamel territory, which lives in E-D-S.
Created attachment 107600 [details] a message where the problem occurs Today, I got another e-mail with problem on subject line. Now it's not UFT-8 but Windows-1250. Again, it's a problem in Evolution. Thunderbird and a webmail shows it properly. I believe it doesn't have to be a bug in Evolution. On the other hand, if anything else shows it properly Evolution should show it properly as well.
rfc2047 encoded-word tokens are not allowed to contain spaces (obviously, or they wouldn't be tokens)
OK, I understand it's not a bug in Evolution and those messages don't follow standards. But please, at least, consider supporting them (i.e. like Thunderbird) because there are a lot of those messages out there and it would be better for users.
Wouldn't this fall under the "accept everything, but follow standards yourself" philosophy of mail clients? But Jeff would know better than I of the technical difficulties involved.
I patched this a while back, he's probably using an old version
Of course I'm not using an old version ;-) I'm using Evolution 2.12 in my main system and 2.22 (GNOME from 3/17) in testing system. As I wrote at the beginning of this bug report both versions behave differently. 2.12 shows subject line like this: "=?UTF-8?Q?vy=C5=BEkou=C5=A1=C3=ADme =C4=8Do to um=C3=AD?=" and 2.22 doesn't show anything, just blank line. We can discuss what's better but I think both is not OK.
can developers please read previous comments? ;-) i already linked to bug 315513 which is jeff's "I patched this a while back". and both me and jiří wrote that we use 2.22 and see the same problems.
ah yeah, reopening - the empty subject line is a regression to me and is even more confusing than having a broken non-decoded subject line.
fejj fixed bug 417000 in the meantime so now the subjects of both emails ARE correctly displayed in the preview pane, but not in the message list pane (running yesterday's svn checkout of the gnome-2-22 branch here).
does deleting the mbox.ev-summary fix it? it should... I hope :\
yes, deleting mbox.ev-summary fixed it. perfect. closing this report as a duplicate of bug 417000. this issue will be fixed in 2.22.1. *** This bug has been marked as a duplicate of 417000 ***
*** Bug 527504 has been marked as a duplicate of this bug. ***
*** Bug 527902 has been marked as a duplicate of this bug. ***
Actually, bug 417000 has nothing much to do with decoding, furthermore, when I import a sample message from the first attachment, then I see the From header non-decoded in both message list and message preview, all on actual trunk.
Created attachment 112278 [details] [review] proposed eds patch for evolution-data-server; The subject line fixed the patch in bug #524704, but the patch there didn't fix email addresses, where the encoded "word" contains space(s). This patch double checks for encoded words in name part of the address. Users should recreate his/her summary files same as before, to see the change even in the message list.
*** Bug 536962 has been marked as a duplicate of this bug. ***
My apologies for the duplicate at Bug 536962, I must have overlooked this bug when searching. In Evolution 2.22.2 (Gnome 2.22.2) the "Subject" header is always correct, in both the message and mail preview pane. The "From" header is correct in the mail preview pane but not in the message list. Example from my mailbox, with the ASCII characters replaced with X's (as it is a person's name) =?iso-8859-1?Q?X=E4XXXXXXXX=2C_R=2EJ=2E?= <R.J.XXXXXXXX@example.com> As correctly displayed in the mail pane: XäXXXXXXXX, R.J. <R.J.XXXXXXXX@example.com> This behaviour occurs consistently with mail from contacts whose names are not written exclusively in ASCII characters and who are not (yet) in my address book, this also happens with different encodings (ISO-2022-JP, GB2312, ISO-8859-1) This issue appears to be fixed everywhere but the From header in the message list pane, the Subjects are always correct.
Fejj, Sankar, Matt: Can you look at the patch by Milan ?
0) Note that in comment #24 there seem to be no spaces enclosed in the "rfc2047 encoded-word token" in what I assume to be a copy of the From header, as the space is replaced by an underscore, so that may be another bug. 1) Anyhow, I can reproduce this easily with rfc2047 encoded-word tokens without a space and even without a space replaced by an underscore, but _only_ with message from an IMAP folder. (Note that both messages in comment #2 and comment #3 are also from an IMAP folder.) For instance, Rogério Brito just posted a message to the LKML (his email address is published non-obfuscated on his homepage, so I feel free to use it here) with this header: From: =?iso-8859-1?Q?Rog=E9rio?= Brito <rbrito@ime.usp.br> This name is displayed, by version 2.22.2 and only in the message list, as (copied by hand): =?ISO-8859-1?Q?Rog=E9rio_Brito_ <rbrito@ime.usp.br> But, if I import a copy of this message to a local (MBOX) folder it is displayed correctly as: Rogério Brito <rbrito@ime.usp.br> even though, the From header is identical to the header used in the IMAP message. 2) Again, no spaces are involved here. Should I open another bug?
(In reply to comment #26) > 2) Again, no spaces are involved here. Should I open another bug? If it looks like an IMAP specific bug, then please do file a bug against IMAP.
looks like a duplicate of this bug #536457 *** This bug has been marked as a duplicate of 536457 ***
Come on Jeff, just half of it, with spaces inside it will not work anyway. (the patch I attached some time back.) I bet the patch in the other bug will not work for cases like this: =?UTF-8?Q?vy=C5=BEkou=C5=A1=C3=ADme =C4=8Do to um=C3=AD?= if placed in mail address.