Background

Emails often flow indirectly through multiple systems -- at each hop potentially undergoing redirection, expansion into multiple copies via aliases and mailing lists, as well as rewriting and filtering before eventually arriving at a mailbox or being processed by a receiving software agent.

Known difficulties caused by multi-hop email delivery include:

* If a message is modified after DKIM signing, it is not possible to determine what was modified, or which hop made which changes.

* The SMTP RCPT TO address might not be present in the signed header fields of an email, meaning that the same message can be sent to arbitrarily many recipients, and those recipients can not tell if the signer intended to include them as recipients.

* Similarly, a message with the exact same DKIM signature can be legitimately received by multiple recipients at a single domain, meaning that tracking signatures is not sufficient to determine whether a message is being replayed.

* The SMTP MAIL FROM address can be forged, meaning that accepting an email and later sending a DSN to that address can cause backscatter, making it hard to perform asynchronous content analysis or delay delivery while collecting more signal; leading to the use of greylisting as a suboptimal workaround to delay making a determination.

Objectives

The working group will extend and modify the mechanisms of DKIM to address message alterations, to provide signing of the intended recipient address at each hop, and to make asynchronous delivery status notifications usable.

It will be necessary for any new design to work in parallel with the existing mechanisms, and have a clear upgrade path.

To achieve its goals, this work requires a wide scope. The group may need to supersede, modify, or replace many parts of the current email infrastructure and associated reporting mechanisms.

To allow for widespread adoption, proposed solutions will be tested for interoperability and scalability.

Deliverables

The working group will produce multiple documents, at least:

* An overview document describing the problem area and proposed mechanism (informational)

* One or more documents on implementation of the mechanism (standards track)

* A guide for implementation during the changeover period, in which interoperability with existing mechanisms needs to be maintained (informational)

This working group will also liaise with the DMARC working group on adding our specification as a new recognized authentication mechanism.  If the DMARC working group has concluded by that time, this working group can undertake that update in coordination with the responsible Area Director.

Proposed Milestones

* WG Formation: Jan 2025

* Overview document: Feb 2025

* Mechanism document draft(s): Mar 2025

* Experiments and drafts: Apr 2025 - Nov 2025

* Implementation guide: Nov 2025

* Publish documents as a group: Dec 2025