I support this. If the consensus is “that specific parts of the message have not been altered” should be added I’d support that, too.
laura > On 28 Nov 2022, at 02:30, Murray S. Kucherawy <[email protected]> wrote: > > Hi folks, > > Area Director hat on here: > > The discussion Barry kicked off has been interesting, but it has strayed (and > mea culpa, in part, because the material is interesting) from the work of > discussing a charter. > > I've set the stage for re-chartering in the system, and now we need some > charter text. Dave and Barry submitted text, which I've synthesized into > what's below. Let's keep this thread just to discussion the charter text; if > you want to continue to debate the technical solutions or problem space, > please start other threads or reply to the other existing ones. > > Here's my run at a charter; please provide suggestions or comments, or tell > us if you think it's ready to go. It's a variant of Barry's version with > parts of Dave's merged in. I've kept the list of candidate documents as a > starting point; the WG doesn't actually have to use any of them if that's > where consensus lands. > > But let's figure out consensus on a charter before we try to hammer out > consensus on solutions. > > -MSK > > -- > > Domain Keys Identified Mail (DKIM, RFC 6376) defines a mechanism for > using a digital signature to associate a domain identity with an email > message in a secure way, and to assure receiving domains that the message has > not been altered since the signature was created. Receiving systems > can use this information as part of their message-handling decision. > This can help reduce spam, phishing, and other unwanted or malicious > email. > > A DKIM-signed message can be re-posted, to a different set of recipients, > without > disturbing the signature's validity. This can be used to confound the > engines that > identify abusive content. RFC 6376 identified a risk of these "replay" > attacks, but > at the time did not consider this to be a problem in need of a solution. > Recently, > the community has decided that it has become enough of a problem to warrant > being revisited. > > The DKIM working group will produce one or more technical specifications that > describe the abuse and propose replay-resistant mechanisms that are compatible > with DKIM's broad deployment. The working group may produce documents > describing > relevant experimental trials first. > > Current proposals include the following drafts: > > - draft-bradshaw-envelope-validation-extension-dkim > - draft-chuang-replay-resistant-arc > - draft-gondwana-email-mailpath > - draft-kucherawy-dkim-anti-replay > > The working group may adopt or ignore these as it sees fit. > _______________________________________________ > Ietf-dkim mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Experts Laura Atkins Word to the Wise [email protected] Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
