| Internet-Draft | react | April 2021 |
| Crocker | Expires 20 October 2021 | [Page] |
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.¶
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 20 October 2021.¶
Copyright (c) 2021 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 address to which email is delivered might be different than any of the addresses shown in any of the content header fields [Mail-Fmt] that were created by the author's Mail User Agent (MUA) [Mail-Arch]. The address used by the Message Handling Service (MHS) is provided separately, through an envelope "RCPT TO" command [SMTP].¶
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 [Mail-Arch]). 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 [RFC8174]:¶
RFC EDITOR: Remove before publication:¶
This specification defines the "Delivered-To" header field, for annotating a delivery event and the individual address to which delivery has been effected.¶
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.¶
Syntax of the header field is:¶
"Delivered-To:" FWS Mailbox CRLF
; Mailbox is from [SMTP]¶
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:¶
List @ example.org¶
Delivered-To: list@example.org Received: by submit.example.org with SMTP id i17so17480689ljn.1 for <list@example.org>; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author <aauthor@example.com> Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@example.org Subject: [list] Sending through a list and alias Sender: Ann Author <aauthor@example.com>¶
Alias @ example.edu¶
Delivered-To: Recipient-alumn@example.edu Received: from mail.example.org by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: list@example.org Received: by submit.example.org with SMTP id i17so17480689ljn.1 for <list@example.org>; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author <aauthor@example.com> 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¶
Delivered-To: theRecipient@example.net Received: from mail.example.edu (mail.example.edu [4.31.198.45]) by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: Recipient-alumn@example.edu Received: from mail.example.org by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: list@example.org Received: by submit.example.org with SMTP id i17so17480689ljn.1 for <list@example.org>; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author <aauthor@example.com> 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 [RFC3864]:¶
Specific feedback is sought concerning:¶
So the questions to answer for this Experimental specification are:¶
Please send comments to ietf-smtp@ietf.org.¶
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.¶