488987 - Embedded Images in html messages displaying as broken links (text/html + cid: url in <img> + Content-Id: + image/xxx under multipart/mixed instead of correct multipart/related)

Status: RESOLVED DUPLICATE of bug 61815

(MailNews Core :: MIME, defect)

Description

[Paul Kinzelman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Build Identifier: version 2.0.0.21 (20090302)

I now and then receive email with embedded pictures which I can view
just fine.

But sometimes I receive email with embedded pictures which display as a
broken link (little red diamond in the space in the upper left corner).
The pictures are also attached, and I can view them by double-clicking
on them but not in-line with the message.

Here's an example of the HTML source which would seem to point to one of
the embedded files (I've inserted CR's here so it's easier to read). It
would appear that the "src=" is the link into the embedded hex area and
the src= string matches the "Content-Id:" string. But Tbird can't seem
to match it up.

<DIV>

<P class=ececececmsonormal><FONT face="Times New Roman" color=black
size=3><SPAN style="FONT-SIZE: 12pt; COLOR: black"><BR><IMG
id=EC_MA11.1238564048 height=146
src="cid:[e-mail]" width=216
border=0></SPAN></FONT></P></DIV>

<P class=ececececmsonormal style="TEXT-ALIGN: center"
align=center><FONT face="Times New Roman" color=black size=3><SPAN
style="FONT-SIZE: 12pt; COLOR: black">Washtub wringers</SPAN></FONT>
</P>
--------------------------------------
Here's an example of the source of the message in the area of one of the
attached pictures (some are .jpeg, some are .gif):

(hex of the previous picture)ThGx+glFFFYnWFFFFABRRRQB/9k=
------=_Part_2789_9748641.1240006437576
Content-Type: image/jpeg; name="ATT00010.jpeg"
Content-Transfer-Encoding: base64
Content-Id: <[e-mail]>

/9j/4AAQSkZJRgABAgAAZABkAAD (etc. for the hex of the next picture)

I searched and found nothing in buzilla. I also posted in the support forum and a couple of people suggested it might be a bug so I'm posting it here.

Reproducible: Always

Steps to Reproduce:
1. Preview or open the message, or save and double-click on it, same thing happens
2. Happens every time on some messages, but not on others.
3.
Actual Results:  
Broken links

Expected Results:  
I expected to see the pictures.

The example email .eml file I have is 1.5MB and I'll keep it around and will email it to anybody upon request.

Comment 1

[Joe Sabash [:JoeS1]]

I think this may be because there is no Content-Disposition: attachment; in the message. A smaller testcase than 1.5 meg would be better, (don't know if my isp will even handle that) but you could try to send it.
My email address in the cc field is correct.

Comment 2

[Joe Sabash [:JoeS1]]

Thanks Paul, for your follow-through in supplying the example mail.
Indeed Thunderbird cannot render attachment content (inline) in the style that was composed in OE.
Don't know about the actual RFC issues here, but I think that doesn't matter much.
OE sends...TB can't read it. Standards or not, that's a problem.

This is most likely a problem in LibMime.

Confirming.With a minimal testcase to follow.

Comment 3

[Joe Sabash [:JoeS1]]

Attachment: The first image was inserted with TB

The first attachment was inserted with TB
The second embedded image is from the original source
Note that TB requires a content-Id in the mime part OE does not

Comment 4

[Paul Kinzelman]

UR welcome! Yes, standards or not, it should work. Reminds me of a bit of interesting history, I worked for DEC many years ago, and when the PDP-11/34 came out (~1975), none of the peripherals that were being used on previous PDP-11's would work because the /34 was the first one that actually implemented the Unibus spec accurately. :-)

Comment 5

[Magnus Melin [:mkmelin] (away until July 8)]

The img giving problms is
<img id="EC_MA2.1238564048" src="cid:[e-mail]" 

There's no [e-mail] part so I don't know how it's supposed to show anything...

Comment 6

[Joe Sabash [:JoeS1]]

(In reply to comment #5)
> The img giving problms is
> <img id="EC_MA2.1238564048" src="cid:[e-mail]" 
> 
> There's no [e-mail] part so I don't know how
> it's supposed to show anything...

I tried to make a minimal test case using TB editor, and it changed some parts that I didn't want changed.

In the original here is the image tag:
<IMG id=EC_MA1.1238564048 height=96 src="cid:[e-mail]" width=100 border=0>

And here is the related part:
Content-Type: image/jpeg; name="ATT00000.jpeg"
Content-Transfer-Encoding: base64
Content-Id: <[e-mail]>

Note that the cid: referenced is correct.
(except it doesn't have the Gecko "part" prefix.)

I'll try to distill down a minimal test case, but will have to use a text-editor for that (or..UGH fire up OE)

Comment 7

[Joe Sabash [:JoeS1]]

OK, I have verified that the original EML with the cid attributes as stated above, works fine in MS outlook express 6.00.XXXX

TB just shows a "placeholder"

I think interoperability is important to the future of TB.

I'm still trying to get a minimal testcase generated with OE 6
But admittedly, I'm not too proficient with it.

Comment 8

[Joe Sabash [:JoeS1]]

Attachment: Single image embed

Added small testcase.eml which renders the image inline with Outlook Express and just a placeholder in TB (sorry about the many extra p and div tags, they come at no extra charge with OE) :)

Comment 9

[Joe Sabash [:JoeS1]]

The cid protocol handler in mime has been broken for a very long time.
xref https://bugzilla.mozilla.org/show_bug.cgi?id=154836#c9
For this particular case of cid: bustage I see the following in the error console:

Security Error: Content at mailbox:///C:/TBtools/broken-image.eml?type=application/x-message-display&number=0 may not load or link to about:blank.

It's really not a security issue, we (TB) just don't fully understand cid's

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to Joe Sabash from comment #8)
> Single image embed

Mail is multipart/mixed mail.
> Content-Type: multipart/mixed; 

What should mailer do when multipart mixed is:
   Show parts in order requested by mail sender.
"Set of html+embed images" should be encapsuled in multipart/related.

Even though Content-Disposition: & Content-Id: is never prohibited in any mime part, I believe definition of highest level multipart/mixed, multipart/related, multipart/alternative superceeds rules for lower level Content-Disposition: & Content-Id: & cid: url.

MS shows multipart/mixed as if multipart/related as he wants, and shows multipart/related as if multipart/mixed as he wants.
And MS generates mail of multpart/related with ATTACHMENT such as pdf under multipart/related, even though RFC for multipart/related(mhtml) was created by MS.
So, many mail applications generate multipart/related mail which should be multipar/mixed, and mulipart/mixed mail which should be multipart/related.

For non-referred/non-displayable part in multipart/related : See bug 674473

For cid: url resolution and showing of image in multipart/mixed as embed image of html (i.e. ignore definition of multipart/mixed as MS does, or introduce exception in definition of multipart/mixed to support html+imbed image+cid: url+Content-Id: in multpart/mixed) : 
  Because MS and some mail applications developed by programmers who don't
  respect mail RFCs frequently sends such mail, it's rquested in some bus.
Needed improvement in "View/Message Body/All Body Parts" mode is same as this request.
  Because "All Body Parts" shows any multipart/xxx as if multipart/mixed
  in order to show any part in malformed multipart mail and mime-part,
  multipart/related part is also shown as if multipart/mixed,
  then same phenomenon as this bug occurs.

Comment 11

[Thomas D. (:thomas8)]

A little house-cleaning in support of this RFE!
-> duping