RFC 9788: Header Protection for Cryptographically Protected Email
In plain English — editorial summary, not part of the RFC
S/MIME version 3.1 introduced a mechanism to provide end-to-end cryptographic protection of email message headers. However, few implementations generate messages using this mechanism, and several legacy implementations have revealed rendering or security issues when handling such a message. This document updates the S/MIME specification (RFC 8551) to offer a different mechanism that provides the same cryptographic protections but with fewer downsides when handled by legacy clients. Furthermore, it offers more explicit usability, privacy, and security guidance for clients when generating or handling email messages with cryptographic protection of message headers. The Header Protection scheme defined here is also applicable to messages with PGP/MIME (Pretty Good Privacy with MIME) cryptographic protections.
Document record
- Document ID
- RFC9788
- Published
- August 2025
- Authors
- D. K. Gillmor; B. Hoeneisen; A. Melnikov
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 218
- Also known as
- —
- Updates:
- RFC 8551
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 9787Guidance on End-to-End Email SecurityCurrent
August 2025
- RFC 4490Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)Current
May 2006
- RFC 9216S/MIME Example Keys and CertificatesCurrent
April 2022
- RFC 3854Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)Current
July 2004
- RFC 3850Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate HandlingObsoleted
July 2004
- RFC 2634Enhanced Security Services for S/MIMEUpdated
June 1999
- RFC 1320The MD4 Message-Digest AlgorithmObsoleted
April 1992
- RFC 1319The MD2 Message-Digest AlgorithmObsoleted
April 1992
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?