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

Network Working Group                                    D. Crocker, Ed.
Internet-Draft                               Brandenburg InternetWorking
Intended status: Standards Track                       February 21, 2021
Expires: August 25, 2021

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

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

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 August 25, 2021.

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

Crocker                  Expires August 25, 2021                [Page 1]
Internet-Draft                    react                    February 2021

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Framework & Terminology . . . . . . . . . . . . . . . . . . .   2
   3.  Delivered-To: . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Multi-hop Example . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

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

   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 of indicating each delivery in the handling sequence,
   and to include each address that led to the final delivery.  One use
   can be for detecting a delivery sequence loop.

2.  Framework & Terminology

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

   o  [Mail-Arch]

Crocker                  Expires August 25, 2021                [Page 2]
Internet-Draft                    react                    February 2021

   o  [SMTP]

   o  [Mail-Fmt]

   and syntax is specified with:

   o  [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.

   RFC EDITOR: Remove before publication:

      Discussion of this draft is best conducted in the: ietf-
      smtp@ietf.org [1] mailing list.

3.  Delivered-To:

   This specification defines the "Delivered-To" header field, for
   annotating a delivery event and the individual address to which
   delivery has been 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 some other
   information, each additional Delivered-To: header field MUST be
   placed at the current 'top' of the message -- as the first header
   field, in a fashion similar to the trace fields specified in [SMTP],
   such as in Section 4.1.1.4.  In addition, and as with other fields
   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.

   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 header field contains the individual address
   used to determine the immediate location for that transition.

   Note:    The presence of an existing Delivered-To: header field, for
      the same Mailbox, is indicative of a handling loop.

   Syntax of the header field is:

Crocker                  Expires August 25, 2021                [Page 3]
Internet-Draft                    react                    February 2021

   "Delivered-To:" FWS Mailbox CRLF
                    ; Mailbox is from [SMTP]

   Note:    The field records only a single address, for one recipient.
      See Section 5 for the privacy-related concerns about divulging
      addresses.

4.  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 @ example.com

   2.  List @ example.org

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

   3.  Alias @ example.edu

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

   4.  Delivery @ example.net

Crocker                  Expires August 25, 2021                [Page 4]
Internet-Draft                    react                    February 2021

   Delivered-To: theRecipient@example.net
   Received: from mail.example.edu (mail.example.edu [4.31.198.45])
      by relay.example.net; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
   Delivered-To: Recipient-alumn@example.edu
   Received: from mail.example.org
      by relay.example.edu; Mon, 25 Jan 2021 23:29:24 +0000 (UTC)
   Delivered-To: list@example.org
   Received: by submit.example.org with SMTP id i17so17480689ljn.1
      for <list@example.org>; Mon, 25 Jan 2021 15:29:19 -0800 (PST)
   From: Ann Author <aauthor@example.com>
   Date: Mon, 25 Jan 2021 18:29:06 -0500
   To: list@example.org
   Subject: [list] Sending through a list and alias
   Sender: list-bounces@example.org

5.  Security Considerations

   As with Received header-fields, their presence in a message discloses
   handling information and, possibly, personal information.

   In some email implementations, a message that is for multiple (local)
   recipients has a single stored version.  Supporting Delivered-To:,
   while maintaining recipient privacy, creates a challenge.  However,
   exposing different mailbox addresses to other recipients 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 recipients, but it does disclose a
   address-transformation handling path for the recipient.

6.  IANA Considerations

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

   Header field name::    Delivered-To

    Applicable protocol::    mail

   Status::    Standard

   Author/Change controller::    IETF

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

Crocker                  Expires August 25, 2021                [Page 5]
Internet-Draft                    react                    February 2021

   Related information:    None.

7.  References

7.1.  Normative References

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008.

   [Mail-Arch]
              Crocker, D., "Internet Mail Architecture", RFC 5598, July
              2009.

   [Mail-Fmt]
              Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

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

7.2.  URIs

   [1] mailto:ietf-smtp@ietf.org

Appendix A.  Acknowledgements

   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, Alessandro
   Vesely.

Crocker                  Expires August 25, 2021                [Page 6]
Internet-Draft                    react                    February 2021

Author's Address

   Dave Crocker (editor)
   Brandenburg InternetWorking

   Email: dcrocker@bbiw.net

Crocker                  Expires August 25, 2021                [Page 7]