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

Received changes through RFC Editor sync (created alias RFC 9228, changed abstract to '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, such as through SMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, 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, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) 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 privacy concerns.

A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as an Experimental RFC, looking for constituency and for operational utility. This document was produced through the Independent Submission Stream and was not subject to the IETF's approval process.', changed pages to 10, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2022-04-13, changed ISE state to Published RFC)

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-crocker-email-deliveredto-09. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will perform a single registry action.

The following entry, which has been approved by the IESG-designated expert, will be added to the Provisional Message Header Field Names registry:

Header Field Name: Delivered-To
Protocol: mail
Reference: this document

The registry is here:

https://www.iana.org/assignments/message-headers

Thank you,

Amanda Baber
IANA Operations Manager

draft-crocker-email-deliveredto has been presented to the ISE for
publication as an Experimental RFC on the Independent Stream.

==Purpose==

This document describes an email header field that an be used to
track the mailboxes that a mail has been delivered to before being
delivered to the final recipient resulting from a series of delivery/
submission events.

The DeliveredTo header field is believed to be present in a number of
implementations, but the behaviour has not been formally described
anywhere.

This document describes an experiment to determine the utility of the
DeliveredTo field and to discover whether the description here matches
implementations.

== History==

This document has some history of discussion in the IETF. There is no
active working group for this topic, and the draft started to progress
as AD sponsored (under Murray Kucherawy) before the author requested
publication in the Independent Stream with the support of the AD.

The document was first brought to the ISE in April 2021 at version -02.
Since then it has been revised several times to address review comments.

There continue to be some conflict of opinions within the IETF. See
further information at the bottom of this write-up.

==Non-IETF Work==

There is considerable risk that a document like this is mistaken for
work emanating from the IETF. To counter this, not only will the
published RFC contain the usual boilerplate, but the author has agreed
to include explicit statements in the Abstract and the Introduction that
the work does not have IETF consensus.

Further, publication as an Experiment (with all of the text explaining
the nature of the experiment) helps indicate that this is not an IETF-
recommended approach.

Additionally, the code point assignment requested (see below) is from a
registry marked "Registration of a Provisional Message Header Field does
not of itself imply any kind of endorsement by the IETF, IANA or any
other body."

==Security Considerations==

The document contains a Security Considerations section that is about
average for this kind of protocol extension. There is some concern about
the privacy implications of the extension, but these are no worse than
for many other email fields.

The privacy concern is flagged in the document Abstract and Introduction,
as well as being discussed in the Security Considerations section.

==IANA==

This document requests registration of the "Delivered-To:" header field
per RFC3864. The relevant registry is "Expert Review" and the Designated
Expert is Graham Klyne.

The request is made for a "Provisional" message header field name.

==Discussion==

There is some possibility of contention in this draft because of
disagreements between the author and other IETF participants who
pre-emptively submitted draft-duklev-deliveredto that claims to
describe "existing usage of the Delivered-To header field". One of the
authors of that document was the original document shepherd of this
draft when it was being AD sponsored.

The author of this draft has benefited fro the discussion arising
from draft-duklev-deliveredto and updated this draft accordingly. Part
of the reasoning behind making this draft experimental is to discover to
what extent implementations in the field vary from what is described in
this draft. If it turns out that this draft does not describe the
deployed base, that would be a successful result of the experiment and
would lead to a clarifying I-D.

On the other hand, draft-duklev-deliveredto and this document both
request the same code point. But while this document requests a
"Provisional" code point, draft-duklev-deliveredto asks for a
"Permanent" assignment. Neither has yet been assigned. Per RFC3864,
"Permanent" assignments need an RFC or Open Standard.

In reviewing this draft, the ISE has made an effort to ensure that this
work is respectful to other interpretations of this message header so
that it can be inclusive of all implementations.

==Reviews==

As well as reviewing the document himself, the ISE commissioned reviews
from George Michaelson and Laura Atkins. John Klensin also gave some
brief comments about internationalisation concerns, and John Levine
expressed concerns about an early version of the draft saying that other
implementations have a different interpretation of the same header
field.

The reviews led to a number of updates to fully address the issues
raised and to be more open to other possible interpretations.

Details of the reviews can be retrieved on request.

==Remaining Nits and Edits==

There is a nit with how a forward reference to Section 6 is handled.
This will be resolved before publication.