Bug 292767 - KMail2 (4.8.0) incorrectly displays some messages (does not process the encoding)
Summary: KMail2 (4.8.0) incorrectly displays some messages (does not process the encod...
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 4.8
Platform: OpenSUSE Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
: 293039 (view as bug list)
Depends on:
Reported: 2012-01-29 09:08 UTC by Frits Spieker
Modified: 2015-02-04 19:52 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:

example 1 (9.95 KB, text/plain)
2012-01-30 10:58 UTC, Frits Spieker
different language, same problem (8.94 KB, text/plain)
2012-01-30 10:59 UTC, Frits Spieker
Should be an email with a PDF attachment..... (158.59 KB, application/mbox)
2012-02-02 13:14 UTC, Frits Spieker
Sample message (16.79 KB, application/mbox)
2014-08-25 11:59 UTC, Vasily Khoruzhick
attachment-7432-0.html (254 bytes, text/html)
2015-02-04 19:53 UTC, Tarpast

Note You need to log in before you can comment on or make changes to this bug.
Description Frits Spieker 2012-01-29 09:08:22 UTC
Version:           4.8 (using KDE 4.8.0) 
OS:                Linux

Since upgrade to KMail2 4.8, I run into the problem that some incoming emails don't show correct, but instead show the raw content such as the one below:

Content-Type: text/plain;charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Lesen Sie diesen Newsletter mit Bildern und in Farbe!=0AKlicken Sie hier:=
=0A=3D> http://=
eBay hat diese Mitteilung an=20=
)=0Agesendet. Ihr Vor- und Nachname in dieser Mitteilung sind=0Aein Hinwei=
s darauf, dass die Nachricht tatsaechlich von eBay=0Astammt.=0A=0AMehr zum=
=0AKostenlos einstellen!*=0ASagen Sie nicht, wir h=C3=A4tten Sie nicht gew=
arnt=0A=0ANEU=0ANur f=C3=BCr kurze Zeit: kostenlos Auktionen einstellen, j=
etzt jeden Tag der Woche=0A=0AJetzt Verkaufsrausch starten=0A=3D> http://r=

etc. etc....

The "Encoding" under the View menu option is set to AUTO, but also changing it to the encoding that can be found in the message header (UTF-8 in the example above) does not help.

KMail started doing this since the upgrade to KDE4.8.0 (from 4.7.4).

Reproducible: Sometimes

Steps to Reproduce:
I have not been able to discover a pattern. Some message show correctly, others like the one above. Totally mangled.

Expected Results:  
Messages show correctly without the raw encoding showing on screen.

If you need any other info or examples, just ask.
Comment 1 Laurent Montel 2012-01-30 07:45:20 UTC
could you put email in attachment to this bug report ?
Comment 2 Frits Spieker 2012-01-30 10:58:34 UTC
Created attachment 68332 [details]
example 1

first example. For privacy reasons overwrote email addresses.
Comment 3 Frits Spieker 2012-01-30 10:59:22 UTC
Created attachment 68333 [details]
different language, same problem
Comment 4 Laurent Montel 2012-01-31 13:54:06 UTC
could you store email as mailbox please.
it's more easy to import mail.
Comment 5 Frits Spieker 2012-02-02 13:14:29 UTC
Created attachment 68431 [details]
Should be an email with a PDF attachment.....

Nice example of a totally useless result in KMail2.
Comment 6 Andreas Mahel 2012-02-03 17:43:53 UTC
i have experienced the same behaviour, and I could narrow it down to the "Bogofilter Check" mail filter.
I've sent myself a multi part message from my web mail client, and with the filter turned off, the mail looked as expected, with the filter turned on, it showed the behaviour as above.

Looking at the raw mail content, the primary difference was that in the bogo-filtered message, the Content-Type in the mail header was:
    Content-Type: text/plain; charset="US-ASCII"
whereas in unfiltered message it looked like
    Content-Type: multipart/mixed; boundary="========GMX112281328289219935858"

I checked bogofilter standalone as well, running a "bogofilter -p -e" against an mbox file of the "unfiltered" test mail - the output here shows the correct header Content-Type .

So it looks that somewhere during the bogofilter run the Content-Type is being changed by kmail (or akonadi?).

If needed, I can as well attach the mbox files, or run additional tests.
Comment 7 mkkot 2012-02-20 19:03:18 UTC
Maybe silly question but are my messages damaged then? Or only parsed incorrectly?
Comment 8 Tarpast 2012-05-23 18:07:41 UTC
Different language, central european characters, KMail2 (4.8.2) same problem. I use bogofilter chceck. And  PDF attachments in quoted printable encoding mails are in text mode, not binary. Like this:
Content-Type: application/pdf; name="setkani vzdelavatelu pozvanka.pdf"
Content-Disposition: attachment; filename="setkani vzdelavatelu pozvanka.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_h2kdfy2a0

it's on strike...
Comment 9 Sandro Knauß 2013-03-28 08:59:23 UTC
*** Bug 293039 has been marked as a duplicate of this bug. ***
Comment 10 Vasily Khoruzhick 2014-08-25 11:59:04 UTC
Created attachment 88415 [details]
Sample message

4.14.0 is affected. Please use attached message to reproduce: kmail displays it correctly in message viewer, but it botches encoding when attempting to reply on this message.

It's just a guess, but I think it happens because this message consists of several parts in different encodings: text/plain in utf-8, text/html in koi8-r and text/plain in koi8-r.
Comment 11 Raúl 2014-10-06 07:14:05 UTC
Confirmed on kontact and kdepim 4.14.1 on debian sid.
Comment 12 Martin Koller 2015-02-01 21:07:43 UTC
(In reply to Frits Spieker from comment #5)
> Created attachment 68431 [details]
> Should be an email with a PDF attachment.....
> Nice example of a totally useless result in KMail2.

Can you still see the problem with recent KDE 4.14.x ?
Comment 13 Frits Spieker 2015-02-02 10:53:26 UTC

I had to install bogofilter again to test, but so far it seems to be behaving OK. PDF's arrive as normal attachments, don't get botched or anything like that. 

Seems resolved...
Comment 14 Tarpast 2015-02-04 19:52:57 UTC
Created attachment 90914 [details]

It seems to be OK, but it´s hard to say, because from Kmail2 4.10 I can´t 
reproduce it. Only some specific mail from some people, who use Gmail, are 
broken. These people were not be able to tell, how the message sent.