Tickets :: [#10169] Some mails can't be displayed

6.0.0-beta1

7/5/25

Summary	Some mails can't be displayed
Queue	IMP
Queue Version	5.0.5
Type	Bug
State	Not A Bug
Priority	2. Medium
Owners
Requester	jacob-horde (at) vindvejr (dot) dk
Created	06/01/2011 (5148 days ago)
Due
Updated	04/13/2018 (2640 days ago)
Assigned	06/02/2011 (5147 days ago)
Resolved	06/15/2011 (5134 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

04/13/2018 09:51:33 AM	build+horde (at) de-korte (dot) org	Comment #13	Reply to this comment
There is no point in adding comments to bugs that have already been closed. Besides this, if you read the earlier comments, you'll find that the problem cannot be fixed by Horde.

04/13/2018 09:47:20 AM	samuel (dot) wolf (at) wolf-maschinenbau (dot) de	Comment #12	Reply to this comment
libxml2:amd64 2.9.4+dfsg1-2.2+deb9u2 imp 6.2.21 stable horde 5.2.17 stable Debian 9.4

04/13/2018 09:44:57 AM	samuel (dot) wolf (at) wolf-maschinenbau (dot) de	Comment #11	Reply to this comment
Same issue here, but with charset="windows-1252" Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable SOMETEXT=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0 =A0 SOMETEXT [...]

10/16/2012 05:53:07 PM	Michael Slusarz	Comment #10	Reply to this comment
We have the same bug. Some HTML-Mails become unreadable. More failure tolerance would be nice, because there is no way to read these mails at all. PLEASE read comment 6. There is nothing we can do about this case, when the charset is misidentified within the HTML data, since we can't parse the HTML data in the first place to replace it.

10/16/2012 03:48:06 PM	ritter (at) perfectpixel (dot) de	Comment #9	Reply to this comment
We have the same bug. Some HTML-Mails become unreadable. More failure tolerance would be nice, because there is no way to read these mails at all.

06/15/2011 10:27:20 AM	Michael Slusarz	Comment #8 State ⇒ Not A Bug	Reply to this comment
That's it - if I change charset from "unicode" to "UTF-8" in the HTML part it renders correctly. Which source file can I look into if I want to investigate why this behaviour is system-dependent? I have no clue. But this is way beyond the scope of Horde/IMP.

06/15/2011 10:20:34 AM	jacob-horde (at) vindvejr (dot) dk	Comment #7	Reply to this comment
[Show Quoted Text - 17 lines][Hide Quoted Text] I'm using libxml 2.7.8. I'll check other related components tomorrow. A related issue is that the charset in that HTML part is reported to be "unicode". This is not a valid charset (see http://www.iana.org/assignments/character-sets). I can only guess that libxml does some kind of best-guess as to the current charset if given bad charset input - it's possible on your system that this best guess is ISO-8859-1, while on my system it is UTF-8, which would explain why it works on some systems but not others. (You can test and see if this is the case by changing the 'unicode' charset definition in the HTML part to 'UTF-8'). However, there is nothing we can do if this is the case. We can't change the charset contained within HTML code because we have to parse the HTML first (via the xml functions) - but this parsing code will apply the charset found in a meta charset tag during the parsing itself. That's it - if I change charset from "unicode" to "UTF-8" in the HTML part it renders correctly. Which source file can I look into if I want to investigate why this behaviour is system-dependent? It must be possible to support bad charset definitions, either by configuration of libxml2 or through the API.

06/14/2011 08:15:44 PM	Michael Slusarz	Comment #6	Reply to this comment
I'm using libxml 2.7.8. I'll check other related components tomorrow. A related issue is that the charset in that HTML part is reported to be "unicode". This is not a valid charset (see http://www.iana.org/assignments/character-sets). I can only guess that libxml does some kind of best-guess as to the current charset if given bad charset input - it's possible on your system that this best guess is ISO-8859-1, while on my system it is UTF-8, which would explain why it works on some systems but not others. (You can test and see if this is the case by changing the 'unicode' charset definition in the HTML part to 'UTF-8'). However, there is nothing we can do if this is the case. We can't change the charset contained within HTML code because we have to parse the HTML first (via the xml functions) - but this parsing code will apply the charset found in a meta charset tag during the parsing itself.

06/14/2011 08:09:10 PM	jacob-horde (at) vindvejr (dot) dk	Comment #5	Reply to this comment
[Show Quoted Text - 12 lines][Hide Quoted Text] Without examples, there isn't much we can do. Create a test mail that produces this behavior, if you don't want to upload a real message. Okay, I finally anonymized a mail and stripped it down while preserving the content that triggers the bug in IMP - attached. Renders fine here. Pursuant to horde/docs/INSTALL: Make sure you are using a newer (v2.7 or greater) version of libxml. Older versions of libxml are broken when handling certain charsets. I'm using libxml 2.7.8. I'll check other related components tomorrow.

06/14/2011 07:37:23 PM	Michael Slusarz	Comment #4	Reply to this comment
Without examples, there isn't much we can do. Create a test mail that produces this behavior, if you don't want to upload a real message. Okay, I finally anonymized a mail and stripped it down while preserving the content that triggers the bug in IMP - attached. Renders fine here. Pursuant to horde/docs/INSTALL: Make sure you are using a newer (v2.7 or greater) version of libxml. Older versions of libxml are broken when handling certain charsets.

06/14/2011 07:26:07 PM	jacob-horde (at) vindvejr (dot) dk	Comment #3 New Attachment: mail	Reply to this comment
Without examples, there isn't much we can do. Create a test mail that produces this behavior, if you don't want to upload a real message. Okay, I finally anonymized a mail and stripped it down while preserving the content that triggers the bug in IMP - attached.

06/02/2011 10:09:41 PM	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
Without examples, there isn't much we can do. Create a test mail that produces this behavior, if you don't want to upload a real message.

06/01/2011 04:57:33 PM	jacob-horde (at) vindvejr (dot) dk	Comment #1 New Attachment: imp-mail.png State ⇒ Unconfirmed Patch ⇒ No Milestone ⇒ Queue ⇒ IMP Summary ⇒ Some mails can't be displayed Type ⇒ Bug Priority ⇒ 2. Medium	Reply to this comment
Some mails are simply displayed as: ÿþ and nothing else (see screenshot). The mails that can't be displayed doesn't seem to have much in common: one is base64 encoded: --> [...] Subject: =?utf-8?B?UmU66LK35a625bey5L+u5pS557Wm5oKo55qE5L+h55So6KmV5YO577yaU0QvTWljcm9TRC9NaW5pU0QvTU1DIE1lbW9yeSBDYXJkIFJlYWRlciBVU0IgMi4wIC0gVUvvvIgyNjA3NzEzNjgxOTPvvIk=?= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u [...] <-- and another one is not: --> [...] Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC1B6F.66B13F22" Subject: SV: SV: Anne og job [...] This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1B6F.66B13F22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey min ven! [...] <-- Clicking "Text part" will display it in the same way, just in a new window. I can mail the raw mails, but prefer not to upload them here. Thunderbird displays them fine, and I haven't experienced the problem before IMP 5.0.4.