Internet-Draft Encrypted E-mail with Cleartext Copies November 2023
Gillmor & Huigens Expires 9 May 2024 [Page]
Intended Status:
Standards Track
D. K. Gillmor
D. Huigens
Proton AG

Encrypted E-mail with Cleartext Copies


When an e-mail program wishes to send an encrypted message to multiple recipients, it is possible that it has no encryption capability for at least one of the recipients, for example because it cannot find a public key for those recipients.

In this circumstance, an e-mail program may choose to still send the message encrypted to the recipients it can encrypt to, and send the message in cleartext to the recipient it cannot encrypt to.

This draft defines an e-mail header to indicate to the recipients that received an encrypted copy, whether all recipients received an encrypted copy, or whether cleartext copies were sent, to inform them of the cryptographic protection status of the message.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at Status information for this document may be found at

Discussion of this document takes place on the LAMPS Working Group mailing list (, which is archived at Subscribe at

Source for this draft and an issue tracker can be found at

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 9 May 2024.

Table of Contents

1. Introduction

This document is concerned with end-to-end encrypted (E2EE) e-mail messages, regardless of the type of encryption used. Both S/MIME ([RFC8551]) and PGP/MIME ([RFC3156]) standards support the creation and consumption of end-to-end encrypted e-mail messages.

When receiving end-to-end encrypted messages, the mail user agent (MUA) may want to display a visual security indicator to communicate to the user that the message was encrypted. Similarly, the MUA may need to behave carefully not to leak the message contents in cleartext, for example when composing a reply-to-all to the message. [I-D.ietf-lamps-e2e-mail-guidance] offers guidance to MUAs for handling end-to-end encrypted messages.

However, when the message was originally sent in cleartext to some of the recipients, the message was effectively not end-to-end encrypted [I-D.knodel-e2ee-definition] to all recipients, and these considerations don't apply. For MUAs, it is thus important to know whether the message was end-to-end encrypted to all recipients.

This document defines the E2EE-To-All header, indicating whether the message was end-to-end encrypted to all (visible) recipients, and provides guidance for MUAs to generate and consume this header.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.1. Terminology

In this draft:

  • E2EE is short for End-to-End Encrypted, as defined by [I-D.knodel-e2ee-definition].
  • MUA is short for Mail User Agent; an e-mail client.
  • The visible participants of an e-mail message are the sender listed in the From header, and the recipients listed in the To and Cc headers. The recipients listed in the Bcc header are invisible participants.

2. Scenarios

The following scenarios are examples where an encrypted message might be produced but some copies of the message are sent or stored in the clear. In all scenarios, Alice is composing a new message to Bob and at least one other copy is generated. Alice has a cryptographic key for Bob, and knows that Bob is capable of decrypting e-mail messages.

In each of the following scenarios, Alice's MUA generates an e-mail, and knows that there is at least one cleartext copy of the message stored on a system not under Alice's personal control.

2.1. Simple Three-Party E-mail

Alice sends a message to Bob and Carol, but Alice has no encryption-capable key for Carol. She encrypts the copy to Bob, but sends a cleartext copy to Carol.

2.2. Cleartext Remote Drafts Folder

Alice's MUA stores all draft copies of any message she writes in the clear in a Drafts folder, and that folder is itself stored on an IMAP server. When she composes a message, the IMAP server has a cleartext copy of the draft, up until and including when she clicks "Send". Her MUA instructs the IMAP server to delete the draft version of the message, but it also knows that it had at one point a cleartext copy, and cleartext might persist forever.

2.3. Cleartext Remote Sent Folder

Unlike in Section 2.2, copies of messages sent to Alice's draft folder are encrypted or only stored locally. But when sending an e-mail message to Bob, her MUA generates a cleartext copy an places it in her Sent folder, which is also stored on IMAP.

2.4. Public Mailing List

Alice "Replies All" to message from Bob on a public mailing list. The public mailing list has no encryption-capable public key (it is archived publicly in the clear), so Alice cannot encrypt to it. But Alice's MUA is configured to opportunistically encrypt every copy possible, so the copy to Bob is encrypted.

2.5. Trusted Mailserver

Alice and Bob work in different organizations, and Alice's MUA has a policy of encrypting to outside peers that does not apply to members of her own organization. Alice's co-worker David is in Cc on the message, and Alice and David both share a trusted mail server, so Alice does not feel the need to encrypt to David. But she wants to defend against the possibility that Bob's mail server could read the contents of her message.

3. Problems

Receiving MUA often needs to behave differently when handling a message with a different cryptographic status.

3.1. Security Indicators

The MUA may want to indicate to the user whether received messages were end-to-end encrypted or not. When a cleartext copy of the message was sent, the message was not end-to-end encrypted as defined by [I-D.knodel-e2ee-definition]. It is important that the message is not indicated as end-to-end encrypted by the MUA in that case, so that the user is away that other parties may have had access to the contents of the message.

3.2. Reply All

When receiving an end-to-end encrypted message, a MUA needs to avoid leaking the contents of the message in the clear during a reply (see Section 5.4 of [I-D.ietf-lamps-e2e-mail-guidance]).

However, if one of the visible participants of the message does not have a cryptographic key, for example, neither the message nor any reply will be able to be end-to-end encrypted. In this case, it is important to indicate that the original message was not end-to-end encrypted, such that the recipient's MUA does not need to warn the user about sending an unencrypted reply to an encrypted message.

4. The E2EE-To-All Header Field

To solve the issues described above, this document specifies a new e-mail header field with the name E2EE-To-All. The only defined values of this field are 1 and 0. This header indicates whether the message was end-to-end encrypted to all visible recipients.

4.1. Sending Encrypted Messages with the E2EE-To-All Header Field

A MUA that creates a message that is encrypted to all visible participants SHOULD add this header field with a value of 1 to each copy of the message.

A MUA that creates an encrypted message with a cleartext copy to one of the visible participants MUST add this header field with a value of 0 to each encrypted copy of the message.

4.2. Receiving Encrypted Messages with the E2EE-To-All Header Field

When receiving a message with an E2EE-To-All: 0 header, the MUA MUST NOT consider the message end-to-end encrypted. It MUST NOT indicate to the user that the message was end-to-end encrypted, and SHOULD NOT indicate the message as being more secure than an unencrypted message.

When composing a reply-to-all to such a message, the MUA MAY send an unencrypted reply to some or all of the participants, and MAY quote the original message in cleartext replies.

When receiving an encrypted message without an E2EE-To-All header, it MAY indicate the message as being encrypted while use of the header is not widespread yet, but SHOULD indicate the message as being unencrypted once usage is widespread, or if the MUA has other reasons to believe the sender may have sent an unencrypted copy of the message.

When composing a reply-to-all to such a message, however, the MUA SHOULD consider the message end-to-end encrypted, and SHOULD send only encrypted replies, or omit the quoted text of the original message, as specified in Section 5.4 of [I-D.ietf-lamps-e2e-mail-guidance].

5. IANA Considerations

The IANA registry of Message Headers should be updated to add a row with Header Field Name E2EE-To-All, no template, protocol mail, status standard, and a reference to this document.

6. Security Considerations

6.1. Misrepresentations By Sender are Out of Scope

This document describes security considerations between mutually-cooperating, end-to-end encryption-capable MUAs. Either party could of course leak cleartext contents of any such message either deliberately or by accident.

In some cases, such as a Bcc scenario, the sending MUA is deliberately taking action on the sender's behalf that they do not want the (listed) recipient to know about. Indicating to the listed recipient that a Bcced copy was emitted in the clear may violate the sender's expectations about what was done with the message.

This specification is not intended to detect fraud, misbehavior, or deliberate misrepresenation from one of the clients.

6.2. Cryptographic Guarantees

For the proposed solutions that require a header field, that header field itself needs cryptographic protections, or an intervening mail transport agent could inject it to tamper with the apparent cryptographic status of the message.

For this reason, any header field involved in this must be provided with header protection, as described in [I-D.ietf-lamps-header-protection].

Additionally, since this is dealing with encrypted messages only, the sender may want to strip the E2EE-To-All header from the unencrypted headers before sending the message, to avoid indicating to a mail transport agent whether a cleartext copy of the message is available somewhere.

7. References

7.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.

7.2. Informative References

Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, , <>.
Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, , <>.
Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Guidance on End-to-End E-mail Security", Work in Progress, Internet-Draft, draft-ietf-lamps-e2e-mail-guidance-12, , <>.
Knodel, M., Celi, S., Kolkman, O., and G. Grover, "Definition of End-to-end Encryption", Work in Progress, Internet-Draft, draft-knodel-e2ee-definition-11, , <>.
Gillmor, D. K., Hoeneisen, B., and A. Melnikov, "Header Protection for Cryptographically Protected E-mail", Work in Progress, Internet-Draft, draft-ietf-lamps-header-protection-17, , <>.

Appendix A. Document History

A.1. Changes from draft-dkg-mail-cleartext-copy-01 to draft-dkg-mail-cleartext-copy-02

Define the E2EE-To-All header, and provide guidance to MUAs for generating and handling it. Remove the other options previously considered in this draft.

Authors' Addresses

Daniel Kahn Gillmor
Daniel Huigens
Proton AG