Internet-Draft react February 2021
Crocker Expires 7 August 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-crocker-email-deliveredto-00
Published:
Intended Status:
Standards Track
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 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 7 August 2021.

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

2. Framework & Terminology

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

and syntax is specified with:

Normative language, per [RFC8174]:

Discussion of this draft is best conducted in the: ietf-smtp mailing list.

3. Delivered-To:

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

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:

"Delivered-To:" FWS Mailbox CRLF
Note:
The field records only a single address, for one recipient.

4. Multi-hop Example

Sending through a mailing list and on through an alias, traveling:

  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

    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.

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.

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 ***
Related information:
None.

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

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.

Author's Address

Dave Crocker (editor)
Brandenburg InternetWorking