Hi all - it looks like no other responses all week! I'm going to merge your ideas.
Given there are no other comments - Murray, are we ready to take this to IESG? Updates still at: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA And I've posted the whole thing at the end... >> 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 > > s/us/message systems/ (or something more neutral than 'us') I went with "DKIM provides a way" - removed "us" entirely. > s/arise with with/arise with/ <- fixed in raw copy Appreciate it. >> 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. > > s/problems of alterations/problems of message alterations/ Taken as is. >> >> >> 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. > > s/clean/clear/ ? Sure. I can see either, or "robust" - I went with clear, it's.... clear. >> >> >> 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. > > "same use-cases" - could this be "existing use-cases"? Yes, that's better. Have done. >> 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. > > s/proposals/proposed solutions/ I have made that change, and also `s/that have been/which have been/` because it reads a little nicer. > > s/Mechinism/Mechanism/ <- fixed in raw copy Sweet, thanks. > These dates are too tight but that's for others. What we do want to say is > that the problem overview document be adopted etc by some date. I've rewritten them slightly to separate adoption; updates; and sending to IESG rather than "publishing". Cheers, Bron. DKIM2 Draft Charter 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 provides 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 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 message 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 clear 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 existing use-cases. Deliverables To gain widespread adoption, it is expected that proposed solutions will be tested during the development of specifications. The working group will favor designs which 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. Milestones • WG Formation: Dec 2024 • Overview document adopted: Jan 2025 • Mechanism document draft(s) adopted: Mar 2025 • Experiments and updated drafts: Apr 2025 - Nov 2025 • Implementation guide adopted: Nov 2025 • Group of documents sent to IESG: Dec 2025 -- Bron Gondwana, CEO, Fastmail Pty Ltd br...@fastmailteam.com
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
