Delivered-To Email Header Field
draft-crocker-email-deliveredto-03
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Author |
|
Dave Crocker
|
|
Last updated |
|
2021-04-19
(latest revision 2021-04-18)
|
|
Stream |
|
Independent Submission
|
|
Intended RFC status |
|
Experimental
|
|
Formats |
|
plain text
xml
pdf
htmlized (tools)
htmlized
bibtex
|
| Stream |
ISE state
|
|
In ISE Review
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
Adrian Farrel
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
rfc-ise@rfc-editor.org
|
Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking
Intended status: Experimental April 18, 2021
Expires: October 20, 2021
Delivered-To Email Header Field
draft-crocker-email-deliveredto-03
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
submission/delivery events, using different destination 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.
Email handling information is a matter of modifying the email
infrastructure and possibly creating 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.
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 October 20, 2021.
Crocker Expires October 20, 2021 [Page 1]
Internet-Draft react April 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
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Framework & Terminology . . . . . . . . . . . . . . . . . . . 3
3. Delivered-To: . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Multi-hop Example . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
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,
Crocker Expires October 20, 2021 [Page 2]
Internet-Draft react April 2021
and to include each address that led to the final delivery. One use
can be for detecting a delivery sequence loop.
Email handling information is a matter of modifying the email
infrastructure and possibly creating 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.
2. Framework & Terminology
Unless otherwise indicated, basic architecture and terminology used
in this specification are taken from:
o [Mail-Arch]
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.
o 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 October 20, 2021 [Page 3]
Internet-Draft react April 2021
o 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
o 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:
"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
Crocker Expires October 20, 2021 [Page 4]
Internet-Draft react April 2021
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.
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.
Crocker Expires October 20, 2021 [Page 5]
Internet-Draft react April 2021
6. 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.
7. Experimental Goals
Specific feedback is sought concerning:
o Technical issues in recording the Delivered-To field into a
message, through its entire submission/delivery seuence
o Market interest
o Utility
So the questions to answer for this Experimental specification are:
o Is there demonstrated interest by MTA/MSA developers?
o If the capability is implemented and the header field generated,
is it used by operators or MUAs?
o Does the presence of the header field create any operational
problems?
o Does the presence of the header field demonstrate additional
security issues?
o What specific changes to the specification are needed?
o What other comments will aid in use of this mechanism?
Please send comments to ietf-smtp@ietf.org.
Crocker Expires October 20, 2021 [Page 6]
Internet-Draft react April 2021
8. References
8.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>.
8.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.
Author's Address
Dave Crocker (editor)
Brandenburg InternetWorking
Email: dcrocker@bbiw.net
Crocker Expires October 20, 2021 [Page 7]