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 identifiers in the message that indicate authorship, receipt, or handling, nor do they involve themselves with evaluation of the content for any sort of validity or safety.  DKIM [STD 76] defines a mechanism for associating a domain name with a message stream and validating its use, which permits evaluation of the stream with a high probability that the owner of that domain name has some responsibility for the handling of that message.

There are contemporary issues, which were not concerns at the time of STD 76 or earlier standards, that the community now seeks to address, including the following:

* There is a desire to maintain validation of a message's signing identifier across common transit and forwarding modifications.  When a message goes through a re-posting, such as through a mailing list, the validation signature typically does not survive and cannot be recovered.  Fixing this would permit a more robust evaluation of the message.

* DKIM “replay” exploits the absence of a protected recipient address, where an authorized user of a site sends a message that is signed by that site to a collaborating receiver, which then re-sends the message to other recipients not in the original set of recipients, but without any indication that the message has been re-posted.  This way, the domain name of the DKIM signature is intended to result in a positive reputation analysis that will obtain deliveries that otherwise would not succeed.

* “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 develop a new technology suite that seeks to address these concerns.  Pursuit of incremental enhancements to DKIM and/or novel applications of DKIM are preferred, but not required.  In particular, this technology will strive to:

* 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, DMARC, 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 specifying the new mechanism(s) (Standards Track)

* An Applicability Statement guiding use 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: Feb 2025

* Overview document: Mar 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