-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the end of January Dave Crocker posted a review of the then current "-01" version of draft-gondwana-dkim2-motivation. This document has now been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over 14 (sorry) emails... ">>" is a quote from our document, ">" a quote from Dave Crocker ... lines that do not start with a ">" are me speaking. - -=-=-=-=-=-=-=-=-=-=-=-=- >> This document solves these and related problems in a holistic way, by >> having every hop in a forwarding chain responsible for: >> >> 1. verifying the path that messages have taken to get to it, >> including by being able to reverse modifications or by asserting >> that it trusts the previous hop unconditionally, and that it is >> the declared next hop in the chain. > >The term forwarding is ambiguous. It is used to mean very different types of >behavior. > > *If 'forwarding' means every MTA, this is a massive infrastructure > change to the entire Internet Mail service. * > >If it only means Intermediaries/mediators that sit between a delivery and a >new >posting, such as mailing lists, then it has the same adoption barriers as ARC, >which has proved challenging. We mean all the devices between a submission server and the machine which does final delivery. Unlike ARC a device further along the chain is able to undo any changes that have been made, reconstruct the email before those changes and then check whether the initial signature is valid. ARC provides an attestation of validity -- and in our view, doubt as to whether that attestation can be trusted creates the adoption barriers. >At the least, this is going to require very >careful attention to adoption incentives -- cost vs. benefit -- to the adopter. > >Also, Intermediaries don't do delivery. MDAs do. Again, a technical document >like this needs to use terminology carefully. Also references to email >architectural components. Here, I gather, MTA and MDA were conflated. Although MTA has entered the general discourse, many other terms defined alongside it have not. The Working Group will doubtless be able to check that we use the terms correctly in the final output, but I expect that for comprehensibility we will need to briefly explain them rather than point to a 51 page document "over there somewhere" >> 2. declaring (under protection of its own signature) where the >> message is being sent to next. > >Why? to significantly limit the scope of "DKIM replay" >> 3. asserting that it will pass control messages (including bounces, >> abuse reports and delivery notifications) back to the previous >> hop for a reasonable time. > >Asserting to whom? Why? asserting to the device to which the email is being passed and why -- because one of our aims was to enable intermediate entities (such as mailing lists and ESPs) to become aware of delivery failures. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ/l0QmHfC/FfW545EQIsgwCgkBWUHWD8bMtELS7vcEqK0KOHmSAAni+1 VdK/Hu2CiUHVur0zhEzT5k8E =9wP6 -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
