By default, the subject of email messages is sent in plain text, even if the message body is encrypted.

For S/MIME, it's always sent unencrypted.

For OpenPGP, a mechanism is defined for encrypting the subject, by transporting it inside the encrypted message contents, and use a simple placeholder in the plaintext headers, for example "..."

Enigmail supported this. We can probably keep support it easily.

Open questions are:

• should we always try to do that by default, or only if the user opts in?
  (some people consider it confusing if the the subject isn't readable,
  vs. the risk that people accidentally reveal a secret in the subject)
• how should we offer the choice in the UI?

Right now, we don't have UI yet. Except - Enigmail has a one-time popup notification/question. I haven't yet disabled it. We probably don't want that popup, but some other UI.

It's hard to explain to people the message is secure and the subject is not, so I think probably better to use the subject encryption mechanism.

This is the specification for encrypted subjects should be implemented. The spec covers both OpenPGP and S/MIME:
https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/

Thanks. I found the Enigmail code still works in our nightly, if the pref is enabled.

I assume there are email clients that support OpenPGP, but don't implement this header extension, right?
If yes, users of those clients might never see the original subject.

Nevertheless, I think it's OK if we enable it by default for now.
We can handle UI for this option later.

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

I assume there are email clients that support OpenPGP, but don't implement this header extension, right?
If yes, users of those clients might never see the original subject.

Has it been considered to add a copy of the subject as the very first line of the inner email body - to ensure it will be shown to the user in non-supporting clients, too?

There is a separate "Legacy Display" message part for this purpose (a specific text/plain message part that is flagged with a header). See section 5 of the specification. By now, many MUA - but certainly not all - support this feature.

Thanks Patrick. I'm unsure if legacy display is already implemented. Below is a simple example of what the current code produces.

The example matches most properties of section 5.2.1 but it doesn't specify the content type for the initial part. Does the absent Content-Type on the message header section imply that it's text/plain and therefore satisfy section 5.2.1 ?

It seems to me that we'd need to add another initial sub part of type text/plain that contains the obscured Subject header, only.

Content-Type: multipart/mixed; boundary="yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb";
 protected-headers="v1"
From: test <testmail@kuix.de>
To: test <testmail@kuix.de>
Message-ID: <ddc2cf3f-39ca-aa37-49fd-2a1e670e5a88@kuix.de>
Subject: enc header

--yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

j98j23pfj3m24n2h2




--yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb--

Patrick, do you know the answer to comment 7 ?

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/464c3c056790
Always send OpenPGP encrypted subject. r=PatrickBrunschwig

Section 5.1.1 defines how to create a legacy display part:

Consider a message whose Cryptographic Payload, before encrypting, that would have a traditional multipart/alternative structure:

X └┬╴multipart/alternative
Y  ├─╴text/plain
Z  └─╴text/html

When adding a Legacy Display part, this structure becomes:

V └┬╴multipart/mixed
W  ├─╴text/plain ("Legacy Display" part)
X  └┬╴multipart/alternative ("original body")
Y   ├─╴text/plain
Z   └─╴text/html

That is, your encrypted message with a Leagcy Display part should look like this:

Content-Type: multipart/mixed; boundary="yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb";
 protected-headers="v1"
From: test <testmail@kuix.de>
To: test <testmail@kuix.de>
Message-ID: <ddc2cf3f-39ca-aa37-49fd-2a1e670e5a88@kuix.de>
Subject: enc header

--yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb
Content-Type: text/plain; charset=utf-8; protected-headers="v1"

Subject: enc header

--yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

whatever blah

--yPVpp0ltDhMdoiQvKhqtGGvICetG4lGDb--

I had missed this pref