]>

steffen@sdaoden.eu

General SMTP 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.

Introduction The SMTP 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 created an IETF document by describing one of the solutions used in practice, the Delivered-To Email Header Field.

Encrypting information to protect email 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 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.

Delivered-Enc The syntax of the header field is:

IANA Considerations This document would request the header field name "Delivered-Enc" from IANA.

References Normative References