Version: 1.9.1 (using KDE KDE 3.5.2) Installed from: Unlisted Binary Package Compiler: gcc 3.2.3 Redhat Enterprise Linux 3 (Scientific Linux 3.05) OS: Linux When I forward an email which was originally HTML the message seems to be corrupt, and will not display in KMail and other clients. I view all email in plain text, and compose like that too. If I take such a message, select 'Forward inline' to create a new (plain text), and send it to myself, when it arrives the message area shows up as blank. I will attach sample messages. One is the original HTML email, the second the result of forwarding the message inline. Note that if I use Forward as Attachment, all is OK. Also, if I Forward Inline, and add a message at the start of the new email, it seems to work OK too. The only problem is if I Forward Inline without adding anything to the message. The only difference I can see is that the Content-type headers in the messages differ: Content-Type: Multipart/Alternative; charset="iso-8859-1" when the email is corrupt and Content-Type: text/plain; charset="iso-8859-1" When things are working properly.
Created attachment 16143 [details] Original HTML email An HTML email which I used to test this.
Created attachment 16144 [details] Email which does not show properly in KMail If I forward the HTML email inline without adding anything to the message, I get this in my inbox.
Created attachment 16145 [details] Text of an email which shows up OK If I forward the original email inline, and add a line of text at the start, the Content-Type header is correctly set to text/plain, as seen in this email.
SVN commit 541990 by kloecker: Fix bug 127526 (Malformed message when forwarding HTML email): Always reset the Content-type of the reference message to text/plain. BUG:127526 M +7 -3 messagecomposer.cpp --- branches/KDE/3.5/kdepim/kmail/messagecomposer.cpp #541989:541990 @@ -395,9 +395,13 @@ // if the user made any modifications to the message then the Content-Type // of the message is no longer reliable (e. g. if he editted a draft/resent a // message and then removed all attachments or changed from PGP/MIME signed - // to clearsigned); therefore we reset the Content-Type to text/plain. - if ( mComposeWin->isModified() ) - mReferenceMessage->setHeaderField( "Content-Type", "text/plain" ); + // to clearsigned); + // even if the user didn't make any modifications to the message the + // Content-Type of the message might be wrong, e.g. when inline-forwarding + // an mp/alt message then the Content-Type is set to mp/alt although it should + // be text/plain (cf. bug 127526); + // therefore we reset the Content-Type to text/plain in any case. + mReferenceMessage->setHeaderField( "Content-Type", "text/plain" ); mUseOpportunisticEncryption = GlobalSettings::self()->pgpAutoEncrypt(); mAllowedCryptoMessageFormats = mComposeWin->cryptoMessageFormat();
*** Bug 111974 has been marked as a duplicate of this bug. ***