Cryptographic Protection of E-mail Headers



Encrypted or signed e-mail does not have cryptographic protection of headers – only the body of an e-mail message is encrypted or signed. This specification provides a solution to this problem by embedding relevant headers within the body of the e-mail in a well-structured way.

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 February 4, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

2. Terminology

header line
a single header field, like “Subject: encrypting mail headers”
header block
a collection of header lines associated with an e-mail message or MIME part
protection layer
a MIME part that wraps an entire MIME subtree with some form of cryptographic protection. application/signed and application/encrypted Content-Types are protection layers.
protected subtree
a MIME subtree immediately enclosed by a protection layer
top protected part
the root MIME part of a protected subtree
external header block
the collection of header lines located outside the body of an e-mail message
external header line
a header line within an external header block
MIME part header block
the collection of header lines assocatied with a MIME part, as distinguished from the content of the MIME part
MIME part header line
a header line within a MIME part header block
displayable header part
a Content-Type: text/rfc822-headers MIME subpart located as the first child of a multipart/mixed top protected part. This part has a MIME part header block, and its content is also a header block. A displayable header part’s MIME part header block should be Content-Disposition: inline, and its parent’s MIME part header block should be Content-Type: multipart/mixed and Memory-Hole: displayable
displayable header line
a header line in the content of a display header part
mail user agent (MUA)
an application designed to receive, render, compose, and send e-mail on behalf of a user

3. Message Structure

In order for cryptographic protection of the e-mail body to apply to associated e-mail headers, the relevant e-mail headers must be present within the body of the message. This section describes how a memoryhole-compatible MUA should inspect the content of a protected message to find the relevant headers.

Not all headers for a given message will necessarily be protected, so rendering MUAs should be prepared for circumstances where some headers have different levels of protection than others. Displaying this distinction to the user is out of scope for this specification (we hope to collect such UI/UX guidance in a companion document).

Below we describe the semantic concepts and how to find them from the structure of the message.

  • When interpreting and rendering an e-mail message, cryptographically aware MUAs should associate each e-mail header line with a set of cryptographic protections: 0 or more “encrypted-by…” and 0 or more “signed-by…” protection associations per header line.
  • protection association sets have a prioritization hierarchy, from highest to lowest:
    • a set with both signed-by and encrypted-by associations
    • a set with only signed-by associations
    • a set with only encrypted-by associations
    • an empty set
  • within each prioritization category, a set with more associations than another is a higher priority than a set with fewer associations.
  • Before cryptographic processing, all header lines have an empty set of protection associations.
  • an e-mail or message part whose Content-Type is a “message protection type” (multipart/signed or multipart/encrypted) inherits all header lines (replacing its own lines) from the internal top-level protected MIME part, if the internal header line has a higher-priority set of protection associations than the current header line.
    • Headers inherited across a verified multipart/signed protection that gains a “signed-by” protection association for each verified signature.
    • Headers inherited across a successfully decrypted multipart/encrypted protection gain an “encrypted-by” protection association for each key known to effectively decrypt the content. If the multipart/encrypted protection also includes a cryptographic signature (as in the case of one-shot PGP/MIME), these headers also gain a “signed-by” protection association for each verified signature.
  • header inheritance chains, so internal headers “bubble up” if they are a higher priority.

TODO: document Force-display (explicit embedded header mime part for compatibility with decryption-capable pre-memoryhole clients) and how it fits into the above breakdown.

3.1. Locating an embedded header


4. Distinguishing from DSN

see [RFC6522]

5. Consequences for encrypted headers

Some message headers are more privacy/confidentiality sensitive than others. When a block of headers is embedded in the encrypted body, the corresponding lines in the external header should be stripped or stubbed out, for at least some of the headers.

If confidentiality is desired for a header line protected in the body of the message by an encryption protection layer, the external header line in question should be removed from the external header block, or possibly replaced with a dummy external header line. The choice of whether to remove or replace depends on the header line itself.

We document the tradeoffs about removing/replacing specific header lines below.

6. Subject

7. To and Cc

8. From

9. Message-ID

10. In-Reply-To, References

11. Date

12. Security Considerations

13. Privacy Considerations

14. IANA Considerations

  • registering any new headers?

15. TODO

  • Should we mark this as updating any of the DSN RFCs?
  • Acknowledge message/rfc822 wrapping and explain why this is different

16. Informative References

[RFC1891]Moore, K., “SMTP Service Extension for Delivery Status Notifications“, RFC 1891, DOI 10.17487/RFC1891, January 1996.
[RFC1892]Vaudreuil, G., “The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages“, RFC 1892, DOI 10.17487/RFC1892, January 1996.
[RFC1894]Moore, K. and G. Vaudreuil, “An Extensible Message Format for Delivery Status Notifications“, RFC 1894, DOI 10.17487/RFC1894, January 1996.
[RFC2047]Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text“, RFC 2047, DOI 10.17487/RFC2047, November 1996.
[RFC3156]Elkins, M.Del Torto, D.Levien, R. and T. Roessler, “MIME Security with OpenPGP“, RFC 3156, DOI 10.17487/RFC3156, August 2001.
[RFC5322]Resnick, P., “Internet Message Format“, RFC 5322, DOI 10.17487/RFC5322, October 2008.
[RFC6522]Kucherawy, M., “The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages“, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012.

Author’s Address

Daniel Kahn Gillmor
EMail: [email protected]