5Independent Submission D. Crocker, Ed.
6Request for Comments: 9228 Brandenburg InternetWorking
7Category: Experimental April 2022
11 Delivered-To Email Header Field
15 The address to which email is delivered might be different than any
16 of the addresses shown in any of the content header fields that were
17 created by the email's author. For example, the address used by the
18 email transport service is provided separately, such as through
19 SMTP's "RCPT TO" command, and might not match any address in the To:
20 or cc: fields. In addition, before final delivery, handling can
21 entail a sequence of submission/delivery events, using a sequence of
22 different destination addresses that (eventually) lead to the
23 recipient. As well, a receiving system's delivery process can
24 produce local address transformations.
26 It can be helpful for a message to have a common way to record each
27 delivery in such a sequence, noting each address used in the sequence
28 to that recipient, such as for (1) analyzing the path a message has
29 taken, (2) loop detection, or (3) formulating the author's address in
30 a reply message. This document defines a header field for this
33 Email handling information discloses details about the email
34 infrastructure, as well as about a particular recipient; this can
35 raise privacy concerns.
37 A header field such as this is not automatically assured of
38 widespread use. Therefore, this document is being published as an
39 Experimental RFC, looking for constituency and for operational
40 utility. This document was produced through the Independent
41 Submission Stream and was not subject to the IETF's approval process.
45 This document is not an Internet Standards Track specification; it is
46 published for examination, experimental implementation, and
49 This document defines an Experimental Protocol for the Internet
50 community. This is a contribution to the RFC Series, independently
51 of any other RFC stream. The RFC Editor has chosen to publish this
52 document at its discretion and makes no statement about its value for
53 implementation or deployment. Documents approved for publication by
54 the RFC Editor are not candidates for any level of Internet Standard;
55 see Section 2 of RFC 7841.
57 Information about the current status of this document, any errata,
58 and how to provide feedback on it may be obtained at
59 https://www.rfc-editor.org/info/rfc9228.
63 Copyright (c) 2022 IETF Trust and the persons identified as the
64 document authors. All rights reserved.
66 This document is subject to BCP 78 and the IETF Trust's Legal
67 Provisions Relating to IETF Documents
68 (https://trustee.ietf.org/license-info) in effect on the date of
69 publication of this document. Please review these documents
70 carefully, as they describe your rights and restrictions with respect
77 3. Framework & Terminology
79 5. Multi-Delivery Example
80 6. Security Considerations
81 7. IANA Considerations
84 9.1. Normative References
85 9.2. Informative References
91 The address to which email is delivered might be different than any
92 of the addresses shown in any of the content header fields
93 [Mail-Fmt], such as the To: and cc: fields that were created by the
94 author's Message User Agent (MUA) [Mail-Arch]. The address used by
95 the Message Handling Service (MHS) is provided separately, in
96 envelope information, such as through a "RCPT TO" command in [SMTP].
98 As noted in Section 4.3.3 of [Mail-Arch], 'A transfer of
99 responsibility from the MHS to a Recipient's environment (mailbox) is
100 called "delivery".' That is, when the destination address is fully
101 and successfully processed, and any additional processing is by an
102 agent working on behalf of that address, the message has been
103 delivered. Rather than placing the message into a recipient inbox or
104 otherwise completing the handling of the message, that agent might
105 create additional processing, including to one or more different
106 addresses. Each transition of responsibility, from the MHS to an
107 agent of a current addressee, constitutes a distinct delivery. Given
108 handling sequences that can include aliasing, mailing lists, and the
109 like, the transit of a message from its author to a final recipient
110 might include a series of submission/delivery events. Also, the
111 delivery process at a receiving system can produce local (internal)
112 address transformations.
114 Header fields that provide information about handling can be used
115 when assessing email traffic issues and when diagnosing specific
116 handling problems. To this end, it can be helpful for a message to
117 have a common way to indicate each delivery in the handling sequence
118 and to include each address that led to the final delivery. This can
119 aid in the analysis of a message's transit handling.
121 An additional use can be to aid in detecting a delivery sequence
122 loop, based on a specific address. With a problematic loop, the same
123 copy of a message is delivered to the same email address more than
124 once. This is different from having different copies delivered to
125 the same address, such as happens when a message is sent directly to
126 an address, as well as via a mailing list. It is also different from
127 having two copies of the same message arrive at the same, ultimate
128 destination address, having been originally posted to two different
129 addresses. Further, this is different from noting when a message
130 simply transits the same Message Transfer Agent (MTA) more than once,
131 which might be necessary, such as when it is processed through a
132 mailing list; an MTA services many addresses.
134 Delivering the same copy of a message more than once, to the same
135 address, is almost certainly not an intended activity. An example of
136 a problematic arrangement would be to send a message to mailing list
137 List-A, where List-A contains an entry for List-B, and List-B
138 contains an entry for List-A. The message will enter an infinite
139 loop. Loop detection for email can be a complicated affair. The
140 Delivered-To: header field provides helpful information, with a
141 definitive indication that this copy of a message has (already) been
142 delivered to a specific address.
144 When specifying new activity that is related to existing activity,
145 there is a choice of design approach:
147 * Seeking to change (some of) the existing behavior
149 * Adding to the activity without changing what is already being done
151 * Calling for separate, new activity
153 On the average, attempting to change existing activities is the least
154 likely to obtain adoption; it can create operational confusion
155 between old and new activities, which in turn creates resistance to
156 adoption. Seeking new activity can make sense when that activity is
157 sufficiently different and deemed sufficiently beneficial. Adding to
158 existing activity has the selling point of building upon an installed
159 base. The current specification builds upon an existing installed
160 base of Delivered-To: activity. It calls for little technical
161 enhancement; rather, it simply provides for a wider range of
166 * Email handling information, such as this, provides information
167 about the email infrastructure, as well as about the recipient.
168 Disclosure of this information might engender privacy concerns.
170 * A specification is not automatically assured of adoption or use.
171 Therefore, this document is being published as an Experimental
172 RFC, looking for extended constituency and for general operational
175 * This document was produced through the Independent RFC Stream and
176 was not subject to the IETF's approval process.
180 Ad hoc use of a Delivered-To: email header field appears to date back
181 to the 1990s, primarily for loop detection, although documentation is
182 spotty and system specific. A listing of some implementations is
185 It appears that all uses include a string in the form of an email
186 address, although at least one example has leading text that is a
187 comment about the address. In some cases, the string appears to be
188 the email transport destination address, such as the address used in
189 SMTP's "RCPT TO" command. In other cases, it appears to be the
190 result of some internal mapping at the receiving system, although
191 tending to be a variant of the transport address.
193 Email loop detection tends to be accomplished through a variety of
194 different methods, such as counting Received: header fields. These
195 methods are often combined to greater effect.
197 The Received: header field's 'for' clause is sometimes useful for
198 disclosing the recipient's address. However, the clause is not used
199 reliably, and its semantics are not thoroughly defined. Also, it
200 references an addressing value that is received but might be
201 different from the value that is ultimately used (as the result of a
202 transformation). That is, the value in a 'for' clause might be a
203 sufficient indicator of delivery addressing, but it might not.
2053. Framework & Terminology
207 Unless otherwise indicated, basic architecture and terminology used
208 in this document are taken from:
216 and syntax is specified with:
220 Normative language is per [RFC8174]:
222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
223 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
224 "MAY", and "OPTIONAL" in this document are to be interpreted as
225 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
226 appear in all capitals, as shown here.
230 The Delivered-To: header field annotates an email delivery event.
231 The header field contains information about the individual address
232 used to effect that transition.
234 * When a message is delivered, as a transition from control by the
235 MHS to the recipient's store or their agent, a Delivered-To:
236 header field SHOULD be added, with the _addr-spec_ value
237 containing the address that was used by the service to reach the
240 * If a receiving system's delivery process applies mappings or
241 transformations from the address used by the MHS to a local value,
242 this new value SHOULD also be recorded into a separate Delivered-
243 To: field when transit and processing using that address
244 successfully complete. This ensures a detailed record of the
245 sequence of handling addresses used for the message.
247 * As with some other information, each additional Delivered-To:
248 header field MUST be placed at the current 'top' of the message's
249 set of header fields -- that is, as the first header field, in a
250 fashion similar to the trace fields specified in [SMTP] (for
251 example, Section 4.1.1.4 of [SMTP]). This produces a sequence of
252 Delivered-To: header fields that represent the sequence of
253 deliveries, with the first being at the 'bottom' of the sequence
254 and the final one being at the top.
256 * As with other fields placed incrementally in this way, with each
257 added at the current top, the Delivered-To: header field MUST NOT
258 be reordered with respect to other Delivered-To: fields and those
259 other fields. This is intended to preserve the fields as
260 representing the message handling sequence.
262 The Delivered-To: header field is added at the time of delivery, when
263 responsibility for a message transitions from the Message Handling
264 Service (MHS) to an agent of the specified individual recipient
265 address. The field can also be added as a result of internal system
266 processing, to note address transformations.
268 | Note: The presence of an existing Delivered-To: header field,
269 | for the same address, typically indicates a handling loop for
270 | this instance of the message.
272 The syntax of the header field is:
276 The field records information about a single address, for one
277 recipient. See Section 6 for the privacy-related concerns about
2805. Multi-Delivery Example
282 The Delivered-To: header field can be used to document a sequence of
283 deliveries of a message. Each time an address is fully processed, a
284 Delivered-To: header field is added, recording a handling sequence,
285 with the most recent one being towards the 'top' of the sequence of
288 This example demonstrates a message traveling from its original
289 posting, through a remote group mailing list, on through an
290 independent personal aliasing mechanism, and then reaching final
291 delivery at yet another independent email provider.
293 1. Origination at com.example
295 The message, as submitted. The destination address is the
296 same as the value in the message's To: header field.
298 From: Ann Author <aauthor@com.example>
299 Date: Mon, 25 Jan 2021 18:29:06 -0500
301 Subject: [list] Sending through a list and alias
302 Sender: Ann Author <aauthor@com.example>
304 2. List processing at org.example
306 As delivered, with one Delivered-To: header field, to the list
307 processing module, which will then resubmit the message for
308 further transport to the list member "Recipient-
311 Delivered-To: list@org.example
312 Received: by submit.org.example with SMTP id i17so17480689ljn.1
313 for <list@org.example> from mail.com.example;
314 Mon, 25 Jan 2021 15:29:19 -0800 (PST)
315 Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
316 From: Ann Author <aauthor@com.example>
317 Date: Mon, 25 Jan 2021 18:29:06 -0500
319 Subject: [list] Sending through a list and alias
320 Sender: Ann Author <aauthor@com.example>
322 3. Alias processing at edu.example
324 The message, as delivered with two Delivered-To: header
325 fields, to the alias processing module, which sends the
326 message on to "theRecipient@example.net".
328 Delivered-To: Recipient-alumn@edu.example
329 Received: from mail.org.example
330 by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
331 Received: by submit.org.example;
332 Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
333 Delivered-To: list@org.example
334 Received: by submit.org.example with SMTP id i17so17480689ljn.1
335 for <list@org.example> from mail.com.example;
336 Mon, 25 Jan 2021 15:29:19 -0800 (PST)
337 Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
338 From: Ann Author <aauthor@com.example>
339 Date: Mon, 25 Jan 2021 18:29:06 -0500
341 Subject: [list] Sending through a list and alias
342 Sender: list-bounces@org.example
344 4. Final delivery to the recipient at example.net
346 The message, as finally delivered with three Delivered-To:
347 header fields, to the recipient at "theRecipient@example.net".
349 Delivered-To: theRecipient@example.net
350 Received: from mail.edu.example (mail.edu.example [4.31.198.45])
351 by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
352 Delivered-To: Recipient-alumn@edu.example
353 Received: from mail.org.example
354 by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
355 Received: by submit.org.example;
356 Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
357 Delivered-To: list@org.example
358 Received: by submit.org.example with SMTP id i17so17480689ljn.1
359 for <list@org.example> from mail.com.example;
360 Mon, 25 Jan 2021 15:29:19 -0800 (PST)
361 Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
362 From: Ann Author <aauthor@com.example>
363 Date: Mon, 25 Jan 2021 18:29:06 -0500
365 Subject: [list] Sending through a list and alias
366 Sender: list-bounces@org.example
3686. Security Considerations
370 As with Received: header fields, the presence of a Delivered-To:
371 header field discloses handling information and, possibly, personal
374 Security and privacy are essential, if challenging, topics for email
375 in general and for the handling of metadata in particular. The
376 purpose of this section is to note points of potential concern,
377 rather than to provide details for mitigation. The basic mechanism
378 described here has a long history of use, with no history of being
379 problematic. However, the expanded use described here might create
380 new scenarios that are problematic.
382 An issue specific to this mechanism is disclosure of a sequence of
383 addresses, applied to the same recipient, if a message goes through a
384 series of recipient address replacements. This document calls for
385 each of these addresses to be recorded in a separate Delivered-To:
386 field. This does not disclose addresses of other recipients, but it
387 does disclose an address-transformation handling path for the
390 This disclosure is most likely to be a concern when a recipient
391 manually forwards a message and includes all of the original header
392 fields. This will expose, to a later recipient, any intermediate
393 addresses used for getting the original message to the original
394 recipient. Such a disclosure is likely to be unintended and might be
395 (highly) problematic. Note that a basic version of this unintended
396 disclosure has long existed, by virtue of a later recipient's seeing
397 Received: header fields, but especially any with a 'for' clause.
398 However, a Delivered-To: header field sequence can disclose
399 significantly more recipient-specific handling detail.
401 An issue that is entirely implementation specific -- and therefore
402 out of scope for this document -- is that in some systems, a message
403 that is for multiple (local) recipients is stored as a single, shared
404 version. Supporting Delivered-To:, while maintaining recipient
405 privacy, creates a challenge in this case, since exposing different
406 recipient addresses to other recipients can be problematic.
4087. IANA Considerations
410 IANA has registered the Delivered-To: header field as below, per
411 [RFC3864] in the "Provisional Message Header Field Names" registry:
413 Header Field Name: Delivered-To
419 Author/Change controller: Dave Crocker
421 Specification document(s): *** This document ***
423 Related information: None.
427 Specific feedback is sought concerning:
429 * Technical issues in recording the Delivered-To: field into a
430 message, through its entire submission/delivery sequence
432 * Market interest in the uses described here
434 * Utility for the purposes described here, or for other uses
436 So the questions to answer for this Experimental RFC are:
438 * Is there demonstrated interest by MSA/MTA/MDA (Message Submission
439 Agent / Message Transfer Agent / Message Delivery Agent)
442 * If the capability is implemented and the header field generated,
443 is it used by operators or MUAs?
445 * Does the presence of the header field create any operational
448 * Does the presence of the header field demonstrate additional
451 * What specific changes to the document are needed?
453 * What other comments will aid in use of this mechanism?
455 Please send comments to ietf-smtp@ietf.org.
4599.1. Normative References
461 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
462 Specifications: ABNF", STD 68, RFC 5234,
463 DOI 10.17487/RFC5234, January 2008,
464 <https://www.rfc-editor.org/info/rfc5234>.
467 Crocker, D., "Internet Mail Architecture", RFC 5598,
468 DOI 10.17487/RFC5598, July 2009,
469 <https://www.rfc-editor.org/info/rfc5598>.
471 [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
472 DOI 10.17487/RFC5322, October 2008,
473 <https://www.rfc-editor.org/info/rfc5322>.
475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
476 Requirement Levels", BCP 14, RFC 2119,
477 DOI 10.17487/RFC2119, March 1997,
478 <https://www.rfc-editor.org/info/rfc2119>.
480 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
481 Procedures for Message Header Fields", BCP 90, RFC 3864,
482 DOI 10.17487/RFC3864, September 2004,
483 <https://www.rfc-editor.org/info/rfc3864>.
485 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
486 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
487 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
489 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
490 DOI 10.17487/RFC5321, October 2008,
491 <https://www.rfc-editor.org/info/rfc5321>.
4939.2. Informative References
495 [Prior] Dukhovni, V. and J. Levine, "The Delivered-To Message
496 Header Field", Work in Progress, Internet-Draft, draft-
497 duklev-deliveredto-01, 6 February 2022,
498 <https://datatracker.ietf.org/doc/html/draft-duklev-
503 Even a simple, narrow specification can elicit a remarkable range and
504 intensity of debate. In spite of the current document's being a case
505 of that challenge, useful discussion has taken place, first in the
506 IETF's emailcore working group mailing list, and then on the long-
507 standing ietf-smtp mailing list.
509 Helpful information and suggestions were provided by Anonymous,
510 Stéphane Bortzmeyer, Richard Clayton, Viktor Dukhovni, Adrian Farrel,
511 Ned Freed, John Klensin, Barry Leiba, Brandon Long, George
512 Michaelson, Michael Peddemors, Phil Pennock, Pete Resnick, Sam
513 Varshavchik, Alessandro Vesely, and Tim Wicinski.
517 Dave Crocker (editor)
518 Brandenburg InternetWorking
519 Email: dcrocker@bbiw.net