The attached mail doesnt render anything in the body or give an attachment in Mozilla. Netscape shows a attachment. the mail: From: firstname.lastname@example.org Subject: ****SPECIAL REPORT**** Content-Type: multipart; boundary="_NextPart_0000904A-00000708-03D46548-3049" Date: Fri, 16 Feb 2001 10:19:22 GMT --_NextPart_0000904A-00000708-03D46548-3049 Content-Type: text/plain Content-Transfer-Encoding: 7bit Get a brand new, clean, --_NextPart_0000904A-00000708-03D46548-3049--
Ducarroz, isn't this a DUP of the bug that I filed on you, that has 2 multipart attachment messages that won't show in the message pane?
I am thinking of bug 74649, specifically.
This is not a dup of bug 74649. Just looks like we don't know what to do with a message of type "multipart". We should have have "multipart/..."
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.7
Confirmation, if I replace the content type to "multipart/mixed", then the message body is correclty displayed inline.
Jean-Francois, anything we can do about this?
Target Milestone: mozilla0.9.7 → mozilla0.9.9
probably. We should be able to handle bad multipart type by using by default a multipart/mixed.
RFC<don't recall number> explicitly says that default subtypes are not allowed :-) But if you're interested, comparison for "multipart/" literal is happen in mimei.cpp and mimemsg.cpp (as well as in eudora and outlook import code, but these are not count) I think that mimei.cpp is relevant here
Created attachment 63486 [details] [diff] [review] treat "multipart" content-type as "multipart/mixed" Should we do similiar thing for "message" content type?
Moving out, but since we have a patch, if it can get reviewed, we can get it in.
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
Comment on attachment 63486 [details] [diff] [review] treat "multipart" content-type as "multipart/mixed" just after the code you are patching, there is the following code: if (!clazz && !exact_match_p) /* Treat all unknown multipart subtypes as "multipart/mixed" */ clazz = (MimeObjectClass *)&mimeMultipartMixedClass; Looks like we already have the logic to thread unknown/invalid multipart as multipart/mixed but for some reason this code doesn't seems to work. I would rather seeing you fixing the existing one that adding new code. Thanks
Attachment #63486 - Flags: needs-work+
Comment on attachment 68307 [details] [diff] [review] patch, v2 >- else if (!nsCRT::strncasecmp(content_type, "multipart/", 10)) >+ else if (!nsCRT::strncasecmp(content_type, "multipart", 9)) That's good >- if (!nsCRT::strcasecmp(content_type+10, "alternative")) >+ if (!content_type || content_type != '/') >+ ; // do nothing >+ else if (!nsCRT::strcasecmp(content_type+10, "alternative")) We don't need this part of the fix as we already have a fall through for case we don't recognize! do that and I will give you my ok...
Attachment #68307 - Flags: needs-work+
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
QA Contact: esther → mime
Product: Core → MailNews Core
5 years of bug and...
No, 5 years from last message. 12 years! Why don't close this?
Good point. No one else has provided any other message which has such an equally malformed MIME type, so there's no reason to fix it.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.