| Internet-Draft | Delivered-Enc Email Header Field | August 2026 |
| Nurpmeso | Expires 4 February 2027 | [Page] |
Cryptographically protected email aims in hiding and protecting. Extending this to an uppermost extend also for trace headers, and/or the transport layer, so that only directly involved hops, which need to have a notion to "know", the sending system and/or the receiving system thus, can interpret certain header information, can be important. This document ensures that only the receiving system, in its desire to prevent email loops, can interpret the real content of the delivery notice header.¶
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 https://datatracker.ietf.org/drafts/current/.¶
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 4 February 2027.¶
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) 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.¶
The SMTP[RFC5321] protocol documents in section 6.3 "Loop Detection" an approach to prevent infinite email loops. In operational practice explicit trace header fields were in use for decades, to record delivery addresses, and to shortcut loop detection, and avoid simple counting mechanisms, until [RFC9228] created an IETF document that describes one of the solutions used in practice, the "Delivered-To Email Header Field".¶
This document introduces a new header field that has the same purpose, and (likely) records the same information that RFC 9228 describes, it however encourages systems to encrypt any content the header field might have, and produce and store solely BASE64[RFC4648] encoded output. Only the local system (any party owning the encryption key) will be capable to decrypt the real content in this scenario, and therefore only interested parties for which the information makes sense. This covers another aspect when cryptographically protecting email[RFC9788], for example in an end-to-end security scenario[RFC9787].¶
The syntax of the header field is:¶
"Delivered-Enc:" FWS BASE64 FWS CRLF ; BASE64 from RFC4648¶
This document would request registration of the header field name "Delivered-Enc".¶
Encrypting trace header content may improve security.¶