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

Status: RESOLVED DUPLICATE of bug 689964

(MailNews Core :: MIME, defect)

Description

[Edward]

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.

Comment 1

[Edward]

The e-mail in question is sent via a T-Mobile USA camera phone.

Comment 2

[Frank Wein [:mcsmurf]]

Do you have loading of external images enabled (may be a privacy risk)?

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[Edward]

Attachment: Source of HTML message not displayed

Comment 5

[Edward]

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

[David :Bienvenu]

we don't use those mail1-5 keywords, really. We used to use them a long time ago.

Comment 7

[Edward]

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

[Mike Cowperthwaite]

Attachment: Mailbox with messages

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

[Mike Cowperthwaite]

Reproduced with TB 2b1-1111 and SM 1.5a-0925, Win2k.

Comment 10

[Edward]

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

[Mike Cowperthwaite]

(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.

Comment 12

[Edward]

Attachment: Sample header

Comment 13

[Edward]

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.

Comment 14

[Edward]

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.

Comment 15

[Edward]

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.

Comment 16

[Edward]

This is still an issue with SeaMonkey 1.1.9.  

Comment 17

[Edward]

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.

Comment 18

[Edward]

Issue also occurs with MMS (picture mail) from LG phones as well.  SeaMonkey 2.0.5 for Windows.

Comment 19

[Edward]

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

[WADA:World Anti-bad-Duping Agency]

(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

Comment 21

[Edward]

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

[WADA:World Anti-bad-Duping Agency]

(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".

Comment 23

[Edward]

Will close this and open new bug.

Comment 24

[Edward]

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.

Comment 25

[Edward]

Attachment: Raw header (HTML) information from test picture message sent via T-Mobile phone.

Source of test HTML message not displayed with SeaMonkey and Thunderbird (Windows and Linux versions).

Comment 26

[Edward]

(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?

Comment 27

[Edward]

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.

Comment 28

[Edward]

Closing this bug, only affects certain phone models.

Comment 29

[WADA:World Anti-bad-Duping Agency]

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.