[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Multipart alternative bug
From:       Shaheed Haque <srhaque () theiet ! org>
Date:       2012-01-09 21:40:21
Message-ID: CAHAc2jffeCPyCMRZFua9b6VUvMz5r0wCNW2uGX4jvwixRy72mg () mail ! gmail ! com
[Download RAW message or body]

I'm not sure if this is related or not, but Content::parse() seems to have
trouble parsing Content-Type headers. For example, I have a message with
this header:

Content-Type:
multipart/related; type="multipart/alternative";
boundary="----_=_NextPart_001_01CCCBB5.9764D6D8"

which, on querying, I was amazed to see was reported back as "text/plain".
However, I can then do this

QByteArray tmp = KMime::extractHeader(head(), "Content-Type");
contentType()->from7BitString(tmp);

which works as expected.

On 20 December 2011 19:06, Andras Mantia <amantia@kde.org> wrote:

> Andras Mantia wrote:
>
> > A quick history browsing doesn't reveal anything changed in OTP or KMime
> > in the past days, so the breakage might come from other place. No idea
> > from where, although still this two is the most suspected, even if it is
> > about KMime usage and not KMime itself
>
> A new test shows it got broken by the filters, probably bogofilter.The
> messages got somehow text/plain for content type although they were
> multipart/alternative. Sigh.
> This will be even harder to catch what went wrong.
>
> Andras
> _______________________________________________
> KDE PIM mailing list kde-pim@kde.org
> https://mail.kde.org/mailman/listinfo/kde-pim
> KDE PIM home page at http://pim.kde.org/
>
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]