As I went through the edits for https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-5.2.1 I was unable to understand the value added by having the "arc.closest-fail" listed in the AAR.
Looking back through the list archives, the idea for this pvalue seems to have come up in mid-August, captured in this snippet: On Wed, Sep 6, 2017 at 4:02 AM, Bron Gondwana <[email protected]> wrote: > On Wed, 6 Sep 2017, at 07:52, Seth Blank wrote: > > On Mon, Aug 14, 2017 at 5:12 PM, Bron Gondwana <[email protected]> > wrote: > > That seems like it would be enough to fix that objection. An additional > "first AMS failure" header at each hop would give you a list of who > actually modified the message. > > arc.closest_fail has been defined to accomplish this. > > That looks great. It adds enough information that my other questions are > basically efficiency concerns, which are not nothing, but at least ARC > signing doesn't make things worse... > It seems that Bron is advocating a change in the verify process where by all AMS signatures would have to be checked rather than just the most recent one. Going through the archives showed me that the language in 5.2.1 should say "...the most recent AMS that fails to validate..." rather than "...the most recent AS that fails to validate..." but then the verifier actions would also need to be updated in section 6 (steps 3+). If we are only concerned with changes in the body of the message which are being introduced by intermediaries, it seems like we could just check for changes in the bh value between hops rather than requiring each verifier to walk (possibly) the whole list of AMS headers. Does this provide enough "bang for the buck" to make it worthwhile? or should we cut out this field? --Kurt
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
