Fwd: RFC 9228 on Delivered-To Email Header Field
Folks, This was just issued. It will aid in evaluating handling history of a message, especially through aliasing and mailing list sequences. d/ -------- Forwarded Message -------- Subject: RFC 9228 on Delivered-To Email Header Field Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org A new Request for Comments is now available in online RFC libraries. RFC 9228 Title: Delivered-To Email Header Field Author: D. Crocker, Ed. Status: Experimental Stream: Independent Date: April 2022 Mailbox: dcrocker@bbiw.net Pages: 10 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-crocker-email-deliveredto-10.txt URL: https://www.rfc-editor.org/info/rfc9228 DOI: 10.17487/RFC9228 The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations. It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information. Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns. A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC -- Dave Crocker Brandenburg InternetWorking bbiw.net
participants (1)
-
Dave Crocker