Closed Bug 1808192 Opened 2 years ago Closed 2 years ago

Contents of some PGP encrypted facebook emails are shown with raw html tags, because an HTML document is incorrectly sent with content-type=text/plain

Categories

(MailNews Core :: Security: OpenPGP, defect)

Product:
MailNews Core
Component:
Security: OpenPGP
Version:
Thunderbird 102
Platform:
Desktop
All
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: Chris, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

I enabled PGP encryption for facebook emails at facebook. I installed the facebook PGP key. From this moment I can see the encrypted emails from facebook.

Actual results:

I got several facebook status notifications related from facebook ads. They are decrypted into HTML but not rendered as HTML. Therefore I see the raw HTML code with html tags. When I copy this raw html in a textfile text.html and open it in a browser, the message is visible, though html syntax is valid for browsers.
I also have enabled in a 2nd try the bug reporting mode in thunderbird and I got same behaviour as described.
Independent of showing the email in preview window or own windows, it is always in raw html code. When I show other facebook status email they are still shows rendered in HTML.

The start in email source code looks in both cases (rendered, and not rendered) same:
X-Priority: 3
X-Mailer: ZuckMail [version 1.00]
From: Facebook <noreply@facebookmail.com>
MIME-Version: 1.0
Content-Type: multipart/encrypted;
boundary="b1_5d374123cbc13e39b07a704f1f11ee26";
protocol="application/pgp-encrypted";
Message-ID: <cfa826be-7c91-11ed-8610-33b03b6e7aac@facebookmail.com>

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--b1_5d374123cbc13e39b07a704f1f11ee26
Content-Type: application/pgp-encrypted; charset="UTF-8"
Content-Transfer-Encoding: 7bit

Content-Description: PGP/MIME Versions Identification

Version: 1

--b1_5d374123cbc13e39b07a704f1f11ee26
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Transfer-Encoding: 7bit
Content-ID: <0>
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----

Expected results:

I expect that the HTML code of enccrypted facebook email is rendered similiar as in browser window.

Though I cannot see any different between valid html rendered and not html rendered emails, the structure and data of email source code look same. I assume that the email content itself can be the root cause which trigger to show the email in unrendered view.

The error console of thunderbird shows following message after selecting a mail which is shows raw html tags:
"
failed to extract email address from: Facebook, Inc. [funcs.jsm:563:15]
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
Content Security Policy: Ignorieren von "'unsafe-inline'" innerhalb script-src: 'strict-dynamic' angegeben
Content Security Policy: Ignorieren von "https:" innerhalb script-src: 'strict-dynamic' angegeben
Content Security Policy: Ignorieren von "http:" innerhalb script-src: 'strict-dynamic' angegeben
"

Following is shown for encrypted emails which are rendered in html:
"
failed to extract email address from: Facebook, Inc. [funcs.jsm:563:15]
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
"

To dispay the email, I have in all cases selected the "original HTML" mode.

Component: Untriaged → Security: OpenPGP
Product: Thunderbird → MailNews Core

I have a test facebook account that is set up to send encrypted messages.

I just checked, I've received an email from facebook on 2023-01-01, it is encrypted, the message is html, and it is rendered by Thunderbird as a html document (not tags).

Either something is different on your side, or you receive a different type of notifications.

To reproduce what you see, I would like to obtain a decrypted version of one of the notifications that you have received. You could use the following approach to create that.

  • create a new message folder, either in your imap account, or as a local folder
  • click one of the messages from facebook that gives you the incorrect display
  • in the message list view, click the message with the right mouse button, select "copy as decrypted to", and then select the folder you just created
  • now click that folder, it should contain the decrypted message. Click the message
  • use menu file / save as / file, and save it to a file on your disk, e.g. using filename decrypted-facebook-notification.eml
  • create a zip archive containing file decrypted-facebook-notification.eml
  • send that zip file to my email address kaie@kuix.de and in your email please mention bug number 1808192

If you click the decrypted message in that folder, does it also show that broken view? (showing tags, not rendered html)

Flags: needinfo?(christoph.woschek)

FYI, the message structure you have reported above is the structure of the encrypted container.
To understand why the decrypted contents aren't rendered correctly, I need to see the exact decrypted data.
The above procedure should allow me to see that. Wrapping it in a zip file ensures that the message won't be modified during the email transit.

(In reply to Kai Engert (:KaiE:) from comment #4)

If you click the decrypted message in that folder, does it also show that broken view? (showing tags, not rendered html)

yes

Flags: needinfo?(christoph.woschek)

(In reply to Kai Engert (:KaiE:) from comment #5)

FYI, the message structure you have reported above is the structure of the encrypted container.
To understand why the decrypted contents aren't rendered correctly, I need to see the exact decrypted data.
The above procedure should allow me to see that. Wrapping it in a zip file ensures that the message won't be modified during the email transit.

Have replaced private strings in EML-file. It seams that this can be a problem for analysis. Have made fidn and replace for private parts.

Thanks Christoph.
I have extracted the structure of the email, and removed all unnecessary contents, see below.

The message claims the content type is "text/plain", but inside it, it includes an HTML document.
That's why we show the html tags, because we assume this is the intention of the sender.

I think this is a broken document structure. The message should have been sent with content-type=text/html

Prior to this email, I never saw <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />, I don't know if this is an allowed upgrade of a text/plain document to a text/html document. If it is, we aren't processing it.

X-Mailer: ZuckMail [version 1.00]
From: Facebook <noreply@facebookmail.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="boundary"

--boundary
Content-Type: multipart/alternative;
	boundary="boundary"


--boundary
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="x-apple-disable-message-reformatting" />
<title>Meta for Business</title></head>
<body style="padding:0;">
</body></html>



--boundary--

--boundary--
Status: UNCONFIRMED → NEW
Ever confirmed: true

Thanks for analysis. I understand, wrong syntax is used, mutipart within multipart with only one section and this one is wrong. paintext is unformatted per definition. Thunderbird is doing all spec conform. I think facebook do not test with Thunderbird :-).
May be it could be an idea to enhance SW error tolerance handling of such crazy emails. I post an bug report to facebook too.

So I think here is nothing to do any more, its not a bug of Thunderbird. Thanks you.

OS: Unspecified → All
Hardware: Unspecified → Desktop
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Summary: PGP encrypted facebook emails are shown in raw html, not rendered → Contents of some PGP encrypted facebook emails are shown with raw html tags, because an HTML document is incorrectly sent with content-type=text/plain
You need to log in before you can comment on or make changes to this bug.