Brandenburg InternetWorking

dcrocker@bbiw.net

Applications and Real-Time handling email mhs recipient transport delivery mda mta 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 author. The address used by the mail transport service is provided separately, through an envelope SMTP "RCPT TO" command. Before final delivery, handling can entail a sequence of submission/delivery events, using different destination addresses, that lead to the recipient. It can be helpful for a message to have a common way to record each delivery in such a sequence, and to include each address used for that recipient. This specification defines a header field for this information. Email handling information is a matter of modifying the email infrastructure and possibly creating privacy concerns. A header field such as this is not automatically assured of adoption or use. Therefore it is being published as an Experiment, looking for constituency and for operational utility.

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 author's Mail User Agent (MUA) . The address used by the Message Handling Service (MHS) is provided separately, through an envelope "RCPT TO" command . Delivery is the final processing of an envelope address, with a transition of responsibility from the MHS, over to an agent responsible for that address (Section 4.3.3). After this transition there might be further, fresh processing of the message, before reaching a final destination. Each transition of responsibility, from the MHS to an agent of the addressee, constitutes a delivery. Given aliasing, mailing lists, and the like, the transit of a message from its author to a final recipient might include a series of submission/delivery events. It can be helpful for a message to have a common way of indicating each delivery in the handling sequence, and to include each address that led to the final delivery. One use can be for detecting a delivery sequence loop. Email handling information is a matter of modifying the email infrastructure and possibly creating privacy concerns. A header field such as this is not automatically assured of adoption or use. Therefore it is being published as an Experiment, looking for constituency and for operational utility.

Unless otherwise indicated, basic architecture and terminology used in this specification are taken from: and syntax is specified with: Normative language, per : The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. RFC EDITOR: Remove before publication: Discussion of this draft is best conducted in the ietf-smtp@ietf.org mailing list.

This specification defines the "Delivered-To" header field, for annotating a delivery event and the individual address to which delivery has been effected. A sequence of deliveries, such as when a message goes through multiple mailing lists, SHOULD be recorded with a series of Delivered-To: header fields As with some other information, each additional Delivered-To: header field MUST be placed at the current 'top' of the message -- as the first header field, in a fashion similar to the trace fields specified in , such as in Section 4.1.1.4 As with other fields placed at the current top, the Delivered-To header field MUST NOT be reordered, with respect to other Delivered-to fields AND those other fields The Delivered-To: header field is added at the time of delivery, when responsibility for a message transitions from the Message Handling (Transport) Service (MHS) to an agent of the specified individual recipient address. The header field contains the individual address used to determine the immediate location for that transition. The presence of an existing Delivered-To: header field, for the same Mailbox, is indicative of a handling loop. Syntax of the header field is:

"Delivered-To:" FWS Mailbox CRLF ; Mailbox is from [SMTP]

The field records only a single address, for one recipient. See for the privacy-related concerns about divulging addresses.

The Delivered-To: header field can indicate a sequence of deliveries, as demonstrated by this example, which has a message traveling through a mailing list, on through an alias, and then reaching final delivery: Origination @ example.com List @ example.org

; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@example.org Subject: [list] Sending through a list and alias Sender: Ann Author ]]>

Alias @ example.edu

; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@example.org Subject: [list] Sending through a list and alias Sender: list-bounces@example.org]]>

Delivery @ example.net

; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@example.org Subject: [list] Sending through a list and alias Sender: list-bounces@example.org]]>

As with Received header-fields, their presence in a message discloses handling information and, possibly, personal information. In some email implementations, a message that is for multiple (local) recipients has a single stored version. Supporting Delivered-To:, while maintaining recipient privacy, creates a challenge. However, exposing different mailbox addresses to other recipients MUST NOT occur. An issue specific to this mechanism is disclosure of a sequence of addresses, if a message goes through a series of recipient envelope address modifications. The specification calls for each of these addresses to be recorded in separate Delivered-To: fields. This does not disclose addresses of other recipients, but it does disclose a address-transformation handling path for the recipient.

Registration of the "Delivered-To" header field is requested, per : Delivered-To mail Provisional Dave Crocker *** This document *** None.

Specific feedback is sought concerning: Technical issues in recording the Delivered-To field into a message, through its entire submission/delivery seuence Market interest Utility So the questions to answer for this Experimental specification are: Is there demonstrated interest by MTA/MSA developers? If the capability is implemented and the header field generated, is it used by operators or MUAs? Does the presence of the header field create any operational problems? Does the presence of the header field demonstrate additional security issues? What specific changes to the specification are needed? What other comments will aid in use of this mechanism? Please send comments to ietf-smtp@ietf.org.

Brandenburg InternetWorking THUS plc Qualcomm Incorporated Brandenburg InternetWorking This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

This specification was engendered by discussions in the IETF's emailcore working group, although the result was outside the scope of its charter. Helpful comments were provided by Ned Freed, Barry Leiba, John Levine, Brandon Long, Michael Peddemors, Phil Pennock, Alessandro Vesely.