Internet-Draft react August 2021
Crocker Expires 28 February 2022 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-crocker-email-deliveredto-08
Published:
Intended Status:
Experimental
Expires:
Author:
D. Crocker, Ed.
Brandenburg InternetWorking

Delivered-To Email Header Field

Abstract

The address to which email is delivered might be different than any of the addresses shown in any of the content header fields, 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. Before final delivery, handling can entail a sequence of submission/delivery events, using different destination addresses that lead to the recipient. Also, 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 include each address used for that recipient, such as for analyzing the path a message has taken, 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 possible 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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 28 February 2022.

Table of Contents

1. Introduction

The address to which email is delivered might be different than any of the addresses shown in any of the content header fields [Mail-Fmt], created by the author's Mail User Agent (MUA) [Mail-Arch]. The address used by the Message Handling Service (MHS) is provided separately, in envelope information, such as through an "RCPT TO" command in [SMTP].

Delivery is a transition of responsibility for a message, from the MHS, over to an agent of the destination represented by the envelope address (Section 4.3.3 [Mail-Arch]). Each transition of responsibility, from the MHS to an agent of the 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 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. With a loop, the same copy of a message transits the same email address more than once. This is different from having the message simply transit 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. It is also different from having two copies of the same message arrive at the same, ultimate destination, having been originally posted to two different 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.

Considerations:

2. Background

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 [Prior].

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.

3. Framework & Terminology

Unless otherwise indicated, basic architecture and terminology used in this document are taken from:

and syntax is specified with:

Normative language, per [RFC8174]:

4. Delivered-To

This defines the "Delivered-To" header field, for annotating an email delivery event. The header field contains information about the individual address used to effect that transition.

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.

Note:
The presence of an existing Delivered-To header field, for the same address, is indicative of 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 only a single address, for one recipient. See Section 6 for the privacy-related concerns about divulging addresses.

5. Multi-hop Example

The Delivered-To header field can indicate a sequence of deliveries, as demonstrated by this example, which has a message traveling through a mailing list, on through an alias, and then reaching final delivery:

  1. Origination @ com.example
  2. List @ org.example

    Delivered-To: list@org.example
    Received: by submit.org.example with SMTP id i17so17480689ljn.1
       for <list@org.example>; Mon, 25 Jan 2021 15:29:19 -0800 (PST)
    From: Ann Author <aauthor@com.example>
    Date: Mon, 25 Jan 2021 18:29:06 -0500
    To: list@org.example
    Subject: [list] Sending through a list and alias
    Sender: Ann Author <aauthor@com.example>
  3. Alias @ edu.example

    Delivered-To: Recipient-alumn@edu.example
    Received: from mail.org.example
       by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
    Delivered-To: list@org.example
    Received: by submit.org.example with SMTP id i17so17480689ljn.1
       for <list@org.example>; Mon, 25 Jan 2021 15:29:19 -0800 (PST)
    From: Ann Author <aauthor@com.example>
    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
  4. Delivery @ example.net

    Delivered-To: theRecipient@example.net
    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)
    Delivered-To: Recipient-alumn@edu.example
    Received: from mail.org.example
       by relay.edu.example; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
    Delivered-To: list@org.example
    Received: by submit.org.example with SMTP id i17so17480689ljn.1
       for <list@org.example>; Mon, 25 Jan 2021 15:29:19 -0800 (PST)
    From: Ann Author <aauthor@com.example>
    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

6. Security Considerations

As with Received header fields, the presence of a Delivered-To header field discloses handling information and, possibly, personal information.

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.

An issue specific to this mechanism is disclosure of a sequence of addresses, if a message goes through a series of recipient address modifications. The document calls for each of these addresses to be recorded in separate Delivered-To fields. This does not disclose addresses of other recipients, but it does disclose a address-transformation handling path for the recipient.

7. IANA Considerations

Registration of the "Delivered-To" header field is requested, per [RFC3864]:

8. Experimental Goals

Specific feedback is sought concerning:

So the questions to answer for this Experimental document are:

Please send comments to ietf-smtp@ietf.org.

9. References

9.1. Normative References

[ABNF]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
[Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, , <https://www.rfc-editor.org/rfc/rfc5598>.
[Mail-Fmt]
Resnick, P., Ed., "Internet Message Format", RFC 5322, , <https://www.rfc-editor.org/rfc/rfc5322>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, , <https://www.rfc-editor.org/info/rfc3864>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[SMTP]
Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, , <https://www.rfc-editor.org/info/rfc5321>.

9.2. Informative References

[Prior]
Dukhovni, V. and J. J. Levine, "The Delivered-To Message Header Field", I-D draft-duklev-deliveredto-00, .

Appendix A. Acknowledgements

Even 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: Richard Clayton, Viktor Dukhovni, Ned Freed, John Klensin, John Levine, Brandon Long, George Michaelson, Michael Peddemors, Phil Pennock, Pete Resnick, Sam Varshavchik, Alessandro Vesely, Tim Wicinski.

Author's Address

Dave Crocker (editor)
Brandenburg InternetWorking