Closed Bug 1814598 Opened 2 years ago Closed 2 years ago

mailnews.send.jsmodule alters body of signed-only text message before sending

Categories

(Thunderbird :: Untriaged, defect)

Thunderbird 102
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: github, Unassigned)

Details

Attachments

(2 files)

Steps to reproduce:

I'm sending a new text message to myself with an S/MIME signature that is not encrypted, with the mailnews.send.jsmodule property undefined (defaulting to true).

Actual results:

The signature of the mail stored in the Sent folder is recognized as valid. The signature of the mail received in the Inbox is shown as invalid. Storing both messages as .eml files and comparing reveals that the signed part of the multipart message has been changed in two ways:

  1. The Content-Transfer-Encoding was altered from "7bit" to "quoted-printable"
  2. The line that was wrapped automatically and which contains a trailing space character " " in the Sent folder is missing this trailing space in the Inbox.

Defining the mailnews.send.jsmodule property, setting it to "false" solves the problem, and both, Inbox and Sent message validate the signature OK.

Expected results:

With all settings, specifically with the default setting of mailnews.send.jsmodule, Thunderbird should never alter the signed body of a text message while sending; it breaks the signature.

This one is the message from the inbox with the body altered and the signature broken.

Did some more digging and testing. With a mail account on a local exim-based mail server and a corresponding POP3 daemon the problem cannot be reproduced. This led me to wonder where along the transmission there could be a chance for message modification that is excluded with a local e-mail server, and this now leads me to believe that the e-mail hoster (GMX, gmx.de) used for the initial test and where the problem was initially observed with is actively altering the e-mail content between receiving the message and delivering it through a POP3 server API.

Some more tests suggest that this effect happens on GMX's side depending on the message body. HTML and plain text messages that do not contain special characters such as umlauts are preserved and not altered by GMX, so the signature matches. However, as soon as an umlaut character shows up, GMX decides to change the encoding which then breaks the signature.

Therefore, I'll resolve this as WORKSFORME, and the recommendation then is to use encryption if you don't want an e-mail hoster to tamper with your messages, or avoid such hosters altogether...

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: