Background

An Internet message (email) may, from creation to final delivery, pass through multiple intermediaries, some of which simply handle and route the message, others effecting an interim delivery and re-injection into the ecosystem.  There are complexities with this handling model, such as evaluation, filtering, intentional mutation, and even malicious activities.

The core email protocols do not provide for authentication of the identities in the message or evaluation of the content for any sort of validity or safety.  DKIM [STD 76] extended the basic messaging function by providing assurance that a message was not modified between a signing agent and a verifying agent by affixing a domain-specific signature.

Still, there exist known shortcomings in the email model that DKIM alone is not designed to address, including the following:

* There is a desire to confirm that a message received truly originated from, or with the approval of, the identity claiming to have done so.  Mutations of a message in transit interfere with the validity of DKIM signatures, which stymies such efforts.  If a message is modified after DKIM signing, it is generally not possible to determine what was modified, or which agent in the handling chain made which change(s); these would be useful inputs to a more robust evaluation.

* A DKIM signature is independent of the true set of (envelope) recipients of the message, meaning that the same message and signature can be sent to arbitrarily many recipients, across one or many independent injections into the ecosystem, and those recipients can not tell if the signer intended to include them as recipients.

* “Backscatter” can result from unauthorized use of the (envelope) sender of a message, where bulk failure notifications go to an address that is not responsible for such unauthorized use.

* Service providers that generate mail on behalf of an entity have no visibility into any resulting errors, as they are sent to the entity and not the provider.

No optimal or preferred remedy to any of the above is provided by any contemporary technology.

Objectives

The working group will observe the success of current technologies, primarily DKIM, reusing its techniques where applicable, to develop a new technology suite that seeks to address these concerns.  Early experience from the deployment of ARC [RFC 8617] will also be considered.  In particular, this technology will:

* Provide stronger assurances against unauthorized use of the (envelope) sender, reducing the success of direct domain name misuse and improving the value of delivery status notifications;

* Identify message mutations made by any handling agent; and

* Attach annotations in transit of the intended chain of handling to assure accountability for each delivery.

The working group will strongly prefer output that, when deployed, does not disturb the deployed ecosystem.  It may, however, through the normal course of evolution, replace technologies such as DKIM and ARC.

To allow for widespread adoption, proposed solutions are expected to be robust in terms of interoperability and scalability.

Deliverables

The working group will produce multiple documents:

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

* One or more documents on implementation of the mechanism (Standards Track)

* An Applicability Statement guiding implementation during any deployment period, in which interoperability with existing mechanisms needs to be maintained (Standards Track)

The working group may optionally introduce the mechanism document at Experimental status first to gain operational experience before pursuing Standards Track status.

This working group will also liaise with the DMARC working group on adding its 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

[dates to be negotiated; focus on the sequence for now]

* 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