Closed Bug 1693156 Opened 3 years ago Closed 3 years ago

E-Mails signed by default (S/MIME or PGP) show multipart/mixed for the body instead of multipart/alternative (leading to display issues in other clients)

Categories

(MailNews Core :: Composition, defect)

Thunderbird 86
defect

Tracking

(thunderbird_esr78 unaffected, thunderbird87 fixed)

RESOLVED FIXED
88 Branch
Tracking Status
thunderbird_esr78 --- unaffected
thunderbird87 --- fixed

People

(Reporter: chris, Assigned: rnons)

References

(Regression)

Details

(Keywords: regression)

Attachments

(5 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

  1. Reply to an email message

Actual results:

  1. View reply in non-Thunderbird email client.
  2. Note how top of the message contains content without any line breaks, followed by correctly formatted content.

This is the simplified source of a reply message. Only message content and headers were removed -- all MIME markup was left as generated by Thunderbird 86.0b3.

=====START
VALID HEADERS

--2QwRmNr8rhD9HdgatTIam88HptNIpyVHF
Content-Type: multipart/mixed; boundary="bWbswnfzjkgNqgDRioCpjmrsreKeoaOQl";
protected-headers="v1"
From: censored
To: censored
Message-ID: censored
Subject: censored
References: censored
In-Reply-To: censored

--bWbswnfzjkgNqgDRioCpjmrsreKeoaOQl
Content-Type: multipart/mixed; boundary="------------loOKvnQqapnJTToKhT071Lfu"

--------------loOKvnQqapnJTToKhT071Lfu
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Another test with some different mail settings.
Message content manually censored for brevity.

--------------loOKvnQqapnJTToKhT071Lfu
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
</head>
<body>
Another test with some different mail settings.<br>
Censored for brevity.
</body>
</html>
--------------loOKvnQqapnJTToKhT071Lfu--

--bWbswnfzjkgNqgDRioCpjmrsreKeoaOQl--

--2QwRmNr8rhD9HdgatTIam88HptNIpyVHF
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEE69BBxgzRNYPH8uJSU1Dd4YfG/jEFAmAsHOQFAwAAAAAACgkQU1Dd4YfG/jGE
iQ//eYqb15gDk4lOEY6eNVqOBbDSv5v48kmS7TzmnbcMr81Ws2Cw38LZoY7RMsLLQcQMLeHee1GX
srLadF5wtlqhEPjqh/mu4KPjv19WxTH4stFu9siStg33j6OWIaU+fHfwEm5FiTky2gspoBRPUM4K
fZxYbTK596JVi1LygChxqpJWPkcY9OpVwKdt1k61s88/Sej7L87tHadkMdkhnW/Iy4VFbgpKHKlH
ptUw3Ui5L5nzD63G4BJCISsb7/mpxrhHzIq4rnu9KnUbFGeW0S6PpAhVnvt/CLMAGZYBKYddL9aY
mhjpX1cgpfI9bCSLFSrJIGDRIPDBy70nDTOrf8oKbAEhXUzskJPuTxPf3ViymUWmI97Iz6D3m4Pi
dr1evR7SiyDFfMA1dsV7Q/7ssQ0YLiSJXY0WUws87lFkJrj21Wh+j8/TrVc6J0/lMdsjgfeEdLwV
7cYEAXG4NBhH/bu+RNZp9oYUdFIoRe+6sExFzl4zg2IbX5hWj+mPhwscw0iKHtHVD0PorjcOnIRP
y/ba62idBgsrYpkSE6VHyyv/uSYtCVagn9EIb5zx5dJTtCVko/930DVxuwb7w1a3KPNcWmSREour
netBpB1QMgUtz6/H17Nb1Hkmce8aURzI8k3dPt1CN++CIn4zFDzVycNOvSBUDidUxBwFRxf4lAm+
RcY=
=9+89
-----END PGP SIGNATURE-----

--2QwRmNr8rhD9HdgatTIam88HptNIpyVHF--

=====END

Expected results:

To my untrained eye, it looks like an inappropriate copy of the text/plain boundary string (--------------loOKvnQqapnJTToKhT071Lfu) was inserted at the top of the text/plain section.

Please provide more detail or even a complete "defective" message from your Sent mailbox. Simply replying doesn't cause any problem, but there might be circumstances where the problem shows. Looks like this is an encrypted message with a "protected-headers" part. But then, the message would be encrypted. With the information you gave, this is not actionable.

Attached file sample.eml

Sample email showing defective rendering in non-Thunderbird client.

Attached image outlook.png

View of how sample.eml looks in Microsoft Outlook.

Attachment #9204451 - Attachment mime type: message/rfc822 → text/plain

Well, it looks fine in my Outlook O365, I'll attach a screenshot in a minute. Let's look at the mime structure:

multipart/signed - boundary="rJnw7zvYwUgrLAEXnR1qO1L0vd96G6r81"

--rJnw7zvYwUgrLAEXnR1qO1L0vd96G6r81
Content-Type: multipart/mixed; boundary="z4fmyhVpABDs8zOMM0f9enHNimn1mjLPT";  protected-headers="v1"
some headers
--z4fmyhVpABDs8zOMM0f9enHNimn1mjLPT

Content-Type: multipart/mixed; boundary="------------vQMOEVj9HsIj0MKuEvxvnAsz" <== Not multipart alternative??
--------------vQMOEVj9HsIj0MKuEvxvnAsz
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Testing reply formatting.
etc.

--------------vQMOEVj9HsIj0MKuEvxvnAsz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
etc.
--------------vQMOEVj9HsIj0MKuEvxvnAsz--

--z4fmyhVpABDs8zOMM0f9enHNimn1mjLPT--

--rJnw7zvYwUgrLAEXnR1qO1L0vd96G6r81
Signature
--rJnw7zvYwUgrLAEXnR1qO1L0vd96G6r81--

So mostly this is fine, however, if I produce a signed plain text+HTML message in TB 78 or 86, I get multipart/alternative. TB displays the "mixed" HTML part inline, Outlook shows it as attachment.

So, so far, I can't see an issue, although I'm wondering why you're not getting multipart/alternative.

Attached image OL-display.png

This is what I see, the plain/text part is displayed correctly. It works fine on reply, too.

EDIT: If I change multipart/mixed to multipart/alternative where indicated, TB and OL only show the HTML part and it looks completely fine.
So as I said, other than the inexplicable multipart/mixed which I cannot reproduce, I can't see an issue.

I am having a similar issue to this in Thunderbird 86.0b3. It doesn't seem to be limited to replying or forwarding and it seems to be caused by having a S/MIME or PGP signature in the e-mail. Without the signatures, everything works as usual. Do you get the same result when you turn off your PGP signature?

What exactly are the issues? The presenter Chris presented one message (with PGP signature) that displays correctly in both TB and OL and has a correct MIME structure. The question how the multipart/mixed instead of multipart/alternative was produced was left unanswered. What in your opinion should a Thunderbird developer fix or change?

I'm not really sure what it is yet, but some recipients seem to see the plain text format e-mail instead of the HTML version. This seems to have started after I upgraded to the beta and when I send without the S/MIME signature, they seem to see the HTML version.

Hmm, seeing the plain text instead of the HTML and the HTML perhaps as attachment (see comment #5) appears to be the problem I observed (see comment #4), multipart/mixed instead of multipart/alternative.

@dittnamn: Can you supply such a message? Do you see the issue if you switch off the JS send module via preference mailnews.send.jsmodule. I've just tried again using the default value and a sent message which was PGP-signed looks just fine.

Ping, are you aware of any changes in the JS send module that may cause this (which?) issue? Or were there any changes in the PGP code? Very hard to tell, since we don't even have a clear definition of the issue yet.

Flags: needinfo?(remotenonsense)

The issue is not there when I disable mailnews.send.jsmodule, and it doesn't seem to happen everytime I send an e-mail either. I'll try to get a clean example message in a while.

Alright, I attached an example e-mail that shows up in both plaint text and HTML in Thunderbird and Roundcube. The issue only seems to happen when I create an e-mail and send it using the default settings (signed with PGP or S/MIME). If I disable the PGP signature and reenable it before sending, the HTML version is shown instead.

Attachment #9204893 - Attachment mime type: message/rfc822 → text/plain

So given that disabling mailnews.send.jsmodule "fixes" the issue, it looks to me like it's caused by the new JS send module. Thanks for the sample, it confirms what we previously saw:

Content-Type: multipart/mixed; boundary="------------G5YhwhmEjmbaDIlblAwuulbj"

--------------G5YhwhmEjmbaDIlblAwuulbj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Test

--------------G5YhwhmEjmbaDIlblAwuulbj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    <p>Test</p>
  </body>
</html>
--------------G5YhwhmEjmbaDIlblAwuulbj--

As you can see, once again, multipart/mixed instead of multipart/alternative.

And it only happens if signing is by default. I manually switched on signing for that message, so that didn't show the issue. That should give the developer something to work with.

Summary: Reply/forward emails display badly, multipart MIME boundaries look incorrect → E-Mails signed by default (S/MIME or PGP) show multipart/mixed for the body instead of multipart/alternative (leading to display issues in other clients)
Attached patch 1693156.patchSplinter Review

Thanks, the problem happens when signing is turned on and attaching the key turned off.

Assignee: nobody → remotenonsense
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(remotenonsense)
Attachment #9205026 - Flags: review?(mkmelin+mozilla)
Component: Untriaged → Composition
Keywords: regression
Product: Thunderbird → MailNews Core
Regressed by: 1680189
Comment on attachment 9205026 [details] [diff] [review]
1693156.patch

Review of attachment 9205026 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM, r=mkmelin
Attachment #9205026 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → 88 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/56c47b8ce37b
Fix content-type of MimePart wrapped in a signed message. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

Comment on attachment 9205026 [details] [diff] [review]
1693156.patch

[Approval Request Comment]
Regression caused by (bug #): bug 1680189
User impact if declined: The plain and html part of a signed email may be rendered at the same time.
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): Low

Attachment #9205026 - Flags: approval-comm-beta?

Comment on attachment 9205026 [details] [diff] [review]
1693156.patch

[Triage Comment]
approved for beta

Attachment #9205026 - Flags: approval-comm-beta? → approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: