Closed Bug 1774805 Opened 3 months ago Closed 1 month ago

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

Categories

(MailNews Core :: MIME, defect)

Thunderbird 91
defect

Tracking

(thunderbird_esr102+ affected, thunderbird105 affected)

RESOLVED FIXED
106 Branch
Tracking Status
thunderbird_esr102 + affected
thunderbird105 --- affected

People

(Reporter: david, Assigned: mkmelin)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Attached file 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.

Attached image Initial email display

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

Summary: SNS texts received as email do not display well → SMS texts received as email do not display well

If

Version: Thunderbird 102 → Thunderbird 91
Attachment #9281816 - Attachment mime type: message/rfc822 → text/plain

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: <foo@bar.net>
| Content-Location: CID: foo@bar.net
|
| 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">

Status: UNCONFIRMED → NEW
Component: Untriaged → MIME
Ever confirmed: true
Product: Thunderbird → MailNews Core
Summary: SMS texts received as email do not display well → 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

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.

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

From the sample:

User-Agent: Android-Mms/2.0

I guess this could be a fairly widespead problem.

Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED

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.

Attachment #9290568 - Attachment description: Bug 1774805 - Don't Content-Location base which can't become a url. r=benc → Bug 1774805 - Don't use Content-Location base which can't become a url. r=benc
Target Milestone: --- → 106 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/ce8b11532aa6
Don't use Content-Location base which can't become a url. r=benc

Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED

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

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

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.

You need to log in before you can comment on or make changes to this bug.