Changed to "intended to include them". -MSK
On Mon, Dec 30, 2024 at 11:02 AM Tim Wicinski <[email protected]> wrote: > 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] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
