rfc9228.original   rfc9228.txt 
Network Working Group D. Crocker, Ed. Independent Submission D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Request for Comments: 9228 Brandenburg InternetWorking
Intended status: Experimental 9 February 2022 Category: Experimental April 2022
Expires: 13 August 2022 ISSN: 2070-1721
Delivered-To Email Header Field Delivered-To Email Header Field
draft-crocker-email-deliveredto-10
Abstract Abstract
The address to which email is delivered might be different than any 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 of the addresses shown in any of the content header fields that were
created by the email's author. For example, the address used by the created by the email's author. For example, the address used by the
email transport service is provided separately, such as through email transport service is provided separately, such as through
SMTP's "RCPT TO" command, and might not match any address in the To: SMTP's "RCPT TO" command, and might not match any address in the To:
or cc: fields. In addition before final delivery, handling can or cc: fields. In addition, before final delivery, handling can
entail a sequence of submission/delivery events, using a sequence of entail a sequence of submission/delivery events, using a sequence of
different destination addresses that (eventually) lead to the different destination addresses that (eventually) lead to the
recipient. As well, a receiving system's delivery process can recipient. As well, a receiving system's delivery process can
produce local address transformations. produce local address transformations.
It can be helpful for a message to have a common way to record each It can be helpful for a message to have a common way to record each
delivery in such a sequence, and to note each address used in the delivery in such a sequence, noting each address used in the sequence
sequence to that recipient, such as for analyzing the path a message to that recipient, such as for (1) analyzing the path a message has
has taken, or for loop detection, or for formulating the author's taken, (2) loop detection, or (3) formulating the author's address in
address in a reply message. This document defines a header field for a reply message. This document defines a header field for this
this information. information.
Email handling information discloses details about the email Email handling information discloses details about the email
infrastructure, as well as about a particular recipient; this can infrastructure, as well as about a particular recipient; this can
raise privacy concerns. raise privacy concerns.
A header field such as this is not automatically assured of A header field such as this is not automatically assured of
widespread use. Therefore this is being published as an Experiment, widespread use. Therefore, this document is being published as an
looking for constituency and for operational utility. The document Experimental RFC, looking for constituency and for operational
is produced through the Independent RFC stream and was not subject to utility. This document was produced through the Independent
the IETF's approval process. Submission Stream and was not subject to the IETF's approval process.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This is a contribution to the RFC Series, independently
time. It is inappropriate to use Internet-Drafts as reference of any other RFC stream. The RFC Editor has chosen to publish this
material or to cite them other than as "work in progress." document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not candidates for any level of Internet Standard;
see Section 2 of RFC 7841.
This Internet-Draft will expire on 13 August 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9228.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background
3. Framework & Terminology . . . . . . . . . . . . . . . . . . . 5 3. Framework & Terminology
4. Delivered-To . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Delivered-To
5. Multi-delivery Example . . . . . . . . . . . . . . . . . . . 6 5. Multi-Delivery Example
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations
8. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 9 8. Experimental Goals
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.2. Informative References
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address
1. Introduction 1. Introduction
The address to which email is delivered might be different than any The address to which email is delivered might be different than any
of the addresses shown in any of the content header fields of the addresses shown in any of the content header fields
[Mail-Fmt], such as the To: and cc: fields that were created by the [Mail-Fmt], such as the To: and cc: fields that were created by the
author's Mail User Agent (MUA) [Mail-Arch]. The address used by the author's Message User Agent (MUA) [Mail-Arch]. The address used by
Message Handling Service (MHS) is provided separately, in envelope the Message Handling Service (MHS) is provided separately, in
information, such as through an "RCPT TO" command in [SMTP]. envelope information, such as through a "RCPT TO" command in [SMTP].
Delivery is a transition of responsibility for a message, from the As noted in Section 4.3.3 of [Mail-Arch], 'A transfer of
MHS, over to an agent of the destination, as represented by the responsibility from the MHS to a Recipient's environment (mailbox) is
envelope address (Section 4.3.3 [Mail-Arch]). That is, when the called "delivery".' That is, when the destination address is fully
destination address is fully and successfully processed, and any and successfully processed, and any additional processing is by an
additional processing is by an agent working on behalf of that agent working on behalf of that address, the message has been
address, the message has been delivered. Rather than placing the delivered. Rather than placing the message into a recipient inbox or
message into a recipient inbox, or otherwise completing the handling otherwise completing the handling of the message, that agent might
of the message, that agent might create additional processing, create additional processing, including to one or more different
including to one or more, different addresses. Each transition of addresses. Each transition of responsibility, from the MHS to an
responsibility, from the MHS to an agent of a current addressee, agent of a current addressee, constitutes a distinct delivery. Given
constitutes a distinct delivery. Given handling sequences that can handling sequences that can include aliasing, mailing lists, and the
include aliasing, mailing lists, and the like, the transit of a like, the transit of a message from its author to a final recipient
message from its author to a final recipient might include a series might include a series of submission/delivery events. Also, the
of submission/delivery events. Also, the delivery process at a delivery process at a receiving system can produce local (internal)
receiving system can produce local (internal) address address transformations.
transformations.
Header fields that provide information about handling can be used Header fields that provide information about handling can be used
when assessing email traffic issues and when diagnosing specific when assessing email traffic issues and when diagnosing specific
handling problems. To this end, it can be helpful for a message to handling problems. To this end, it can be helpful for a message to
have a common way of indicating each delivery in the handling have a common way to indicate each delivery in the handling sequence
sequence, and to include each address that led to the final delivery. and to include each address that led to the final delivery. This can
This can aid in the analysis of a message's transit handling. aid in the analysis of a message's transit handling.
An additional use can as be an aid in detecting a delivery sequence An additional use can be to aid in detecting a delivery sequence
loop, based on a specific address. With a problematic loop, the same loop, based on a specific address. With a problematic loop, the same
copy of a message is delivered to the same email address more than copy of a message is delivered to the same email address more than
once. This is different from having different copies delivered to once. This is different from having different copies delivered to
the same address, such as happens when a message is sent directly to the same address, such as happens when a message is sent directly to
an address, as well as via a mailing list. It is also different from an address, as well as via a mailing list. It is also different from
having two copies of the same message arrive at the same, ultimate having two copies of the same message arrive at the same, ultimate
destination address, having been originally posted to two different destination address, having been originally posted to two different
addresses. Further, this is different from noting when a message addresses. Further, this is different from noting when a message
simply transits the same MTA more than once, which might be simply transits the same Message Transfer Agent (MTA) more than once,
necessary, such as when it is processed through a mailing list; an which might be necessary, such as when it is processed through a
MTA services many addresses. mailing list; an MTA services many addresses.
Delivering the same copy of a message more than once, to the same Delivering the same copy of a message more than once, to the same
address, is almost certainly not an intended activity. An example of address, is almost certainly not an intended activity. An example of
a problematic arrangement would be to send a message to mailing list a problematic arrangement would be to send a message to mailing list
List-A, where List-A contains an entry for List-B, and List-B List-A, where List-A contains an entry for List-B, and List-B
contains an entry for List-A. The message will enter an infinite contains an entry for List-A. The message will enter an infinite
loop. Loop detection for email can be a complicated affair. The loop. Loop detection for email can be a complicated affair. The
Delivered-To: header field provides helpful information, with a Delivered-To: header field provides helpful information, with a
definitive indication that this copy of a message has (already) been definitive indication that this copy of a message has (already) been
delivered to a specific address. delivered to a specific address.
When specifying new activity that is related to existing activity, When specifying new activity that is related to existing activity,
there is a choice of design approach: there is a choice of design approach:
* Seeking to change (some) of the existing behavior * Seeking to change (some of) the existing behavior
* Adding to the activity without changing what is already being done * Adding to the activity without changing what is already being done
* Calling for separate, new activity * Calling for separate, new activity
On the average, attempting to change existing activities is the least On the average, attempting to change existing activities is the least
likely to obtain adoption; it can create operational confusion likely to obtain adoption; it can create operational confusion
between old and new activities, which in turn creates resistance to between old and new activities, which in turn creates resistance to
adoption. Seeking new activity can make sense when that activity is adoption. Seeking new activity can make sense when that activity is
sufficiently different and deemed sufficiently beneficial. Adding to sufficiently different and deemed sufficiently beneficial. Adding to
existing activity has the selling point of building upon an installed existing activity has the selling point of building upon an installed
base. The current specification builds upon an existing installed base. The current specification builds upon an existing installed
base of Delivered-To: activity. It calls for little technical base of Delivered-To: activity. It calls for little technical
enhancement, but rather, it simply provides for wider range of enhancement; rather, it simply provides for a wider range of
application. application.
Considerations: Considerations:
* Email handling information, such as this, provides information * Email handling information, such as this, provides information
about the email infrastructure, as well as about the recipient. about the email infrastructure, as well as about the recipient.
Disclosure of this information might engender privacy concerns. Disclosure of this information might engender privacy concerns.
* A specification, is not automatically assured of adoption or use. * A specification is not automatically assured of adoption or use.
Therefore it is being published as an Experiment, looking for Therefore, this document is being published as an Experimental
extended constituency and for general operational utility. RFC, looking for extended constituency and for general operational
utility.
* This document was produced through the Independent RFC stream and * This document was produced through the Independent RFC Stream and
was not subject to the IETF's approval process. was not subject to the IETF's approval process.
2. Background 2. Background
Ad hoc use of a "Delivered-To:" email header field appears to date Ad hoc use of a Delivered-To: email header field appears to date back
back to the 1990s, primarily for loop detection, although to the 1990s, primarily for loop detection, although documentation is
documentation is spotty and system-specific. A listing of some spotty and system specific. A listing of some implementations is
implementations is offered in [Prior]. offered in [Prior].
It appears that all uses include a string in the form of an email It appears that all uses include a string in the form of an email
address, although at least one example has leading text that is a address, although at least one example has leading text that is a
comment about the address. In some cases, the string appears to be comment about the address. In some cases, the string appears to be
the email transport destination address, such as used in SMTP's "RCPT the email transport destination address, such as the address used in
TO" command. In other cases, it appears to be the result of some SMTP's "RCPT TO" command. In other cases, it appears to be the
internal mapping at the receiving system, although tending to be a result of some internal mapping at the receiving system, although
variant of the transport address. tending to be a variant of the transport address.
Email loop detection tends to be accomplished through a variety of Email loop detection tends to be accomplished through a variety of
different methods, such as counting Received: header fields. These different methods, such as counting Received: header fields. These
methods are often combined to greater effect. methods are often combined to greater effect.
The Received: header field's 'for' clause is sometimes useful for The Received: header field's 'for' clause is sometimes useful for
disclosing the recipient's address. However the clause is not used disclosing the recipient's address. However, the clause is not used
reliably and its semantics are not thoroughly defined. Also it reliably, and its semantics are not thoroughly defined. Also, it
references an addressing value that is received, but might be references an addressing value that is received but might be
different from the value that is ultimately used (as the result of a different from the value that is ultimately used (as the result of a
transformation.) That is, the value in a 'for' clause might be a transformation). That is, the value in a 'for' clause might be a
sufficient indicator of delivery addressing, but it might not. sufficient indicator of delivery addressing, but it might not.
3. Framework & Terminology 3. Framework & Terminology
Unless otherwise indicated, basic architecture and terminology used Unless otherwise indicated, basic architecture and terminology used
in this document are taken from: in this document are taken from:
* [Mail-Arch] * [Mail-Arch]
* [SMTP] * [SMTP]
* [Mail-Fmt] * [Mail-Fmt]
and syntax is specified with: and syntax is specified with:
* [ABNF] * [ABNF]
Normative language, is per [RFC8174]: Normative language is per [RFC8174]:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as "MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 [RFC2119] [RFC8174] when, and only when, they described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
4. Delivered-To 4. Delivered-To
The "Delivered-To:" header field annotates an email delivery event. The Delivered-To: header field annotates an email delivery event.
The header field contains information about the individual address The header field contains information about the individual address
used to effect that transition. used to effect that transition.
* When a message is delivered, as a transition from control by the * When a message is delivered, as a transition from control by the
MHS to the recipient's store or their agent, a Delivered-To: MHS to the recipient's store or their agent, a Delivered-To:
header field SHOULD be added, with the _addr-spec_ value header field SHOULD be added, with the _addr-spec_ value
containing the address that was used by the service to reach the containing the address that was used by the service to reach the
recipient. recipient.
* If a receiving system's delivery process applies mappings or * If a receiving system's delivery process applies mappings or
transformations, from the address used by the MHS, to a local transformations from the address used by the MHS to a local value,
value, this new value SHOULD also be recorded into a separate this new value SHOULD also be recorded into a separate Delivered-
Delivered-To: field, when transit and processing using that To: field when transit and processing using that address
addresses successfully completes. This ensures a detailed record successfully complete. This ensures a detailed record of the
of the sequence of handling addresses used for the message. sequence of handling addresses used for the message.
* As with some other information, each additional Delivered-To: * As with some other information, each additional Delivered-To:
header field MUST be placed at the current 'top' of the message's header field MUST be placed at the current 'top' of the message's
set of header fields -- that is, as the first header field, in a set of header fields -- that is, as the first header field, in a
fashion similar to the trace fields specified in [SMTP], such as fashion similar to the trace fields specified in [SMTP] (for
in its Section 4.1.1.4. This produces a sequence of Delivered-To: example, Section 4.1.1.4 of [SMTP]). This produces a sequence of
header fields that represent the sequence of deliveries, with the Delivered-To: header fields that represent the sequence of
first being at the 'bottom' of the sequence and the final one deliveries, with the first being at the 'bottom' of the sequence
being at the top. and the final one being at the top.
* As with other fields placed incrementally in this way, with each * As with other fields placed incrementally in this way, with each
added at the current top, the Delivered-To: header field MUST NOT added at the current top, the Delivered-To: header field MUST NOT
be reordered with respect to other Delivered-To: fields and those be reordered with respect to other Delivered-To: fields and those
other fields. This is intended to preserve the fields as other fields. This is intended to preserve the fields as
representing the message handling sequence. representing the message handling sequence.
The Delivered-To: header field is added at the time of delivery, when The Delivered-To: header field is added at the time of delivery, when
responsibility for a message transitions from the Message Handling responsibility for a message transitions from the Message Handling
(Transport) Service (MHS) to an agent of the specified individual Service (MHS) to an agent of the specified individual recipient
recipient address. The field can also be added as a result of address. The field can also be added as a result of internal system
internal system processing, to note address transformations. processing, to note address transformations.
Note: The presence of an existing Delivered-To: header field, for | Note: The presence of an existing Delivered-To: header field,
the same address, typically indicates a handling loop for this | for the same address, typically indicates a handling loop for
instance of the message. | this instance of the message.
The syntax of the header field is: The syntax of the header field is:
"Delivered-To:" FWS addr-spec FWS CRLF ; addr-spec is from [Mail-Fmt] "Delivered-To:" FWS addr-spec FWS CRLF ; addr-spec is from [Mail-Fmt]
The field records information about a single address, for one The field records information about a single address, for one
recipient. See [Section 6] for the privacy-related concerns about recipient. See Section 6 for the privacy-related concerns about
divulging addresses. divulging addresses.
5. Multi-delivery Example 5. Multi-Delivery Example
The Delivered-To: header field can be used to document a sequence of The Delivered-To: header field can be used to document a sequence of
deliveries of a message. Each time an address is fully processed, a deliveries of a message. Each time an address is fully processed, a
Delivered-To: header field is added, recording a handling sequence, Delivered-To: header field is added, recording a handling sequence,
with the most recent one being towards the 'top' of the sequence of with the most recent one being towards the 'top' of the sequence of
header fields. header fields.
This example demonstrates a message traveling from its original This example demonstrates a message traveling from its original
posting, through a remote group mailing list, on through an posting, through a remote group mailing list, on through an
independent personal aliasing mechanism, and then reaching final independent personal aliasing mechanism, and then reaching final
delivery at yet another independent email provider. delivery at yet another independent email provider.
1. Origination @ com.example 1. Origination at com.example
The message, as submitted. The destination address is the The message, as submitted. The destination address is the
same as the value in the message's To: header field. same as the value in the message's To: header field.
From: Ann Author <aauthor@com.example> From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:00 -0500 Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example To: list@org.example
Subject: [list] Sending through a list and alias Subject: [list] Sending through a list and alias
Sender: Ann Author <aauthor@com.example> Sender: Ann Author <aauthor@com.example>
2. List @ org.example 2. List processing at org.example
As delivered, with one Delivered-To: header field, to the list As delivered, with one Delivered-To: header field, to the list
processing module, which will then re-submit the message for processing module, which will then resubmit the message for
further transport to the list member "Recipient- further transport to the list member "Recipient-
alumn@edu.example". alumn@edu.example".
Delivered-To: list@org.example Delivered-To: list@org.example
Received: by submit.org.example with SMTP id i17so17480689ljn.1 Received: by submit.org.example with SMTP id i17so17480689ljn.1
for <list@org.example> from mail.com.example; for <list@org.example> from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST) Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST) Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
From: Ann Author <aauthor@com.example> From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500 Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example To: list@org.example
Subject: [list] Sending through a list and alias Subject: [list] Sending through a list and alias
Sender: Ann Author <aauthor@com.example> Sender: Ann Author <aauthor@com.example>
3. Alias @ edu.example 3. Alias processing at edu.example
The message, as delivered with two Delivered-To: header The message, as delivered with two Delivered-To: header
fields, to the alias processing module, which sends the fields, to the alias processing module, which sends the
message on to "theRecipient@example.net". message on to "theRecipient@example.net".
Delivered-To: Recipient-alumn@edu.example Delivered-To: Recipient-alumn@edu.example
Received: from mail.org.example Received: from mail.org.example
by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
Received: by submit.org.example; Received: by submit.org.example;
Mon, 25 Jan 2021 23:29:21 +0000 (UTC) Mon, 25 Jan 2021 23:29:21 +0000 (UTC)
skipping to change at page 8, line 5 skipping to change at line 340
Received: by submit.org.example with SMTP id i17so17480689ljn.1 Received: by submit.org.example with SMTP id i17so17480689ljn.1
for <list@org.example> from mail.com.example; for <list@org.example> from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST) Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST) Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -0800 (PST)
From: Ann Author <aauthor@com.example> From: Ann Author <aauthor@com.example>
Date: Mon, 25 Jan 2021 18:29:06 -0500 Date: Mon, 25 Jan 2021 18:29:06 -0500
To: list@org.example To: list@org.example
Subject: [list] Sending through a list and alias Subject: [list] Sending through a list and alias
Sender: list-bounces@org.example Sender: list-bounces@org.example
4. Delivery @ example.net 4. Final delivery to the recipient at example.net
The message, as finally delivered with three Delivered-To: The message, as finally delivered with three Delivered-To:
header fields, to the recipient at "theRecipient@example.net". header fields, to the recipient at "theRecipient@example.net".
Delivered-To: theRecipient@example.net Delivered-To: theRecipient@example.net
Received: from mail.edu.example (mail.edu.example [4.31.198.45]) 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) by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
Delivered-To: Recipient-alumn@edu.example Delivered-To: Recipient-alumn@edu.example
Received: from mail.org.example Received: from mail.org.example
by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC) by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
skipping to change at page 8, line 40 skipping to change at line 375
As with Received: header fields, the presence of a Delivered-To: As with Received: header fields, the presence of a Delivered-To:
header field discloses handling information and, possibly, personal header field discloses handling information and, possibly, personal
information. information.
Security and privacy are essential, if challenging, topics for email Security and privacy are essential, if challenging, topics for email
in general and for the handling of metadata in particular. The in general and for the handling of metadata in particular. The
purpose of this section is to note points of potential concern, purpose of this section is to note points of potential concern,
rather than to provide details for mitigation. The basic mechanism rather than to provide details for mitigation. The basic mechanism
described here has a long history of use, with no history of being described here has a long history of use, with no history of being
problematic. However the expanded use described here might create problematic. However, the expanded use described here might create
new scenarios that are problematic. new scenarios that are problematic.
An issue specific to this mechanism is disclosure of a sequence of An issue specific to this mechanism is disclosure of a sequence of
addresses, applied to the same recipient, if a message goes through a addresses, applied to the same recipient, if a message goes through a
series of recipient address replacements. The document calls for series of recipient address replacements. This document calls for
each of these addresses to be recorded in a separate Delivered-To: each of these addresses to be recorded in a separate Delivered-To:
field. This does not disclose addresses of other recipients, but it field. This does not disclose addresses of other recipients, but it
does disclose a address-transformation handling path for the does disclose an address-transformation handling path for the
recipient. recipient.
Where this disclosure is most likely to be a concern is when a This disclosure is most likely to be a concern when a recipient
recipient manually forwards a message and includes all of the manually forwards a message and includes all of the original header
original header fields. This will expose, to a later recipient, any fields. This will expose, to a later recipient, any intermediate
intermediate addresses used for getting the original message to the addresses used for getting the original message to the original
original recipient. Such a disclosure is likely to be unintended and recipient. Such a disclosure is likely to be unintended and might be
might be (highly) problematic. Note that a basic version of this (highly) problematic. Note that a basic version of this unintended
unintended disclosure has long existed, by virtue of a later disclosure has long existed, by virtue of a later recipient's seeing
recipient's seeing Received: header fields, but especially any with a Received: header fields, but especially any with a 'for' clause.
'for' clause. However a Delivered-To: header field sequence can However, a Delivered-To: header field sequence can disclose
disclose significantly more recipient-specific handling detail. significantly more recipient-specific handling detail.
An issue that is entirely implementation specific -- and therefore An issue that is entirely implementation specific -- and therefore
out of scope to this document -- is that in some systems, a message out of scope for this document -- is that in some systems, a message
that is for multiple (local) recipients is stored as a single, shared that is for multiple (local) recipients is stored as a single, shared
version. Supporting Delivered-To:, while maintaining recipient version. Supporting Delivered-To:, while maintaining recipient
privacy, creates a challenge in this case, since exposing different privacy, creates a challenge in this case, since exposing different
recipient addresses to other recipients can be problematic. recipient addresses to other recipients can be problematic.
7. IANA Considerations 7. IANA Considerations
Registration of the "Delivered-To:" header field is requested, per IANA has registered the Delivered-To: header field as below, per
[RFC3864]: [RFC3864] in the "Provisional Message Header Field Names" registry:
Header field name: Delivered-To Header Field Name: Delivered-To
Applicable protocol: mail Protocol: mail
Status: Provisional Status: Provisional
Author/Change controller: Dave Crocker Author/Change controller: Dave Crocker
Specification document(s): *** This document *** Specification document(s): *** This document ***
Related information: None. Related information: None.
8. Experimental Goals 8. Experimental Goals
Specific feedback is sought concerning: Specific feedback is sought concerning:
* Technical issues in recording the Delivered-To: field into a * Technical issues in recording the Delivered-To: field into a
message, through its entire submission/delivery sequence message, through its entire submission/delivery sequence
* Market interest in the uses described here * Market interest in the uses described here
* Utility for the purposes described here, or for other uses * Utility for the purposes described here, or for other uses
So the questions to answer for this Experimental document are: So the questions to answer for this Experimental RFC are:
* Is there demonstrated interest by MSA/MTA/MDA developers? * Is there demonstrated interest by MSA/MTA/MDA (Message Submission
Agent / Message Transfer Agent / Message Delivery Agent)
developers?
* If the capability is implemented and the header field generated, * If the capability is implemented and the header field generated,
is it used by operators or MUAs? is it used by operators or MUAs?
* Does the presence of the header field create any operational * Does the presence of the header field create any operational
problems? problems?
* Does the presence of the header field demonstrate additional * Does the presence of the header field demonstrate additional
security issues? security issues?
* What specific changes to the document are needed? * What specific changes to the document are needed?
* What other comments will aid in use of this mechanism? * What other comments will aid in use of this mechanism?
Please send comments to ietf-smtp@ietf.org. Please send comments to ietf-smtp@ietf.org.
9. References 9. References
9.1. Normative References 9.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234,
<https://www.rfc-editor.org/rfc/rfc5234>. DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[Mail-Arch] [Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, July Crocker, D., "Internet Mail Architecture", RFC 5598,
2009, <https://www.rfc-editor.org/rfc/rfc5598>. DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322, [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <https://www.rfc-editor.org/rfc/rfc5322>. DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004,
<https://www.rfc-editor.org/info/rfc3864>. <https://www.rfc-editor.org/info/rfc3864>.
skipping to change at page 11, line 11 skipping to change at line 491
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>. <https://www.rfc-editor.org/info/rfc5321>.
9.2. Informative References 9.2. Informative References
[Prior] Dukhovni, V. and J. J. Levine, "The Delivered-To Message [Prior] Dukhovni, V. and J. Levine, "The Delivered-To Message
Header Field", I-D draft-duklev-deliveredto-00, 16 August Header Field", Work in Progress, Internet-Draft, draft-
2021. duklev-deliveredto-01, 6 February 2022,
<https://datatracker.ietf.org/doc/html/draft-duklev-
deliveredto-01>.
Appendix A. Acknowledgements Acknowledgements
Even a simple, narrow specification can elicit a remarkable range and Even a simple, narrow specification can elicit a remarkable range and
intensity of debate. In spite of the current document's being a case intensity of debate. In spite of the current document's being a case
of that challenge, useful discussion has taken place, first in the of that challenge, useful discussion has taken place, first in the
IETF's emailcore working group mailing list, and then on the long- IETF's emailcore working group mailing list, and then on the long-
standing ietf-smtp mailing list. standing ietf-smtp mailing list.
Helpful information and suggestions were provided by: Anonymous, Helpful information and suggestions were provided by Anonymous,
Richard Clayton, Viktor Dukhovni, Adrian Farrel, Ned Freed, John Stéphane Bortzmeyer, Richard Clayton, Viktor Dukhovni, Adrian Farrel,
Klensin, Barry Leiba, Brandon Long, George Michaelson, Michael Ned Freed, John Klensin, Barry Leiba, Brandon Long, George
Peddemors, Phil Pennock, Pete Resnick, Sam Varshavchik, Alessandro Michaelson, Michael Peddemors, Phil Pennock, Pete Resnick, Sam
Vesely, Tim Wicinski. Varshavchik, Alessandro Vesely, and Tim Wicinski.
Author's Address Author's Address
Dave Crocker (editor) Dave Crocker (editor)
Brandenburg InternetWorking Brandenburg InternetWorking
Email: dcrocker@bbiw.net Email: dcrocker@bbiw.net
 End of changes. 59 change blocks. 
154 lines changed or deleted 163 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/