Delivered-To Email Header FieldBrandenburg InternetWorkingdcrocker@bbiw.net
Applications and Real-Time
handlingemailmhsrecipienttransportdeliverymdamtarelayheaderThe 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's author. For example, the address used by the
email transport service is provided separately, such as through SMTP's "RCPT TO" command, and might not
match any address in the To: or cc: fields. In addition before final delivery, handling can entail a
sequence of submission/delivery events, using a sequence of different destination addresses that
(eventually) lead to the recipient. As well, a receiving system's 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
note each address used in the sequence to that recipient, such as for analyzing the path a message has
taken, or for loop detection, or for formulating the author's address in a reply message. This document
defines a header field for this information.Email handling information discloses details about the email infrastructure, as well as about a
particular recipient; this can raise privacy concerns.A header field such as this is not automatically assured of widespread use. Therefore this is being
published as an Experiment, looking for constituency and for operational utility. The document is
produced through the Independent RFC stream and was not subject to the IETF's approval process.The address to which email is delivered might be different than any of the addresses shown in any of the
content header fields , such as the To: and cc: fields that were created by the
author's Mail User Agent (MUA) . The address used by the Message Handling
Service (MHS) is provided separately, in envelope information, such as through an "RCPT TO" command in
.Delivery is a transition of responsibility for a message, from the MHS, over to an agent of the
destination, as represented by the envelope address (Section 4.3.3).
That is, when the destination address is fully and successfully processed, and any additional processing
is by an agent working on behalf of that address, the message has been delivered. Rather than placing
the message into a recipient inbox, or otherwise completing the handling of the message, that agent
might create additional processing, including to one or more, different addresses. Each transition of
responsibility, from the MHS to an agent of a current addressee, constitutes a distinct delivery. Given
handling sequences that can include 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 at a receiving system can produce local (internal) address transformations. Header fields that provide information about handling can be used when assessing email traffic issues and
when diagnosing specific handling problems. To this end, 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. This can aid in the analysis of a message's transit handling. An additional use can as be an aid in detecting a delivery sequence 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
once. This is different from having different copies delivered 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
having two copies of the same message arrive at the same, ultimate destination address, having been
originally posted to two different addresses. Further, this is different from noting when a message
simply transits the same MTA more than once, which might be necessary, such as when it is processed
through a mailing list; an MTA services many addresses. Delivering the same copy of a message more than once, to the same address, is almost certainly not an
intended activity. An example of 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 contains an entry for List-A. The message
will enter an infinite loop. Loop detection for email can be a complicated affair. The Delivered-To:
header field provides helpful information, with a definitive indication that this copy of a message has
(already) been delivered to a specific address.When specifying new activity that is related to existing activity, there is a choice of design approach:
Seeking to change (some) of the existing behaviorAdding to the activity without changing what is already being doneCalling for separate, new activityOn the average, attempting to change existing activities is the least likely to obtain adoption;
it can create operational confusion between old and new activities, which in turn creates resistance to
adoption. Seeking new activity can make sense when that activity is sufficiently different and deemed
sufficiently beneficial. Adding to existing activity has the selling point of building upon an installed
base. The current specification builds upon an existing installed base of Delivered-To: activity. It
calls for little technical enhancement, but rather, it simply provides for wider range of
application.Considerations: Email handling information, such as this, provides information about the email infrastructure, as
well as about the recipient. Disclosure of this information might engender privacy concerns.A specification, is not automatically assured of adoption or use. Therefore it is being published
as an Experiment, looking for extended constituency and for general operational utility.This document was produced through the Independent RFC stream and was not subject to the IETF's
approval process.Ad hoc use of a "Delivered-To:" email header field appears to date back to the 1990s, primarily for loop
detection, although documentation is spotty and system-specific. A listing of some implementations is
offered in .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 comment about the address. In some cases, the string appears to be the email
transport destination address, such as used in SMTP's "RCPT TO" command. In other cases, it appears to
be the result of some internal mapping at the receiving system, although tending to be a variant of the
transport address.Email loop detection tends to be accomplished through a variety of different methods, such as counting
Received: header fields. These methods are often combined to greater effect. The Received: header field's 'for' clause is sometimes useful for disclosing the recipient's address.
However the clause is not used reliably and its semantics are not thoroughly defined. Also it references
an addressing value that is received, but might be 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 sufficient indicator of
delivery addressing, but it might not.Unless otherwise indicated, basic architecture and terminology used in this document are taken from: and syntax is specified with: Normative language, is per : 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 when, and only when, they appear in all capitals, as shown here.The "Delivered-To:" header field annotates an email delivery event. The header field contains information
about the individual address used to effect that transition.When a message is delivered, as a transition from control by the MHS to the recipient's store or
their agent, a Delivered-To: header field SHOULD be added, with the addr-spec
value containing the address that was used by the service to reach the recipient.If a receiving system's delivery process applies mappings or transformations, from the address
used by the MHS, to a local value, this new value SHOULD also be recorded into a separate
Delivered-To: field, when transit and processing using that addresses successfully completes.
This ensures a detailed record of the sequence of handling addresses used for the message.As with some other information, each additional Delivered-To: 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
fashion similar to the trace fields specified in , such as in its Section
4.1.1.4. This produces a sequence of Delivered-To: header fields that represent the sequence of
deliveries, 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 added 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 address. The field can also be added as a result of internal system processing, to note
address transformations.The presence of an existing Delivered-To: header field, for the same address,
typically indicates a handling loop for this instance of the message.The syntax of the header field is: "Delivered-To:" FWS addr-spec FWS CRLF ; addr-spec is from [Mail-Fmt]The field records information about a single address, for one recipient. See []
for the privacy-related concerns about divulging addresses.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 Delivered-To: header field is added, recording a handling sequence,
with the most recent one being towards the 'top' of the sequence of header fields.This example demonstrates a message traveling from its original posting, through a remote group mailing
list, on through an independent personal aliasing mechanism, and then reaching final delivery at yet
another independent email provider. Origination @ com.example The message, as submitted. The destination address is the same as the value in the
message's To: header field.
Date: Mon, 25 Jan 2021 18:29:00 -0500
To: list@org.example
Subject: [list] Sending through a list and alias
Sender: Ann Author ]]>List @ org.example As delivered, with one Delivered-To: header field, to the list processing module, which
will then re-submit the message for further transport to the list member
"Recipient-alumn@edu.example". from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -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 ]]>Alias @ edu.example The message, as delivered with two Delivered-To: header fields, to the alias processing
module, which sends the message on to "theRecipient@example.net". from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -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]]>Delivery @ example.net The message, as finally delivered with three Delivered-To: header fields, to the
recipient at "theRecipient@example.net". from mail.com.example;
Mon, 25 Jan 2021 15:29:19 -0800 (PST)
Received: by mail.com.example; Mon, 25 Jan 2021 15:29:00 -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]]>As with Received: header fields, the presence of a Delivered-To: header field discloses handling
information and, possibly, personal information.Security and privacy are essential, if challenging, topics for email in general and for the handling of
metadata in particular. The purpose of this section is to note points of potential concern, rather than
to provide details for mitigation. The basic mechanism described here has a long history of use, with no
history of being problematic. However the expanded use described here might create new scenarios that
are problematic.An issue specific to this mechanism is disclosure of a sequence of addresses, applied to the same
recipient, if a message goes through a series of recipient address replacements. The document calls for
each of these addresses to be recorded in a separate Delivered-To: field. This does not disclose
addresses of other recipients, but it does disclose a address-transformation handling path for the
recipient.Where this disclosure is most likely to be a concern is when a recipient manually forwards a message and
includes all of the original header fields. This will expose, to a later recipient, any intermediate
addresses used for getting the original message to the original recipient. Such a disclosure is likely
to be unintended and might be (highly) problematic. Note that a basic version of this unintended
disclosure has long existed, by virtue of a later recipient's seeing Received: header fields, but
especially any with a 'for' clause. However a Delivered-To: header field sequence can disclose
significantly more recipient-specific handling detail.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, since exposing different recipient addresses to other recipients can be problematic.Registration of the "Delivered-To:" header field is requested, per : Delivered-To mailProvisionalDave Crocker *** This document ***None.Specific feedback is sought concerning:Technical issues in recording the Delivered-To: field into a message, through its entire
submission/delivery sequenceMarket interest in the uses described hereUtility for the purposes described here, or for other uses So the questions to answer for this Experimental document are:Is there demonstrated interest by MSA/MTA/MDA 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. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the
specification. These words are often capitalized. This document defines these words as they
should be interpreted in IETF documents. This document specifies an Internet Best Current
Practices for the Internet Community, and requests discussion and suggestions for
improvements. Augmented BNF for Syntax Specifications: ABNFBrandenburg InternetWorkingTHUS plcInternet Message Format Qualcomm Incorporated Internet Mail ArchitectureBrandenburg InternetWorkingRegistration Procedures for Message Header Fields This specification defines registration procedures for the message header fields used by
Internet mail, HTTP, Netnews and other applications. This document specifies an Internet
Best Current Practices for the Internet Community, and requests discussion and suggestions
for improvements. Simple Mail Transfer Protocol This document is a specification of the basic protocol for Internet electronic mail
transport. It consolidates, updates, and clarifies several previous documents, making all or
parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices
for the contemporary Internet, but does not provide details about particular extensions.
Although SMTP was designed as a mail transport and delivery protocol, this specification
also contains information that is important to its use as a "mail submission" protocol for
"split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This
document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key
words have the defined special meanings. The Delivered-To Message Header FieldBloomberg LPStandcore LLCEven a simple, narrow specification can elicit a remarkable range and intensity of debate. In spite of
the current document's being a case of that challenge, useful discussion has taken place, first in the
IETF's emailcore working group mailing list, and then on the long-standing ietf-smtp mailing list.Helpful information and suggestions were provided by: Anonymous, Richard Clayton, Viktor Dukhovni, Adrian
Farrel, Ned Freed, John Klensin, Barry Leiba, Brandon Long, George Michaelson, Michael Peddemors, Phil
Pennock, Pete Resnick, Sam Varshavchik, Alessandro Vesely, Tim Wicinski.