MS Outlook seems to be using the content-location for embedding image in a multipart related message instead of the traditional content-id. This is defined bu RFC 2110. Mozilla wont display surch image inline but add them to the attachment list.

The attachment to this bug has, for example (reformatting mine): <IMG src="1_multipart?2_clip_image002.jpg" height=302 width=254 v:shapes="_x0000_i1025"> referring to Content-Type: image/jpeg; name="clip_image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <00c301c47e6e$de76b380$a8595544@selfqq74yfzdys> Content-Location: 1_multipart%3F2_clip_image002.jpg Now xref bug 244433; attachment 72795 [details] has: <IMG src="1on1Ad.gif" alt="Weather One-on-One" border="0"> referring to Content-Type: image/gif Content-Transfer-Encoding: base64 Content-Disposition: attachment Content-Location: 1on1Ad.gif I don't know which of these headers might be causing a difference, but that attachment does display its images inline (unless the HTML Sanitizer -- Simple HTML -- is used for display, which is the referenced bug).

In the firt case (the one attached to this bug, the URL in the content-location is escaped while itsn't in the mail content nor in the second example (bug 244433). Maybe that's the problem!

my bad, we already support content-location for related object, and this since the beginign of the project. My memory become weak!! Anyway, there is a bug with the attached mesage which prevent the images to be displayed inline! We need to debug the function MimeMultipartRelated_output_child_p()...

... or function flush_tag(), both in mailnews/mime/src/mimemrel.cpp

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.