Version: 4.8 (using KDE 4.8.0)
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:
Lesen Sie diesen Newsletter mit Bildern und in Farbe!=0AKlicken Sie hier:=
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=
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).
Steps to Reproduce:
I have not been able to discover a pattern. Some message show correctly, others like the one above. Totally mangled.
Messages show correctly without the raw encoding showing on screen.
If you need any other info or examples, just ask.
could you put email in attachment to this bug report ?
Created attachment 68332 [details]
first example. For privacy reasons overwrote email addresses.
Created attachment 68333 [details]
different language, same problem
could you store email as mailbox please.
it's more easy to import mail.
Created attachment 68431 [details]
Should be an email with a PDF attachment.....
Nice example of a totally useless result in KMail2.
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.
Maybe silly question but are my messages damaged then? Or only parsed incorrectly?
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"
it's on strike...
*** Bug 293039 has been marked as a duplicate of this bug. ***
Created attachment 88415 [details]
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.
Confirmed on kontact and kdepim 4.14.1 on debian sid.
(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 ?
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.
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.