Open Bug 689964 Opened 13 years ago Updated 2 years ago

Content-Location header makes attachments show as broken

Categories

(Thunderbird :: Message Reader UI, defect)

Product:
Thunderbird
Component:
Message Reader UI
Version:
7 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

People

(Reporter: bugzilla_mozilla, Unassigned)

References

(
URL
)

Details

Attachments

(2 files)

Saved message with the offending header still in it.
134.41 KB, text/plain
Details
Same message with Content-Location header removed from HTML part. This one shows up correctly.
134.38 KB, text/plain
Details
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110902133214 Steps to reproduce: Sent self a photo from (lousy, archaic) LG420G TracFone. Actual results: Message shows up as a table of broken images; no attachments are listed. Expected results: Images should appear inline, or listed as attachments.
See Also: → 256421
See Also: → 360857
360857 was closed for apparent lack of pervasiveness of the problem; but searching around leads me to believe that this problem applies to more than just phones. Also, new applications of the Content-Location header continue popping up.
Attachment #563088 - Attachment mime type: application/octet-stream → text/plain
Attachment #563090 - Attachment mime type: application/octet-stream → text/plain
Linkify referred bugs : Bug 256421, Bug 360857 (A) Content-ID: of text/html under multipart/related is seen in both Bug 360857 and your case. > Bug 360857 > Content-ID: <0000> > Content-Location: p.smil > Your case > Content-ID: <0000> > Content-Location: GCGP.smil (B) cid: url used in text/html is same in both Bug 360857 and your case. > <img src=3D"cid:tmobilespace.gif (snip) So, your case is probably same phenomenon on mail of same structure from same mail sender as that bug, which was unfortunately closed as invalid by bug opener. Although Content-Location: <0000> in the text/html part is semantically wrong, the Content-Location: in text/html part is not explicitely prohibited by RFCs and is syntactically perhaps not wrong("<" & ">" should be escaped because of uri?) And, because Content-Location: and Content-ID: is for reference from pointer like <img sc="...">, cid: url resolution in text/html part by mailer is better not affected by not-absolutely-correct Content-Location: <0000> of the text/html part. Confirming, as mcow@well.com did on that bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Just want to confirm that this problem is not limited to Windows. The same (as originally reported in bug 360857) also occurs with Linux (both 32 and 64-bit) versions of both the latest Thunderbird (9.0.1) and SeaMonkey (2.6.1). With some phone brands (e.g. Samsung, the resulting picture message sent from the phone is displayed correctly with all images, but with another phone (LG), the e-mail displays the blank placeholders instead. This is via T-Mobile USA.
This is not limited to T-Mobile USA. Also occurring from metroPCS. SeaMonkey 2.7 Beta 4 (based on Firefox 10?) only displays the text sent with the multimedia message, not the image(s) or the placeholder(s). ------=_Part_2031963_10719891.1327015255467 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-ID: <0000> Content-Location:IMMS.SMIL Content-Disposition: inline <html> <head> <meta http-equiv=3D"Content-Language" content=3D"en-us"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-1= 252"> <meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4.0"> <meta name=3D"ProgId" content=3D"FrontPage.Editor.Document"> <title>New Page 1</title> </head>
From a T-Mobile USA phone, in this instance SeaMonkey only displayed empty placeholders. ------=_Part_3100134_9827541.1327159529529 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-ID: <0000> Content-Location: GCGP.smil Content-Disposition: inline <html> <head> =09=09<title>T-Mobile</title>=20 =09=09<!-- =09=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =09=09If you can read this text, but much of the message below seems unread= able, you might be using an e-mail program that does not work with HTML. =09=09=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D--> =09=09<style type=3D"text/css"> <!-- =09=09.footer { =09=09=09font-family: Arial, Helvetica, sans-serif; =09=09=09font-size: 11px; =09=09=09color: #555555; =09=09=09text-decoration: none; =09=09} =09=09.normal { =09=09=09font-family: Arial, Helvetica, sans-serif; =09=09=09font-size: 10px; =09=09=09color: #555555; =09=09=09text-decoration: none; =09=09} =09=09--> =09=09</style> =09</head> =09<body marginwidth=3D"0" marginheight=3D"0" leftmargin=3D"0" topmargin=3D= "0" bgcolor=3D"#ffffff"> =09=09<table border=3D"0" width=3D"600" cellspacing=3D"0" cellpadding=3D"0"= > =09=09=09<tr> =09=09=09=09<td width=3D"20" rowspan=3D"8"><img src=3D"cid:tmobilespace.gif= " width=3D"20" height=3D"20"></td> =09=09=09=09<td width=3D"600" colspan=3D"2"><img src=3D"cid:tmobilespace.gi= f" width=3D"600" height=3D"20"></td> =09=09=09=09<td width=3D"20" rowspan=3D"8"><img src=3D"cid:tmobilespace.gif= " width=3D"20" height=3D"20"></td> =09=09=09</tr> =09=09=09<tr> =09=09=09=09<td width=3D"600" colspan=3D"2"><img src=3D"cid:dottedline600.g= if" width=3D"600"></td> =09=09=09</tr> =09=09=09<tr> =09=09=09=09<td width=3D"370"> =09=09=09=09 <!-- presentation starts here --> =09=09=09=09 <table border=3D0><tr><tr><td colspan=3D1 align=3D"Left"><IMG= align=3Dbaseline alt=3D"" border=3D0 hspace=3D0 src=3D"cid:97" title=3D"ri= ght-click and choose Save Picture As... to save the image"></td></tr></tr><= TR><TD width=3D350 colSpan=3D1><IMG height=3D30 src=3D"cid:tmobilespace.gif= " width=3D350></TD></TR><TR><TD width=3D350 colSpan=3D4><IMG src=3D"cid:do= ttedline350.gif" width=3D350></TD></TR><TR><TR><TD width=3D350 colSpan=3D4= ><IMG height=3D30 src=3D"cid:tmobilespace.gif" width=3D350></TD></TR></tab= le> =20 =09=09=09=09 <!-- presentation ends here --> =09=09=09=09</td> =09=09=09=09<td width=3D"240" bgcolor=3D"#f2f2f2"><BR></td> =09=09=09</tr> <tr> <td width=3D"600" colspan=3D"2"><img src=3D= "cid:tmobilelogo.gif" width=3D"600" height=3D"105"></td> </tr> </span></td> </tr> <tr> =09=09=09=09<td width=3D"600" colspan=3D"2"><img src=3D"cid:tmobilespace.gi= f" width=3D"600" height=3D"40"></td> </tr> </table> </body></html>
Malformed "Content-Location: <0000>" like one didn't exist in mail. Sorry for my confusion. (In reply to Eric F from comment #0) > Created attachment 563088 [details] > Saved message with the offending header still in it. (1) Surrounding Content-Type: multipart/related doesn't have Content-Location. (2-1) Content-Type: text/html part has Content-ID: <0000> Because this is for refer from other than this text/html part, this shouldn't produce any problem in cid:URL resolution for this HTML. An <img> in HTML has cid:2 (2-2) An image/jpeg in same multipart/related has next header. Content-Type: image/jpeg; name=P09-17-11_12.07.jpg Content-ID: <2> Content-Location: P09-17-11_12.07.jpg (3) Due to existence of Content-Location: P09-17-11_12.07.jpg, or due to different string in Content-Location: from Content-Id:, cid resolution by Tb fails to or doesn't associate cid:2 to "Content-Id: <2>". I don't know detailed spec of cid: resolution in such case. RFC says next only, If cid: URL resolution reached absolutely same URL by resolution using Content-Id: and Content-Location:, use Content-ID:(scope is mail data only) instead of Content-Location:(scope can be out side of mail, e.g. Web site), although I think concept of cid:URL and Content-ID: requests cid: URL resolution with Content-Id: in this case. (In reply to Edward from comment #6) > ------=_Part_2031963_10719891.1327015255467 > Content-Type: text/html > Content-ID: <0000> > Content-Location:IMMS.SMIL If I understand RFC correctly, Content-Location:IMMS.SMIL in this case is similar to <base> of HTML in URL resolution. So, "what should be" depends on cid: URL in HTML and Content-ID:(and/or Content-Location:) of embed image. Without such data, nothing can be said on this case. As for Content-Location:IMMS.SMIL of text/html part, I think it can be called "malformed mail", if the Content-Location:IMMS.SMIL header is placed without understading RFC. No space between "Content-Location:" and "IMMS.SMIL" may produce other problem. (In reply to Edward from comment #7) > ------=_Part_3100134_9827541.1327159529529 > Content-Type: text/html > Content-ID: <0000> > Content-Location: GCGP.smil By te way, please don't paste long mail data. Save it in .eml and attach the file to this bug, as bug opner did. "Content-Location: GCGP.smil" for text/html part case. > cid:tmobilespace.gif, cid:tmobilespace.gif, cid:tmobilespace.gif, cid:dottedline600.gif > cid:97 > cid:tmobilespace.gif, cid:dottedline350.gif, cid:tmobilespace.gif, id:tmobilelogo.gif, cid:tmobilespace.gif, Because similar name to original report, same "Contentent-Id: <97> & Content-Location: something for image/xxx" is suspected, but mail sample without actual header data or information on actual header is useless, because problem is relevant to cid:url resolution when Content-Location: header is perhapes placed by mail application developer without understanding RFC.
Rule of cid: URL resolution is stated im RFC 2557 section-8.2 . http://tools.ietf.org/html/rfc2557#section-8.2 > 8.2 Resolution of URIs in text/html body parts To bug opener and problem reporters in this bug: What is correct behavior based on the RFC on the combination of cid: URL, Content-Location: header, and Content-ID: header which you provided? If provided message header is absolutely valid based on RFC, and if this bug is Tb's fault, what is Tb's RFC violation of which part in the RFC? (In reply to Eric F from comment #0) > Expected results: > Images should appear inline, or listed as attachments. "listed as attachment" part may be achieved by bug 674473, if the image/jpeg part with Content-Location: and Content-Id: is considered "non-reffered part" after fix of bug 674473.
If I send a picture (MMS) e-mail from the phone to an IMAP e-mail account and view the e-mail using either Thunderbird or SeaMonkey, I see empty placeholders with most accounts (e.g. GMX, mail.com.) If viewing through an AOL Mail account, it generally will display the images, but if using one of the former Tunome domains AOL previously offered for e-mail (e.g. mcom.com, games.com, etc.), the empty placeholders are still seen using TB or SM. If I leave the message on the server and then log into the respective web site to view the e-mail, all images appear as expected. But when testing with two different phone models, the e-mail sent from a Samsung phone displayed all images, but when sending from an LG phone (same 420G TracFone on T-Mobile as Eric, as well as an LG GS170 direct from T-Mobile), they did not. Looking at the two attachments Eric posted from the TracFone, T-Mobile is the carrier.
Also, if the MMS message is sent to a POP3 account, the same empty placeholders are also seen with TB and SM.
Problem also exists with Linux, both 32- and 64-bit. Looking at this bug, as well as bug 360857 (which was one I filed almost six (6) years ago, BTW), as well as bug 606850, does anyone have a reason why this problem has not been fixed after all this time?
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: