idnits 2.17.1 draft-crocker-email-deliveredto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 112, but not defined -- Looks like a reference, but probably isn't: '1' on line 265 ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'Mail-Arch') Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Standards Track February 21, 2021 5 Expires: August 25, 2021 7 Delivered-To Email Header Field 8 draft-crocker-email-deliveredto-02 10 Abstract 12 The address to which email is delivered might be different than any 13 of the addresses shown in any of the content header fields that were 14 created by the author. The address used by the mail transport 15 service is provided separately, through an envelope SMTP "RCPT TO" 16 command. Before final delivery, handling can entail a sequence of 17 addresses that lead to the recipient. It can be helpful for a 18 message to have a common way to record each delivery in such a 19 sequence, and to include each address used for that recipient. This 20 specification defines a header field for this information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 25, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Framework & Terminology . . . . . . . . . . . . . . . . . . . 2 58 3. Delivered-To: . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Multi-hop Example . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The address to which email is delivered might be different than any 71 of the addresses shown in any of the content header fields [Mail-Fmt] 72 that were created by the author's Mail User Agent (MUA) [Mail-Arch]. 73 The address used by the Message Handling Service (MHS) is provided 74 separately, through an envelope "RCPT TO" command [SMTP]. 76 Delivery is the final processing of an envelope address, with a 77 transition of responsibility from the MHS, over to an agent 78 responsible for that address (Section 4.3.3 [Mail-Arch]). After this 79 transition there might be further, fresh processing of the message, 80 before reaching a final destination. Each transition of 81 responsibility, from the MHS to an agent of the addressee, 82 constitutes a delivery. 84 Given aliasing, mailing lists, and the like, the transit of a message 85 from its author to a final recipient might include a series of 86 submission/delivery events. It can be helpful for a message to have 87 a common way of indicating each delivery in the handling sequence, 88 and to include each address that led to the final delivery. One use 89 can be for detecting a delivery sequence loop. 91 2. Framework & Terminology 93 Unless otherwise indicated, basic architecture and terminology used 94 in this specification are taken from: 96 o [Mail-Arch] 97 o [SMTP] 99 o [Mail-Fmt] 101 and syntax is specified with: 103 o [ABNF] 105 Normative language, per [RFC8174]: 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 108 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 109 "MAY", and "OPTIONAL" in this document are to be interpreted as 110 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 111 appear in all capitals, as shown here. 113 RFC EDITOR: Remove before publication: 115 Discussion of this draft is best conducted in the: ietf- 116 smtp@ietf.org [1] mailing list. 118 3. Delivered-To: 120 This specification defines the "Delivered-To" header field, for 121 annotating a delivery event and the individual address to which 122 delivery has been effected. A sequence of deliveries, such as when a 123 message goes through multiple mailing lists, SHOULD be recorded with 124 a series of Delivered-To: header fields. As with some other 125 information, each additional Delivered-To: header field MUST be 126 placed at the current 'top' of the message -- as the first header 127 field, in a fashion similar to the trace fields specified in [SMTP], 128 such as in Section 4.1.1.4. In addition, and as with other fields 129 placed at the current top, the Delivered-To header field MUST NOT be 130 reordered, with respect to other Delivered-to fields AND those other 131 fields. 133 The Delivered-To: header field is added at the time of delivery, when 134 responsibility for a message transitions from the Message Handling 135 (Transport) Service (MHS) to an agent of the specified individual 136 recipient address. The header field contains the individual address 137 used to determine the immediate location for that transition. 139 Note: The presence of an existing Delivered-To: header field, for 140 the same Mailbox, is indicative of a handling loop. 142 Syntax of the header field is: 144 "Delivered-To:" FWS Mailbox CRLF 145 ; Mailbox is from [SMTP] 147 Note: The field records only a single address, for one recipient. 148 See Section 5 for the privacy-related concerns about divulging 149 addresses. 151 4. Multi-hop Example 153 The Delivered-To: header field can indicate a sequence of deliveries, 154 as demonstrated by this example, which has a message traveling 155 through a mailing list, on through an alias, and then reaching final 156 delivery: 158 1. Origination @ example.com 160 2. List @ example.org 162 Delivered-To: list@example.org 163 Received: by submit.example.org with SMTP id i17so17480689ljn.1 164 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 165 From: Ann Author 166 Date: Mon, 25 Jan 2021 18:29:06 -0500 167 To: list@example.org 168 Subject: [list] Sending through a list and alias 169 Sender: Ann Author 171 3. Alias @ example.edu 173 Delivered-To: Recipient-alumn@example.edu 174 Received: from mail.example.org 175 by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 176 Delivered-To: list@example.org 177 Received: by submit.example.org with SMTP id i17so17480689ljn.1 178 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 179 From: Ann Author 180 Date: Mon, 25 Jan 2021 18:29:06 -0500 181 To: list@example.org 182 Subject: [list] Sending through a list and alias 183 Sender: list-bounces@example.org 185 4. Delivery @ example.net 186 Delivered-To: theRecipient@example.net 187 Received: from mail.example.edu (mail.example.edu [4.31.198.45]) 188 by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 189 Delivered-To: Recipient-alumn@example.edu 190 Received: from mail.example.org 191 by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 192 Delivered-To: list@example.org 193 Received: by submit.example.org with SMTP id i17so17480689ljn.1 194 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 195 From: Ann Author 196 Date: Mon, 25 Jan 2021 18:29:06 -0500 197 To: list@example.org 198 Subject: [list] Sending through a list and alias 199 Sender: list-bounces@example.org 201 5. Security Considerations 203 As with Received header-fields, their presence in a message discloses 204 handling information and, possibly, personal information. 206 In some email implementations, a message that is for multiple (local) 207 recipients has a single stored version. Supporting Delivered-To:, 208 while maintaining recipient privacy, creates a challenge. However, 209 exposing different mailbox addresses to other recipients MUST NOT 210 occur. 212 An issue specific to this mechanism is disclosure of a sequence of 213 addresses, if a message goes through a series of recipient envelope 214 address modifications. The specification calls for each of these 215 addresses to be recorded in separate Delivered-To: fields. This does 216 not disclose addresses of other recipients, but it does disclose a 217 address-transformation handling path for the recipient. 219 6. IANA Considerations 221 Registration of the "Delivered-To" header field is requested, per 222 [RFC3864]: 224 Header field name:: Delivered-To 226 Applicable protocol:: mail 228 Status:: Standard 230 Author/Change controller:: IETF 232 Specification document(s): *** This document *** 233 Related information: None. 235 7. References 237 7.1. Normative References 239 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 240 Specifications: ABNF", RFC 5234, January 2008. 242 [Mail-Arch] 243 Crocker, D., "Internet Mail Architecture", RFC 5598, July 244 2009. 246 [Mail-Fmt] 247 Resnick, P., Ed., "Internet Message Format", RFC 5322, 248 October 2008. 250 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 251 Procedures for Message Header Fields", BCP 90, RFC 3864, 252 DOI 10.17487/RFC3864, September 2004, 253 . 255 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 256 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 257 May 2017, . 259 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 260 DOI 10.17487/RFC5321, October 2008, 261 . 263 7.2. URIs 265 [1] mailto:ietf-smtp@ietf.org 267 Appendix A. Acknowledgements 269 This specification was engendered by discussions in the IETF's 270 emailcore working group, although the result was outside the scope of 271 its charter. 273 Helpful comments were provided by Ned Freed, Barry Leiba, John 274 Levine, Brandon Long, Michael Peddemors, Phil Pennock, Alessandro 275 Vesely. 277 Author's Address 279 Dave Crocker (editor) 280 Brandenburg InternetWorking 282 Email: dcrocker@bbiw.net