Bug 43479

Summary: Alt nested in MIME message does not dislay
Product: [Unmaintained] kmail Reporter: Kevin J. Miller <kevin.j.miller>
Component: mimeAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED DUPLICATE    
Severity: normal    
Priority: NOR    
Version: 1.4.1   
Target Milestone: ---   
Platform: RedHat Enterprise Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Kevin J. Miller 2002-06-04 01:41:00 UTC
(*** 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)
Comment 1 Michael H 2002-06-04 04:17:48 UTC
-----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-----
Comment 2 Kevin J. Miller 2002-06-04 20:28:36 UTC
--------------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--
Comment 3 Dave Banks 2002-12-03 22:22:43 UTC
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?
Comment 4 Stephan Kulow 2003-09-26 07:44:30 UTC
same missing feature 

*** This bug has been marked as a duplicate of 6710 ***