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)
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.
The e-mail in question is sent via a T-Mobile USA camera phone.
Comment 2•18 years ago
|
||
Do you have loading of external images enabled (may be a privacy risk)?
Comment 3•18 years ago
|
||
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
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.
Comment 6•18 years ago
|
||
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.
Comment 8•18 years ago
|
||
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.
Comment 9•18 years ago
|
||
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
Reporter | ||
Comment 10•18 years ago
|
||
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.
Comment 11•18 years ago
|
||
(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.
Reporter | ||
Comment 12•17 years ago
|
||
Reporter | ||
Comment 13•17 years ago
|
||
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.
Reporter | ||
Comment 14•17 years ago
|
||
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.
Reporter | ||
Comment 15•17 years ago
|
||
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.
Reporter | ||
Comment 16•17 years ago
|
||
This is still an issue with SeaMonkey 1.1.9.
Reporter | ||
Comment 17•16 years ago
|
||
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
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Reporter | ||
Comment 18•14 years ago
|
||
Issue also occurs with MMS (picture mail) from LG phones as well. SeaMonkey 2.0.5 for Windows.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 19•14 years ago
|
||
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.
Comment 20•14 years ago
|
||
(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
Reporter | ||
Comment 21•14 years ago
|
||
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.)
Comment 22•14 years ago
|
||
(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".
Reporter | ||
Comment 23•14 years ago
|
||
Will close this and open new bug.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 14 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 24•14 years ago
|
||
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 → ---
Reporter | ||
Comment 25•14 years ago
|
||
Source of test HTML message not displayed with SeaMonkey and Thunderbird (Windows and Linux versions).
Reporter | ||
Comment 26•14 years ago
|
||
(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?
Reporter | ||
Comment 27•14 years ago
|
||
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.
Reporter | ||
Comment 28•14 years ago
|
||
Closing this bug, only affects certain phone models.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → INVALID
Comment 29•13 years ago
|
||
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.
Description
•