Delivered-To Email Header Field
draft-crocker-email-deliveredto-06

Network Working Group                                    D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Intended status: Experimental                             13 August 2021
Expires: 14 February 2022

                    Delivered-To Email Header Field
                   draft-crocker-email-deliveredto-06

Abstract

   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 email's author.  For example, the address used by the
   email transport service is provided separately, through an envelope
   SMTP "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, the 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/.

Crocker                 Expires 14 February 2022                [Page 1]
Internet-Draft                    react                      August 2021

   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 14 February 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Framework & Terminology . . . . . . . . . . . . . . . . . . .   4
   4.  Delivered-To  . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Multi-hop Example . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Experimental Goals  . . . . . . . . . . . . . . . . . . . . .   7
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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]
   that were created by the author's Mail User Agent (MUA) [Mail-Arch].
   The address used by the Message Handling Service (MHS) is provided
   separately, typically through an envelope "RCPT TO" command [SMTP].

   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 [Mail-Arch]).  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 of the addressee,
   constitutes a delivery.

Crocker                 Expires 14 February 2022                [Page 2]
Internet-Draft                    react                      August 2021

   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.  Also, the delivery process can produce
   local address transformations.  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 an aid in detecting a delivery sequence
   loop.  With a loop, the same copy of a messages 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
   listA, where listA contains an entry for listB, and listB contains an
   entry for listA.  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 been delivered to a
   specific address.

   Email handling information, such as this, provides information about
   the email infrastructure, as well as about the recipient; disclosure
   of this information might entail privacy concerns.  A header field
   such as this is not automatically assured of adoption or use.
   Therefore it is being published as an Experiment, looking for
   constituency and for operational utility.  This document is produced
   through the Independent RFC stream and was not subject to the IETF's
   approval process.

2.  Background

   Ad hoc use of a "Delivered-To" email header field appears to date
   back to the 1990s, although documentation is spotty and system-
   specific.  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.  In other cases, it
   appears to be the result of some internal mapping, although tending
   to be a variant of the transport address.

Crocker                 Expires 14 February 2022                [Page 3]
Internet-Draft                    react                      August 2021

   Email loop detection tends to be accomplished through a variety of
   different methods, such as counting Received: header fields.  These
   methods are often combined for 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:

   *  [Mail-Arch]

   *  [SMTP]

   *  [Mail-Fmt]

   and syntax is specified with:

   *  [ABNF]

   Normative language, per [RFC8174]:

      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.

4.  Delivered-To

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

   *  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.

Crocker                 Expires 14 February 2022                [Page 4]
Internet-Draft                    react                      August 2021

   *  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 [SMTP], such as
      in Section 4.1.1.4.  This produces a sequence of Delivered-To
      header fields that represent the delivery handling sequence, 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
      placed 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.

   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

Crocker                 Expires 14 February 2022                [Page 5]
Internet-Draft                    react                      August 2021

      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.

Crocker                 Expires 14 February 2022                [Page 6]
Internet-Draft                    react                      August 2021

   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.  However, exposing
   different addresses to other recipients is usually 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]:

      Header field name:  Delivered-To

      Applicable protocol:  mail

      Status:  Provisional

      Author/Change controller:  Dave Crocker

      Specification document(s):  *** This document ***

      Related information:  None.

8.  Experimental Goals

   Specific feedback is sought concerning:

   *  Technical issues in recording the Delivered-To field into a
      message, through its entire submission/delivery sequence

   *  Market interest

   *  Utility

   So the questions to answer for this Experimental document are:

   *  Is there demonstrated interest by MTA/MSA developers?

   *  If the capability is implemented and the header field generated,
      is it used by operators or MUAs?

Crocker                 Expires 14 February 2022                [Page 7]
Internet-Draft                    react                      August 2021

   *  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.

9.  Normative References

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [Mail-Arch]
              Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009, <https://www.rfc-editor.org/rfc/rfc5598>.

   [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008, <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, March 1997,
              <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, September 2004,
              <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,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

Crocker                 Expires 14 February 2022                [Page 8]
Internet-Draft                    react                      August 2021

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

   Email: dcrocker@bbiw.net

Crocker                 Expires 14 February 2022                [Page 9]