Based on Dave and Murray's comments in particular, here's another take! Key Changes: • Removed milestone dates • Simplified a lot of the supporting text • No mention of "trust relationships" • Used the words "hop" and "hops" to align with the terminology in RFC5322. • Detailed known issues, and specified the three major issues being addressed explicitly: modifications, lack of signature on recipient, lack of signature on sender/bounce address. The detail of known issues is maybe a bit wordy - would be happy to see tighter text proposals.
Again - the original is at: https://notes.ietf.org/YGynIPpYS7yqg5G7ZeSQeA?both Cheers, Bron. DKIM2 Draft Charter 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 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: • 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 our specification as a new recognized authentication mechanism. Milestones • Overview document adopted • Mechanism document draft(s) adopted • Experiments and updated drafts • Implementation guide adopted • Group of related documents sent to IESG -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
