Hi I think V3 is worth having the IESG work over.
I made one small change s/intended to them as recipients/intended them as recipients/ tim On Sat, Dec 28, 2024 at 9:31 PM Bron Gondwana <brong= [email protected]> wrote: > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
