idnits 2.17.1 draft-crocker-email-deliveredto-03.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 (April 18, 2021) is 1102 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 124, but not defined -- Looks like a reference, but probably isn't: '1' on line 312 Summary: 0 errors (**), 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: Experimental April 18, 2021 5 Expires: October 20, 2021 7 Delivered-To Email Header Field 8 draft-crocker-email-deliveredto-03 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 submission/delivery events, using different destination addresses, 18 that lead to the recipient. It can be helpful for a message to have 19 a common way to record each delivery in such a sequence, and to 20 include each address used for that recipient. This specification 21 defines a header field for this information. 23 Email handling information is a matter of modifying the email 24 infrastructure and possibly creating privacy concerns. A header 25 field such as this is not automatically assured of adoption or use. 26 Therefore it is being published as an Experiment, looking for 27 constituency and for operational utility. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 20, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Framework & Terminology . . . . . . . . . . . . . . . . . . . 3 62 3. Delivered-To: . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Multi-hop Example . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 The address to which email is delivered might be different than any 76 of the addresses shown in any of the content header fields [Mail-Fmt] 77 that were created by the author's Mail User Agent (MUA) [Mail-Arch]. 78 The address used by the Message Handling Service (MHS) is provided 79 separately, through an envelope "RCPT TO" command [SMTP]. 81 Delivery is the final processing of an envelope address, with a 82 transition of responsibility from the MHS, over to an agent 83 responsible for that address (Section 4.3.3 [Mail-Arch]). After this 84 transition there might be further, fresh processing of the message, 85 before reaching a final destination. Each transition of 86 responsibility, from the MHS to an agent of the addressee, 87 constitutes a delivery. 89 Given aliasing, mailing lists, and the like, the transit of a message 90 from its author to a final recipient might include a series of 91 submission/delivery events. It can be helpful for a message to have 92 a common way of indicating each delivery in the handling sequence, 93 and to include each address that led to the final delivery. One use 94 can be for detecting a delivery sequence loop. 96 Email handling information is a matter of modifying the email 97 infrastructure and possibly creating privacy concerns. A header 98 field such as this is not automatically assured of adoption or use. 99 Therefore it is being published as an Experiment, looking for 100 constituency and for operational utility. 102 2. Framework & Terminology 104 Unless otherwise indicated, basic architecture and terminology used 105 in this specification are taken from: 107 o [Mail-Arch] 109 o [SMTP] 111 o [Mail-Fmt] 113 and syntax is specified with: 115 o [ABNF] 117 Normative language, per [RFC8174]: 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 120 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 121 "MAY", and "OPTIONAL" in this document are to be interpreted as 122 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 123 appear in all capitals, as shown here. 125 RFC EDITOR: Remove before publication: 127 Discussion of this draft is best conducted in the ietf- 128 smtp@ietf.org [1] mailing list. 130 3. Delivered-To: 132 This specification defines the "Delivered-To" header field, for 133 annotating a delivery event and the individual address to which 134 delivery has been effected. 136 o A sequence of deliveries, such as when a message goes through 137 multiple mailing lists, SHOULD be recorded with a series of 138 Delivered-To: header fields 140 o As with some other information, each additional Delivered-To: 141 header field MUST be placed at the current 'top' of the message -- 142 as the first header field, in a fashion similar to the trace 143 fields specified in [SMTP], such as in Section 4.1.1.4 145 o As with other fields placed at the current top, the Delivered-To 146 header field MUST NOT be reordered, with respect to other 147 Delivered-to fields AND those other fields 149 The Delivered-To: header field is added at the time of delivery, when 150 responsibility for a message transitions from the Message Handling 151 (Transport) Service (MHS) to an agent of the specified individual 152 recipient address. The header field contains the individual address 153 used to determine the immediate location for that transition. 155 Note: The presence of an existing Delivered-To: header field, for 156 the same Mailbox, is indicative of a handling loop. 158 Syntax of the header field is: 160 "Delivered-To:" FWS Mailbox CRLF 161 ; Mailbox is from [SMTP] 163 Note: The field records only a single address, for one recipient. 164 See Section 5 for the privacy-related concerns about divulging 165 addresses. 167 4. Multi-hop Example 169 The Delivered-To: header field can indicate a sequence of deliveries, 170 as demonstrated by this example, which has a message traveling 171 through a mailing list, on through an alias, and then reaching final 172 delivery: 174 1. Origination @ example.com 176 2. List @ example.org 178 Delivered-To: list@example.org 179 Received: by submit.example.org with SMTP id i17so17480689ljn.1 180 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 181 From: Ann Author 182 Date: Mon, 25 Jan 2021 18:29:06 -0500 183 To: list@example.org 184 Subject: [list] Sending through a list and alias 185 Sender: Ann Author 187 3. Alias @ example.edu 188 Delivered-To: Recipient-alumn@example.edu 189 Received: from mail.example.org 190 by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 191 Delivered-To: list@example.org 192 Received: by submit.example.org with SMTP id i17so17480689ljn.1 193 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 194 From: Ann Author 195 Date: Mon, 25 Jan 2021 18:29:06 -0500 196 To: list@example.org 197 Subject: [list] Sending through a list and alias 198 Sender: list-bounces@example.org 200 4. Delivery @ example.net 202 Delivered-To: theRecipient@example.net 203 Received: from mail.example.edu (mail.example.edu [4.31.198.45]) 204 by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 205 Delivered-To: Recipient-alumn@example.edu 206 Received: from mail.example.org 207 by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) 208 Delivered-To: list@example.org 209 Received: by submit.example.org with SMTP id i17so17480689ljn.1 210 for ; Mon, 25 Jan 2021 15:29:19 -0800 (PST) 211 From: Ann Author 212 Date: Mon, 25 Jan 2021 18:29:06 -0500 213 To: list@example.org 214 Subject: [list] Sending through a list and alias 215 Sender: list-bounces@example.org 217 5. Security Considerations 219 As with Received header-fields, their presence in a message discloses 220 handling information and, possibly, personal information. 222 In some email implementations, a message that is for multiple (local) 223 recipients has a single stored version. Supporting Delivered-To:, 224 while maintaining recipient privacy, creates a challenge. However, 225 exposing different mailbox addresses to other recipients MUST NOT 226 occur. 228 An issue specific to this mechanism is disclosure of a sequence of 229 addresses, if a message goes through a series of recipient envelope 230 address modifications. The specification calls for each of these 231 addresses to be recorded in separate Delivered-To: fields. This does 232 not disclose addresses of other recipients, but it does disclose a 233 address-transformation handling path for the recipient. 235 6. IANA Considerations 237 Registration of the "Delivered-To" header field is requested, per 238 [RFC3864]: 240 Header field name: Delivered-To 242 Applicable protocol: mail 244 Status: Provisional 246 Author/Change controller: Dave Crocker 248 Specification document(s): *** This document *** 250 Related information: None. 252 7. Experimental Goals 254 Specific feedback is sought concerning: 256 o Technical issues in recording the Delivered-To field into a 257 message, through its entire submission/delivery seuence 259 o Market interest 261 o Utility 263 So the questions to answer for this Experimental specification are: 265 o Is there demonstrated interest by MTA/MSA developers? 267 o If the capability is implemented and the header field generated, 268 is it used by operators or MUAs? 270 o Does the presence of the header field create any operational 271 problems? 273 o Does the presence of the header field demonstrate additional 274 security issues? 276 o What specific changes to the specification are needed? 278 o What other comments will aid in use of this mechanism? 280 Please send comments to ietf-smtp@ietf.org. 282 8. References 284 8.1. Normative References 286 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 287 Specifications: ABNF", RFC 5234, January 2008. 289 [Mail-Arch] 290 Crocker, D., "Internet Mail Architecture", RFC 5598, July 291 2009. 293 [Mail-Fmt] 294 Resnick, P., Ed., "Internet Message Format", RFC 5322, 295 October 2008. 297 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 298 Procedures for Message Header Fields", BCP 90, RFC 3864, 299 DOI 10.17487/RFC3864, September 2004, 300 . 302 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 303 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 304 May 2017, . 306 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 307 DOI 10.17487/RFC5321, October 2008, 308 . 310 8.2. URIs 312 [1] mailto:ietf-smtp@ietf.org 314 Appendix A. Acknowledgements 316 This specification was engendered by discussions in the IETF's 317 emailcore working group, although the result was outside the scope of 318 its charter. 320 Helpful comments were provided by Ned Freed, Barry Leiba, John 321 Levine, Brandon Long, Michael Peddemors, Phil Pennock, Alessandro 322 Vesely. 324 Author's Address 326 Dave Crocker (editor) 327 Brandenburg InternetWorking 329 Email: dcrocker@bbiw.net