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/