1774805 - Images in multipart/related HTML parts are not displayed because the CID references are not resolved correctly if the MIME part contains a Content-Location: header

Status: RESOLVED FIXED

(MailNews Core :: MIME, defect)

Description

[David McDivitt]

Attachment: message_2.eml

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.0.0 Safari/537.36

Steps to reproduce:

I displayed a web page on my android phone then shared the page as a text message having my email address as the destination.

Actual results:

In Thunderbird the email is very hard to work with having a large blank section at the top with difficulty getting to information the email contains.

Expected results:

There should be no blank section at the top necessitating scrolling. The link contained in the text should be clickable and open that web page.

Comment 1

[David McDivitt]

Attachment: Initial email display

Comment 2

[David McDivitt]

Attachment: Email display showing attachment list

Comment 3

[David McDivitt]

Attachment: Email display stretched to view the text it contains

Comment 4

[David McDivitt]

This is a longstanding issue for as long as I can remember and is not new to 102 beta.

Comment 5

[Wayne Mery (:wsmwk)]

If

Comment 6

[Alfred Peters [:infofrommozilla]]

This is caused by the MIME part header:
Content-Location:smil.xml

If I remove this header, the mail is displayed correctly.

This header can be used to redirect cross-references in the content to other body parts.

On the one hand, the header here is wrong and meaningless, which is why it leads to the wrong presentation, but on the other hand, there is an explicit exception in the treatment:

RFC 2557 - 8.3 Use of the Content-ID header and CID URLs
| When URIs employing a CID (Content-ID) scheme as defined in [URL] and
| [MIDCID] are used to reference other body parts in an MHTML
| multipart/related structure, they MUST only be matched against
| Content-ID header values, and not against Content-Location header
| with CID: values. Thus, even though the following two headers are
| identical in meaning, only the Content-ID value will be matched, and
| the Content-Location value will be ignored.
|
| Content-ID: <[e-mail]>
| Content-Location: CID: [e-mail]
|
| Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
| permitted to make them unique only within a message or within a
| single multipart/related structure.

The IMG references in the body should therefore not be affected.
Like e.g.:
<IMG src="cid:tmobilespace.gif" width="350" height="30">

Comment 7

[David McDivitt]

To demonstrate this issue I sent an SMS text message to my POP3 email address. in the text message I included a web address URL. Upon receiving the email in Thunderbird I dragged and dropped it from my inbox to the Windows desktop, creating an .eml file. After editing the .eml file to remove personal info I uploaded that for this issue. If however, I display the email in K-9, the android application, which pulls from the same POP3 mailbox, it displays the email perfectly and the URL is clickable.

For comparison I sent a similar text message to my work email address which is Outlook, Office 365, Enterprise. It displays the email perfectly and the link is clickable. Image uploaded for that. Understand, the email for the Outlook rendering is the same as for the Thunderbird rendering since both originated from the Google android messaging app.

Comment 8

[David McDivitt]

Attachment: Similar email sent to Outlook, Office 365, Enterprise

Comment 9

[David McDivitt]

I'm hoping someone takes this ticket number since I receive emails generated by mobile phone texting quite a lot, and they're a pain to view in TB. They render excellent in Outlook and K-9 on android. Please see the images I posted. Thanks

Comment 10

[Magnus Melin [:mkmelin]]

From the sample:

User-Agent: Android-Mms/2.0

I guess this could be a fairly widespead problem.

Comment 11

[Magnus Melin [:mkmelin]]

Attachment: Bug 1774805 - Don't use Content-Location base which can't become a url. r=benc

Comment 12

[Magnus Melin [:mkmelin]]

Thanks Alfred for the analysis!

The proposed solution will disregard Content-Location in the first part if it can't be the basis for other parts anyway.
I'm not sure if we do much even with working full urls, but if it can't be resolved... it has more theoretical usage than anything else.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/ce8b11532aa6
Don't use Content-Location base which can't become a url. r=benc

Comment 14

[David McDivitt]

When will the beta version containing this fix be available? I'm excited.

Comment 15

[Magnus Melin [:mkmelin]]

Its' only in Daily so far. Will see how it fares, and probably uplift to beta in a couple of weeks.

Comment 16

[David McDivitt]

Thanks @magnus. One thing it needs in addition to displaying images, is making text containing links, clickable. Outlook and K-9 do that.

For instance I frequently receive texts where a web page was shared. The sender chooses to share a web page, opens their messaging app, and the web address is sent as plain text to my email address. When I receive that in TB, I must scroll the message up and down so the text is visible, highlight, copy, open the browser and paste into the address bar. This is a real pain. Links within the text should be recognized and made clickable to open the default browser with that address. Outlook and K-9 do that.

This is more than just displaying images for unanticipated header info. It will require a bit more work since plain text does not render well, anyway.

Comment 17

[Magnus Melin [:mkmelin]]

Comment on attachment 9290568 [details]
Bug 1774805 - Don't use Content-Location base which can't become a url. r=benc

[Approval Request Comment]
Regression caused by (bug #): ancient issue
User impact if declined: can't properly read certain messages, like android MMS forwarded to emails
Testing completed (on c-c, etc.): beta since some time
Risk to taking this patch (and alternatives if risky): possibly there is some fallout, the code is hard to reason about. Unlikely to break any major functionality though.

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9290568 [details]
Bug 1774805 - Don't use Content-Location base which can't become a url. r=benc

[Triage Comment]
Approved for esr102

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 102.4.1:
https://hg.mozilla.org/releases/comm-esr102/rev/c4b93edce053