User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: 2.0.0.15pre (20080611) Thunderbird shows an additional attachment or one attachment when there is really no attachment in email message. Attachment name appears as "part 1.5" or (part 1.x.x). When I view MIME MESSAGE SOURCE, as there is no attachment in message. Reproducible: Always Steps to Reproduce: 1. Send an email which should have top most content-type: multipart/mixed 2. Main body should have some image references (cid:<cid>) but those image should be appear as "INLINE" in message. 3. There should be one additional and separate attachment , say "resume.doc" 4. Now view received email in Thunderbird. Actual Results: It will show one of the image as attachment with "resume.doc" attachment. Expected Results: "resume.doc" ONLY should appear as attachment.

This you can use as a test case to send and view in Thunderbird. If something is going wring in MIME , please let me know.

Agree on that kinda confusing for regular John.

David, can you confirm if this is by design?

we generally show all attachments in the attachment pane, not just external attachments, to make it easier to save them, etc. Multi-part related is particularly challenging to handle, iirc - it doesn't seem like we're showing all the images as attachments in your test case, so something definitely is wrong. I agree that showing part 1.5 is not helpful.

I'd love to not show "Part 1.x" bits which seem to be junk (either just whitespace, or sometimes dashes?), even though I understand that they may be junk caused by malformed emails.

Duplicate of bug 436555?

bug 436555 is much more general. We could arbitrarily decide not to show attachments that have no real name, that we've cobbled together a name using the mime part number for. I think we'd need to pass that information through the handleAttachment method, and the listener (in this case nsMsgHdrViewOverlay.js) can decide what they want to do with the attachment (I would *not* skip the notification from libmime, because other mime listeners might still want to know about the attachment). The listeners have no way of knowing if the part is junk, and I'm not convinced that libmime really can tell either. In this bug, for example, the part looks pretty real to me.

Filer Update ========== I found the reason with one of the email this issue. If there is any BODY part (say, image/gif) but the corresponding Content-Id is not being referenced in main message body then Thunderbird showing that BODY part as attachment. For detail desc. I uploaded a https://bugzilla.mozilla.org/attachment.cgi?id=324741 ----------- Content-type: image/gif Content-Transfer-Encoding: base64 Content-ID: <4736426> Content-Disposition: inline R0lGODlhCwDIAIABANLYsP8A/yH5BAEAAAEALAAAAAALAMgAAAJCjI+JwBrcFoxmwmNvzWDzxzWh OJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1qt8cCADs= =========================================== This content id 4736426 is not being referenced in main MIME message body and that's the reason Thunderbird shows that an attachment. Ideally to have an extra body part i.e. which is not being referenced, looks correct / per RFC.

More findings : ================ The issues because below line does not seem work with Thunderbird and then it shows corresponding Content-Id as attachment. <td style="background-image:url(cid:3972145);background-repeat:no-repeat" width="11" height="11"> Can anyone comment on above scenerio, if required I can provide MIME source of that problematic message.

Duplicate of bug 154836 ? See https://bugzilla.mozilla.org/show_bug.cgi?id=154836#c11 For the CID part

Just to be clear: Comment #4 and comment #5 I believe are missing the point entirely. That being, that viewing the testcase in "original html" TB is unable to deal with the specific tag <td style=3D"background-image:url(cid:473= 6426);background-repeat:no-repeat" width=3D"11" height=3D"11"> As a matter of fact, styled background images, either with inline styles or stylesheets are completely ignored. Well I shouldn't say completely ignored, since TB doesn't know what to do with the inline content, it shows as an attachment. The fix for this particular problem is clearly indicated in bug 154836.

marking dup of bug 154836 bug 388562 also