Background

Emails often flow indirectly through multiple systems, 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.

DKIM gives us a way to detect that the content of a message was not altered between the signing domain and its eventual destination. Several attempts have been made to address the issues that arise with with alterations made by intermediate systems. For various reasons, these technologies have failed to provide the information to reliably distinguish between legitimate mail, and replay or alteration of messages by bad actors.

Objectives

This working group will take a holistic approach to the underlying problems of alterations, error handling, and trust relationships between the systems involved in handling an email -- from its inception to arrival at its final destination.

The working group will use the mechanisms of DKIM as a basis, extending and modifying them to solve problems that have been identified in real-world usage.

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

To achieve its goals, this work requires a wide scope. The design may supersede, modify, or replace many parts of the current email infrastructure and associated reporting mechanisms -- while retaining the ability to support the same use-cases.

Deliverables

To gain widespread adoption, it is expected that proposals will be tested during the development of specifications. The working group will favor designs that have been tested for interoperability at scale.

This working group will produce multiple documents, at least:

* A 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 this as a recognised authentication mechanism.

Proposed Milestones

* WG Formation: Dec 2024
* Overview document: Jan 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