Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Intended status: Experimental 4 August 2021 Expires: 5 February 2022 Delivered-To Email Header Field draft-crocker-email-deliveredto-05 Abstract 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 author. The address used by the email 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. Also, the 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, and to include each address used for that recipient. This document 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 document is produced through the Independent RFC stream and was not subject to the IETF's approval process. Status of This Memo 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 5 February 2022. Crocker Expires 5 February 2022 [Page 1] Internet-Draft react August 2021 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Framework & Terminology . . . . . . . . . . . . . . . . . . . 3 3. Delivered-To . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multi-hop Example . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction 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. Crocker Expires 5 February 2022 [Page 2] Internet-Draft react August 2021 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. Also, the delivery process can produce local address transformations. 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. Delivering the same message more than once to the same address is almost certainly not an intended activity. 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 document is produced through the Independent RFC stream and was not subject to the IETF's approval process. 2. Framework & Terminology Unless otherwise indicated, basic architecture and terminology used in this document are taken from: * [Mail-Arch] * [SMTP] * [Mail-Fmt] and syntax is specified with: * [ABNF] Normative language, per [RFC8174]: 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. Discussion of this experiment is best conducted in the ietf- smtp@ietf.org (mailto:ietf-smtp@ietf.org) mailing list. Crocker Expires 5 February 2022 [Page 3] Internet-Draft react August 2021 3. Delivered-To This document defines the "Delivered-To" header field, for annotating am email delivery event and the individual mailbox 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 [SMTP], such as in Section 4.1.1.4. This produces a sequence of Delivered-To header fields that represent the delivery handling sequence, with the first being at the 'bottom' of the sequence and the final one being at the top * As with other fields placed incrementally in this way, with each 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. This is intended to preserve the fields as representing the message handling sequence. 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 mailbox. The header field contains information about the individual mailbox that is used to determine the immediate location for that transition. Note: The presence of an existing Delivered-To header field, for the same Mailbox, is indicative of a handling loop. The syntax of the header field is: "Delivered-To:" FWS *phrase Mailbox *phrase CRLF ; Mailbox is from [SMTP] Note: The field records only a single mailbox, for one recipient. See Section 5 for the privacy-related concerns about divulging mailboxes. Crocker Expires 5 February 2022 [Page 4] Internet-Draft react August 2021 4. Multi-hop Example 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: 1. Origination @ com.example 2. List @ org.example Delivered-To: list@org.example Received: by submit.org.example with SMTP id i17so17480689ljn.1 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@org.example Subject: [list] Sending through a list and alias Sender: Ann Author 3. Alias @ edu.example Delivered-To: Recipient-alumn@edu.example Received: from mail.org.example by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: list@org.example Received: by submit.org.example with SMTP id i17so17480689ljn.1 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@org.example Subject: [list] Sending through a list and alias Sender: list-bounces@org.example 4. Delivery @ example.net Crocker Expires 5 February 2022 [Page 5] Internet-Draft react August 2021 Delivered-To: theRecipient@example.net Received: from mail.edu.example (mail.edu.example [4.31.198.45]) by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: Recipient-alumn@edu.example Received: from mail.org.example by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) Delivered-To: list@org.example Received: by submit.org.example with SMTP id i17so17480689ljn.1 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) From: Ann Author Date: Mon, 25 Jan 2021 18:29:06 -0500 To: list@org.example Subject: [list] Sending through a list and alias Sender: list-bounces@org.example 5. Security Considerations As with Received header-fields, their presence in a message discloses handling information and, possibly, personal information. An issue that is entirely implementation specific, and therefore out of scope to this document, is that in some systems, a message that is for multiple (local) recipients is stored as a single, shared version. Supporting Delivered-To, while maintaining recipient privacy, creates a challenge in this case. However, exposing different mailboxes to other recipients MUST NOT occur. An issue specific to this mechanism is disclosure of a sequence of mailboxes, if a message goes through a series of recipient envelope mailbox modifications. The document calls for each of these mailboxes to be recorded in separate Delivered-To fields. This does not disclose mailboxes of other recipients, but it does disclose a mailbox-transformation handling path for the recipient. 6. IANA Considerations Registration of the "Delivered-To" header field is requested, per [RFC3864]: Header field name: Delivered-To Applicable protocol: mail Status: Provisional Author/Change controller: Dave Crocker Specification document(s): *** This document *** Crocker Expires 5 February 2022 [Page 6] Internet-Draft react August 2021 Related information: None. 7. Experimental Goals Specific feedback is sought concerning: * Technical issues in recording the Delivered-To field into a message, through its entire submission/delivery sequence * Market interest * Utility So the questions to answer for this Experimental document 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 document are needed? * What other comments will aid in use of this mechanism? Please send comments to ietf-smtp@ietf.org. 8. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, . [Mail-Arch] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, . [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008, . Crocker Expires 5 February 2022 [Page 7] Internet-Draft react August 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . Appendix A. Acknowledgements 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 Adrian Farrel, Ned Freed, Barry Leiba, John Levine, Brandon Long, Michael Peddemors, Phil Pennock, Alessandro Vesely. Author's Address Dave Crocker (editor) Brandenburg InternetWorking Email: dcrocker@bbiw.net Crocker Expires 5 February 2022 [Page 8]