Need a new IANA registry of header fields that are Ok to add during submission/relay/delivery

[ietf-svn-bot]

keyword_SMTP owner:alexey.melnikov@isode.com type_task | by alexey.melnikov@isode.com

---

Ned Freed wrote:

There are many fields that get added after submission and before final delivery. And not all of them really qualify as "trace" IMO.

Moreover, making a list of these fields is a hopeless task, since all it takes is one more document to outdate the list.

I see two possible solutions:

(1) Craft some text saying something like, "Only add fields specified as OK to be added in other specifications."

(2) Create a registry.

I kind of like the idea of a registry, but it is a fair bit more work.

---

Issue migrated from trac:8 at 2022-01-31 12:33:44 +0000

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

John Levine wrote:

Sounds like a new column or two in the existing Message Headers registry, with options like "trace", "add once", and "add multiple".

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

John Klensin wrote in response to Ned Freed:

Are you thinking about some sort of FCFS or DE-type registry or requiring that the IETF do a serious review and grant permission?

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

John Levine wrote:

On Thu, 8 Oct 2020, Ned Freed wrote:

That sounds like the right way to handle it, but this is just a registration organization detail. The hard part is writing the text explinaing the criteria for giving agents permission to add a field to a message as it transits the infrastructure.

Given that mail systems add headers with wild abandon, it would be nice to have some guardrails to point to. We might have to distinguish between headers added in final delivery and those added during relay, since there's a lot more of the former but they matter less.

I'm also wondering how much work it's worth to try to catalog existing practice. For example, "Delivered-To" has been a widely used trace header at least since qmail came out in 1998, it's used as an example in RFCs 5293, 7681, and 8904, but it's not in any registry.

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Dave Crocker wrote:

The wild abandon includes lack of clarity about role.

Having a registry that distinguishes among submission, transfer, and delivery roles could helpful. (hope spring eternal, even during the Fall.)

I'd suggest separation of the registry creation effort from the registry populating effort, so that the latter is out of the critical path and can even be done in increments.

[ietf-svn-bot]

@alexey.melnikov@isode.com set owner to alexey.melnikov@isode.com

[ietf-svn-bot]

@alexey.melnikov@isode.com changed type from defect to task

[ietf-svn-bot]

@alexey.melnikov@isode.com set component to email-applicability-statement

[ietf-svn-bot]

@alexey.melnikov@isode.com changed title from Need a registry of header fields that are Ok to add after submission to Need a new IANA registry of header fields that are Ok to add after submission

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Based on the IETF 109 discussion there seem to be some support for doing this in the A/S document.

[ietf-svn-bot]

@vesely@tana.it commented

---

Discussion: https://mailarchive.ietf.org/arch/msg/emailcore/0xZ4j99gKjqjZAsFlP1d8MNJK1I

[ietf-svn-bot]

@alexey.melnikov@isode.com changed title from Need a new IANA registry of header fields that are Ok to add after submission to Need a new IANA registry of header fields that are Ok to add during submission/relay/delivery

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Updated proposal for text to include in the IANA Considerations:

https://mailarchive.ietf.org/arch/msg/emailcore/Zsc_RrIRuIF3uiCW1UhmKNDetv8/

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Also add MUA as per Dave Crocker?

[aamelnikov]

No energy to complete this and disagreement between major proponents on the purpose of this registry.