Summary: | multipart mails with imap are broken | ||
---|---|---|---|
Product: | [Applications] kmail | Reporter: | Andre Woebbeking <woebbeking> |
Component: | IMAP | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugzilla-kde |
Priority: | NOR | ||
Version: | 1.6.50 | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Andre Woebbeking
2004-01-30 15:30:41 UTC
Subject: Re: New: multipart mails with imap are broken On Friday 30 January 2004 15:30, AndrX WXbbeking wrote: > I use IMAP with "Load attachments on demand". Multipart mails are broken: > - in plain text parts the encodig of the part isn't used, so I get e.g. > Gr=FCsse > - some attachments can't be saved or opened e.g. PowerPoint. > > If I copy such a mail to a local folder all works fine. Do you see this problem only with HEAD or also with kde 3.2 (rc1)? Subject: Re: multipart mails with imap are broken
On Saturday 31 January 2004 14:04, Carsten Burghardt wrote:
>
> Do you see this problem only with HEAD or also with kde 3.2 (rc1)?
only with HEAD.
CVS commit by burghard: Fix LOD by creating the partNode from the already existing object and not from string CCMAIL: 73824-done@bugs.kde.org M +1 -0 kmmessage.h 1.160 M +1 -2 partNode.cpp 1.44 --- kdepim/kmail/partNode.cpp #1.43:1.44 @@ -119,6 +119,5 @@ partNode * partNode::fromMessage( const // subscrib-shared, so we just force mimelib to parse the whole mail // as just another DwBodyPart... - DwBodyPart * mainBody = new DwBodyPart( msg->asDwString(), 0 ); - mainBody->Parse(); + DwBodyPart * mainBody = new DwBodyPart( *msg->getTopLevelPart() ); partNode * root = new partNode( mainBody, mainType, mainSubType, true ); --- kdepim/kmail/kmmessage.h #1.159:1.160 @@ -588,4 +588,5 @@ public: If there is no body part, return value will be zero. */ DwBodyPart * getFirstDwBodyPart() const; + DwMessage * getTopLevelPart() const { return mMsg; } /** Fill the KMMessagePart structure for a given DwBodyPart. This is still the case for KMail in KDE 3.3.1 For imap account multipart mails are shown without headers for text/plain parts when viewing source (and attachment source is missing as well). This makes KMail displaying emails with the wrong encoding. I would also like to confirm this bug for KMail in KDE 3.3.1. Is this really so hard to fix? :-( I don't know if it is that hard to fix. We thought it was fixed. You have of course also tried long and hard to fix it, I trust? I committed a fix in this area for HEAD so it would be good if you could provide a test email (gzip'ed) to see if it's fixed. Carsten Should not happen with 3.4 (past beta1) anymore. If you still encounter these problems I definitely need a testmail. Thanks a lot, seems to be fixed now. BUT: I have one message (that is too private to publish as is) still causing problems. I updated your last changes from kdepim/kmail manually because I did not want to download the whole CVS repository. :) If the following problem seems to be fixed by another change in other files, I'm sorry. We'll see thins when beta 2 has arrived. Ok, the problem is that the charset encoding is not applid correctly to the text part of the following message. I use utf-8 as default charset and this message was sent with iso-8859-1. When I preview the message in KMails preview area, all umlauts are crap (iso-8859-1 treated as utf-8). When I double-click the message (and download the whole msword-data :( ), the umlauts are correctly displayed. but not in the preview area. When I press "v" to view the message source, the preview area get updated and shows correct umlauts. So there is no solution without downloading the whole message. I tried but could not reproduce the error for a message created with KMail, possibly, this only affects broken mime structures. The MIME-structure of this message looks like this (anonymized): MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_14D6_01C4CFCC.98146D10" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcTPw/xL+k5TF5UESDirkJqH+YfssA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ID: JlEE1TZA8eAjryAyCkTvrjkNR86sMYyRaZ8maE3vEfaFl1uJpwEUsc X-TOI-MSGID: 319739a1-b350-4e41-9f37-fbd0d5b9de4a This is a multi-part message in MIME format. ------=_NextPart_000_14D6_01C4CFCC.98146D10 Content-Type: multipart/related; boundary="----=_NextPart_001_14D7_01C4CFCC.98146D10" ------=_NextPart_001_14D7_01C4CFCC.98146D10 Content-Type: multipart/alternative; boundary="----=_NextPart_002_14D8_01C4CFCC.98146D10" ------=_NextPart_002_14D8_01C4CFCC.98146D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [... text part ...] ------=_NextPart_002_14D8_01C4CFCC.98146D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [... crappy html part ...] ------=_NextPart_002_14D8_01C4CFCC.98146D10-- ------=_NextPart_001_14D7_01C4CFCC.98146D10 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <image001.gif@01C4CBD2.2B2DF7A0> [... data ...] ------=_NextPart_001_14D7_01C4CFCC.98146D10-- ------=_NextPart_000_14D6_01C4CFCC.98146D10 Content-Type: application/octet-stream; name="Filename.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Filename.pdf" [... dozens of kilobytes of data ...] ------=_NextPart_000_14D6_01C4CFCC.98146D10 Content-Type: application/msword; name="Wordfile.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Wordfile.doc" [... tons of binary crap ...] ------=_NextPart_000_14D6_01C4CFCC.98146D10-- So I know that this message is ugly mime code, but KMail's behaviour is not correct either. Sorry, forgot to mention: Atm, I use KDE-3.4 beta 1 with recent changes from CVS for the files objecttreeparser.cpp and kmsender.cpp patched in manually. Bernd, what you are describing is being discussed in #84425. Maybe you can pitch in there. comment #11: Thank you for the hint, this looks like is is the same issue. :) So *this* bug is finally resolved for me now. |