| Internet-Draft | Delivered-Enc Email Header Field | April 2026 |
| Nurpmeso | Expires 26 October 2026 | [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, is 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 26 October 2026.¶
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 by describing 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.¶
The syntax of the header field is:¶
"Delivered-Enc:" FWS BASE64 FWS CRLF ; BASE64 from RFC4648¶
This document would request the header field name "Delivered-Enc" from IANA.¶