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

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