After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 681040 - Incorrect code page in subject in message list
Incorrect code page in subject in message list
Status: RESOLVED WONTFIX
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.4.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[imapx] evolution[google]
Depends on:
Blocks:
 
 
Reported: 2012-08-02 07:04 UTC by Milan Crha
Modified: 2012-11-26 13:51 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test message (2.04 KB, message/rfc822)
2012-08-02 07:04 UTC, Milan Crha
Details
how it's shown in evolution (21.32 KB, image/png)
2012-08-02 07:04 UTC, Milan Crha
Details

Description Milan Crha 2012-08-02 07:04:07 UTC
Created attachment 220118 [details]
test message

Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=844466

The attached test message, when received on Google Mail through IMAPx shows incorrect codepage in Subject in message list, while message preview shows Subject correctly.
Comment 1 Milan Crha 2012-08-02 07:04:54 UTC
Created attachment 220119 [details]
how it's shown in evolution
Comment 2 Milan Crha 2012-11-26 13:51:27 UTC
I thought this is fixed already, but it isn't. I'm afraid this cannot be fixed properly, unless at least headers are downloaded as well, but even after that there still can be issues. The reason why message preview shows the message properly is because it uses character set as defined by Content-Type header, and it uses it for the whole message, including Headers in preview. When IMAP downloads the message into folder summary (the part which shows content in the message list), it may not have this information available, but even if it has, the Content-Type charset should not influence charset of other headers. That said, the sending server/software should encode Subject to follow RFC 2047, thus it'll be clear in which charset the header is.

http://tools.ietf.org/html/rfc2047