Closed Bug 360857 Opened 18 years ago Closed 14 years ago

text/html part with Content-Location fails to resolve cid: URLs of subsequent image parts (T-Mobile picture mail)

Categories

(MailNews Core :: MIME, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 689964

People

(Reporter: epp, Unassigned)

Details

Attachments

(4 files)

User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.0.9pre) Gecko/20061114 SeaMonkey/1.0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.8.0.9pre) Gecko/20061114 SeaMonkey/1.0.6 When SeaMonkey (both Windows XP and Linux) opens a picture e-mail message sent from a T-Mobile camera phone, the message body only displays the image placeholders, it will not display the images. In regards to Windows, Outlook Express displays the same e-mail perfectly. Reproducible: Always Steps to Reproduce: 1.Load in picture e-mail sent from a T-Mobile camera phone 2. 3. Actual Results: SeaMonkey will only display image placeholders in the e-mail body. Expected Results: SeaMonkey should have displayed the message as an HTML message with all images. Problem discovered in both the Windows and Linux releases of SeaMonkey.
Keywords: mail1
The e-mail in question is sent via a T-Mobile USA camera phone.
Do you have loading of external images enabled (may be a privacy risk)?
Can you provide the source of the message, please? Save it as a .EML file and attach it to this bug, using the Create New Attachment link above. And don't add keywords to bugs, please, until you know what you're doing.
Keywords: mail1
Attached file Source of HTML message not displayed (deleted) —
In reply to Comment #2 (Frank), the Image Permissions Policy is set to "Accept All Images". This appears to be the default as I have never looked at that setting prior to this. Thanks for asking. In response to Comment #3: I have been reporting bugs to this organization for more than three years now, I know what I am doing. If I feel a Keyword is warranted, I add it. "mail1" is for mail-related bugs, I added "mail1". If I am not sure whether a Keyword is required, I leave it out. The requested file is attached to this report.
we don't use those mail1-5 keywords, really. We used to use them a long time ago.
David - thanks for the comment. To better serve the users of Bugzilla, perhaps the admins ought to consider removing those particular keywords (if it's possible), so they cannot be used. This particular issue is a strange one. All other HTML e-mails received (from trusted sources) will display perfectly, except these.
Attached file Mailbox with messages (deleted) —
The text/html part has a Content-Location header. Removing that makes the message display. The attachment contains the data from the previous attachment, adds usable mail headers, and duplicates the message; the second instance is the same as the first, except with the Content-Location header from the first part removed.
Reproduced with TB 2b1-1111 and SM 1.5a-0925, Win2k.
Assignee: mail → nobody
Status: UNCONFIRMED → NEW
Component: MailNews: Main Mail Window → MailNews: MIME
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: mime
Summary: Picture e-mail sent from a T-Mobile phone does not display → text/html part with Content-Location fails to resolve cid: URLs of subsequent image parts (T-Mobile picture mail)
Version: unspecified → Trunk
I sent another picture message to my ISP e-mail address. Since first reporting this bug, the Content-Location header is no longer part of the e-mail headers, but SeaMonkey still does not display such messages. I sent another test picture message, but used KMail in Linux to retrieve and view the message. KMail (once I selected to display HTML) displayed it perfectly.
(In reply to comment #10) > Since first reporting > this bug, the Content-Location header is no longer part of the e-mail headers, > but SeaMonkey still does not display such messages. OK: then we need a sample of the mail that's breaking.
Attached file Sample header (deleted) —
The Content-Location header has returned, the From and To addresses, and mail server headers were removed. SeaMonkey 1.1.2 for both Windows and Linux still doesn't display this HTML (or picture) e-mail sent from T-Mobile USA.
With this build: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7pre) Gecko/20070801 SeaMonkey/1.1.3 The multimedia message will appear correctly when the following header is present in the e-mail headers: multipart/related; boundary="----=_Part_1809120_26240823.1186101441739"; type="text/html" However, when this header is present: multipart/related; type="text/html"; boundary="----=_Part_1747326_270985.1186102080430" all that is displayed are the image placeholders.
I am using SeaMonkey 1.1.5 for Linux. When a picture message was sent via e-mail using a Samsung phone on T-Mobile, SeaMonkey Mail correctly displayed the e-mail with all graphics included. When the bug was opened, the phone used to send a picture message was a Nokia.
This is still an issue with SeaMonkey 1.1.9.
Problem may not be SM related. When a picture message is sent using a Samsung mobile phone on T-Mobile, the e-mail displays correctly with all graphics. My guess is that this is an issue with the Nokia phone software, closing bug.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
Issue also occurs with MMS (picture mail) from LG phones as well. SeaMonkey 2.0.5 for Windows.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This is not specific to any one particular brand of mobile phone, but occurs if sent via T-Mobile. Both POP3 and IMAP accounts will not display the images. Occurs with SM and TB for Linux as well.
(In reply to comment #14) > With this build: > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.7pre) Gecko/20070801 > SeaMonkey/1.1.3 > The multimedia message will appear correctly when the following header is > present in the e-mail headers: > multipart/related; boundary="----=_Part_1809120_26240823.1186101441739"; > type="text/html" > However, when this header is present: > multipart/related; type="text/html"; > boundary="----=_Part_1747326_270985.1186102080430" > all that is displayed are the image placeholders. AFAIR, above issue was already resolved. With both parameter order in Content-Type header, problem of this bug could be observed with Tb 3.1 for your test mail attached to comment #12, and problem of this bug disappered by removing Content-Location: header of text/html part. As Mike Cowperthwaite said in Comment #8, and as Mike changed bug summary, culprit is Content-Location: header of text/html part in multipart/related. Problem of this bug could still be observed with Tb 3.1. Although Mozilla's processing of wrong Content-Location: looks wrong, and Mozilla may have failed to do proper resolution of "cid:" url in <img src>, main culprit is wrong usage of Content-Location: header by mail sender. As RFC usually never defines action of MUA for RFC violation, any result can be said correct if RFC violation exists. See RFC 2557 for MHTML. > http://tools.ietf.org/html/rfc2557
Content-Location is no longer listed in the headers. Even without that now, the messages do not display. After trying other e-mail programs in Linux, Evolution was the only one that displayed the message as expeected, with all graphics displayed. Claws was the other one used (aside from TB and SM.)
(In reply to comment #21) > Content-Location is no longer listed in the headers. > Even without that now, the messages do not display. If so, it's absolutely different problem from this bug. Open separate bug, with attaching mail data(not paste), with screen shot if required. Please keep "one problem per a bug".
Will close this and open new bug.
Status: REOPENED → RESOLVED
Closed: 16 years ago14 years ago
Resolution: --- → WORKSFORME
My mistake. When I sent another test message, Content-Location is in fact, still present. I will attach a new group of headers from the test message.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Source of test HTML message not displayed with SeaMonkey and Thunderbird (Windows and Linux versions).
(In reply to comment #20) Is it possible for SM/TB to "ignore" the Content-Location header in some way? This bug was opened almost four years ago. The solution appears to be here (per Mike's comments above), so can something be implemented, perhaps an item in prefs.js (about:config) (for SM, at least) to ignore/strip that particular header?
With an AOL/AIM IMAP account, such a message will display correctly with SeaMonkey (currently using 2.0.6). With POP-based accounts and also with an IMAP account created via AOL's former Tunome service, the image placeholders continue to be displayed.
Closing this bug, only affects certain phone models.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
We can not say this bug is absolutely INVALID. Fotunately, Bug 689964 has been opened for same issue. Duping to clear/crisp Bug 689964, for ease of tracking.
Resolution: INVALID → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: