(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.4.1 (using KDE 3.0.0 -10) Severity: normal Installed from: Red Hat Linux 7.2.93 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) OS: Linux (i686) release 2.4.18-4smp OS/Compiler notes: I received a mime message from Eudora with the following structure: multipart/mixed multipart/alt plain text message HTML version PDF attachment PDF attachment Nothing appeared in the message display. I had the sender resend the message but this time I captured it with fetchmail. The message was formatted correctly with different boundary strings. The boundary string for the "alt" part just had ".ALT" appended. When I looked at the mail spool file the ".ALT" text had been stripped so all the boundary strings were identical. (Submitted via bugs.kde.org) (Called from KBugReport dialog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 04 June 2002 03:41 Kevin.J.Miller@jpl.nasa.gov wrote: > > I received a mime message from Eudora with the following structure: > > multipart/mixed > multipart/alt > plain text message > HTML version > PDF attachment > PDF attachment Are you sure that the structure is not: multipart/mixed multipart/alt plain text message HTML version PDF attachment PDF attachment With an "multipart/mixed" that doesn't contain parts. There is a to me known bug in Eudora that produces such broken format. Regards Michael Häckel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE8/D9ve9KEPyN2R8URAvO3AJ4zrT63pl/UjkBR4ORwPTUwBYJkqQCeLkck g75jMRSwUOWKT/E+o1wo+xc= =Wjbp -----END PGP SIGNATURE-----
--------------Boundary-00=_OJ77FSU6GIYH19OQGGJR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit When I checked the message in the KMail folder it was incorrectly formatted as you have stated so I first thought it was a Eudora bug. However when I got the mail from the pop server using fetchmail it was formatted correctly (see attached "fetchmail"). When I used KMail to fetch the same message what I found in the folder (see attached "folder") was corrupt. I first ran fetchmail with the option to leave the message on the server so I know that I got the same message with both fetchmail and KMail. I'm guessing that the problem is in the KMail code that fetches and sorts the messages. -Kevin Miller On Monday 03 June 2002 09:17 pm Michael Häckel wrote: > On Tuesday 04 June 2002 03:41 Kevin.J.Miller@jpl.nasa.gov wrote: > > I received a mime message from Eudora with the following structure: > > > > multipart/mixed > > multipart/alt > > plain text message > > HTML version > > PDF attachment > > PDF attachment > > Are you sure that the structure is not: > > multipart/mixed > multipart/alt > plain text message > HTML version > PDF attachment > PDF attachment > > With an "multipart/mixed" that doesn't contain parts. > There is a to me known bug in Eudora that produces such broken format. > > Regards > Michael Häckel > > > (Complete bug history is available at http://bugs.kde.org/db/43/43479.html) --------------Boundary-00=_OJ77FSU6GIYH19OQGGJR Content-Type: text/plain; charset="iso-8859-1"; name="fetchmail" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fetchmail" VGhpcyB3YXMgb2J0YWluZWQgZnJvbSBmZXRjaG1haWwgZGlyZWN0bHkNCg0K U3RhbmRhcmQgTWFpbCBIZWFkZXJzOg0KQ29udGVudC1UeXBlOiBtdWx0aXBh cnQvbWl4ZWQ7DQoJYm91bmRhcnk9Ij09PT09PT09PT09PT09PT09PT09PV8y NTcyMTI4PT1fIg0KDQotLT09PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4 PT1fDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCgli b3VuZGFyeT0iPT09PT09PT09PT09PT09PT09PT09XzI1NzIxMjg9PV8uQUxU Ig0KDQotLT09PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4PT1fLkFMVA0K Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJpc28tODg1OS0x IjsgZm9ybWF0PWZsb3dlZA0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog cXVvdGVkLXByaW50YWJsZQ0KDQpQbGFpbiB0ZXh0IG1lc3NhZ2UuDQoNCi0t PT09PT09PT09PT09PT09PT09PT09XzI1NzIxMjg9PV8uQUxUDQpDb250ZW50 LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD0iaXNvLTg4NTktMSINCkNvbnRl bnQtVHJhbnNmZXItRW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KSFRN TCBtZXNzYWdlLg0KDQotLT09PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4 PT1fLkFMVC0tDQoNCi0tPT09PT09PT09PT09PT09PT09PT09XzI1NzIxMjg9 PV8NCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcGRmOyBuYW1lPSJmaWxl MS5wZGYiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQNCkNv bnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZpbGVuYW1lPSJmaWxl MS5wZGYiDQoNCkVuY29kZWQgUERGIEZpbGUNCg0KLS09PT09PT09PT09PT09 PT09PT09PT1fMjU3MjEyOD09Xw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlv bi9wZGY7IG5hbWU9ImZpbGUyLnBkZiINCkNvbnRlbnQtVHJhbnNmZXItRW5j b2Rpbmc6IGJhc2U2NA0KQ29udGVudC1EaXNwb3NpdGlvbjogYXR0YWNobWVu dDsgZmlsZW5hbWU9ImZpbGUyLnBkZiINCg0KRW5jb2RlZCBQREYgRmlsZQ0K DQotLT09PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4PT1fLS0NCg0K --------------Boundary-00=_OJ77FSU6GIYH19OQGGJR Content-Type: text/plain; charset="iso-8859-1"; name="folder" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="folder" VGhpcyBpcyB0aGUgdGVtcGxhdGUgZm91bmQgaW4gdGhlIEtNYWlsIGZvbGRl cgoKU3RhbmRhcmQgTWFpbCBIZWFkZXJzOgpDb250ZW50LVR5cGU6IG11bHRp cGFydC9taXhlZDsKICBib3VuZGFyeT0iPT09PT09PT09PT09PT09PT09PT09 XzI1NzIxMjg9PV8iClgtU3RhdHVzOiBPCgotLT09PT09PT09PT09PT09PT09 PT09PV8yNTcyMTI4PT1fCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L2FsdGVy bmF0aXZlOwoJYm91bmRhcnk9Ij09PT09PT09PT09PT09PT09PT09PV8yNTcy MTI4PT1fLkFMVCIKCi0tPT09PT09PT09PT09PT09PT09PT09XzI1NzIxMjg9 PV8KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJpc28tODg1 OS0xIjsgZm9ybWF0PWZsb3dlZApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5n OiBxdW90ZWQtcHJpbnRhYmxlCgpQbGFpbiB0ZXh0IG1lc3NhZ2UuCgotLT09 PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4PT1fCkNvbnRlbnQtVHlwZTog dGV4dC9odG1sOyBjaGFyc2V0PSJpc28tODg1OS0xIgpDb250ZW50LVRyYW5z ZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlCgpIVE1MIG1lc3NhZ2Uu CgotLT09PT09PT09PT09PT09PT09PT09PV8yNTcyMTI4PT1fCgotLT09PT09 PT09PT09PT09PT09PT09PV8yNTcyMTI4PT1fCkNvbnRlbnQtVHlwZTogYXBw bGljYXRpb24vcGRmOyBuYW1lPSJmaWxlMS5wZGYiCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IGJhc2U2NApDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRh Y2htZW50OyBmaWxlbmFtZT0iZmlsZTEucGRmIgoKRW5jb2RlZCBQREYgRmls ZQoKLS09PT09PT09PT09PT09PT09PT09PT1fMjU3MjEyOD09XwpDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL3BkZjsgbmFtZT0iZmlsZTIucGRmIgpDb250 ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBiYXNlNjQKQ29udGVudC1EaXNwb3Np dGlvbjogYXR0YWNobWVudDsgZmlsZW5hbWU9ImZpbGUyLnBkZiIKCkVuY29k ZWQgUERGIEZpbGUKCi0tPT09PT09PT09PT09PT09PT09PT09XzI1NzIxMjg9 PV8tLQoK --------------Boundary-00=_OJ77FSU6GIYH19OQGGJR--
I am having the same problem and what seams odd to me is that something is altering the source of the message. Viewing the message source the structure of the email is... ... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_5214437==_" --=====================_5214437==_ Content-Type: multipart/alternative; boundary="=====================_5214437==_.ALT" --=====================_5214437==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Text Content... --=====================_5214437==_ Content-Type: text/html; charset="us-ascii" HTML Content... --=====================_5214437==_ --=====================_5214437==_ Content-Type: application/octet-stream; name="Helpdesk outline1.xls"; x-mac-type="584C5334"; x-mac-creator="5843454C" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Helpdesk outline1.xls" The attatchment --=====================_5214437==_-- The boundary after the HTML message should have had .ALT-- after it and when I view the source from the Mozilla mail reader it does. Is this a broken format or is kmail breaking it? Or maybe Mozilla mail is fixing it?
same missing feature *** This bug has been marked as a duplicate of 6710 ***