Delivered-To Email Header FieldBrandenburg InternetWorkingdcrocker@bbiw.net
Applications and Real-Time
handlingemailmhsrecipienttransportdeliverymdamtaThe 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 author. The
address used by the mail transport service is provided separately, through an
envelope SMTP "RCPT TO" command. Before final delivery, handling can entail a
sequence of addresses that lead to the recipient. It can be helpful for a message to
have a common way to record each delivery in such a sequence, and to include each
address used for that recipient. This specification defines a header field for this
information.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
created by the author's Mail User Agent (MUA). The address used by the Message
Handling Service (MHS) is provided separately, through an
envelope SMTP "RCPT TO" command .Delivery is the final processing of an envelope address, with a transition of
responsibility from the MHS, over to an agent responsible for that address (Section 4.3.3). After this transition there might be
further, fresh processing of the message, before reaching a final destination. Each
transition of responsibility, from the MHS to an agent acting on behalf of the
envelope address, constitutes a delivery. Given 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. It can be
helpful for a message to have a common way to record each delivery in such a
sequence, and to include each address that led to the final delivery. Unless otherwise indicated, basic architecture and terminology used in this
specification are taken from: and syntax is specified with: Normative language, 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 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.Discussion of this draft is best conducted in the: ietf-smtp mailing list.This specification defines the "Delivered-To" trace header field, for annotating a
delivery event and the address to which delivery was effected. A sequence of
deliveries, such as when a message goes through multiple mailing lists, SHOULD be
recorded with a series of Delivered-To: header fields. As with other trace
information, each additional Delivered-To header field MUST be placed at the 'top'
of the current message, per Section 4.1.1.4.The Delivered-To: header field is added at the time of delivery, when responsibility
for a message transitions from the Mail Handling (Transport) Service to an agent
acting on behalf of the specified recipient address. The header field contains the
individual address used to determine the immediate location for that transition.Syntax of the header field is: The field records only a single address, for one
recipient.Sending through a mailing list and on through an alias, traveling:Origination @ example.comList @ example.orgAlias @ example.eduDelivery @ example.netAs with Received header-fields, their presence in a message discloses handling
information and, possibly, personal information.Delivering one stored message to multiple recipients creates a challenge for
representing the separate, individual Delivered-To fields -- one for each actual
recipient -- without, exposing the different mailbox names to each other; such
exposure MUST NOT occur.An issue specific to this mechanism is disclosure of a sequence of addresses, if a
message goes through a series of recipient envelope address modifications. The
specification calls for each of these addresses to be recorded in separate
Delivered-To: fields. This does not disclose addresses of other, possible
recipients, but it does disclose a address-transformation handling path for the
recipient.Registration of the "Delivered-To" header field is requested, per : Delivered-To mail StandardIETF *** This document ***None.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. This specification was engendered by discussions in the IETF's emailcore working
group, although the result was outside the scope of its charter. Helpful comments were provided by Ned Freed, Barry Leiba, John Levine, Brandon Long,
Michael Peddemors, Phil Pennock.