OK, so we've spoken with Brandon a bit about this in person, and we're still a bit unclear about the resolution of this issue.
It seems we have two choices available to us upon receipt of an invalid chain(which is defined as AS b= unable to be computed). 1. Simply stop adding further ARC headers. Put arc=fail(or invalid) in the AR. Further recipients will detect that the chain is broken as well, for the same reasons. This is clearly the easiest solution. 2. Add one further ARC-Set with an explicit cv=invalid in order to 'close' the chain, using the rule that Kurt has suggested. This seems to have some benefit to me, but it's minimal. It seems to wrap things up nicely, and it means that all ARC chains have a well defined cv value, which makes testing a little easier. However the cost is clearly added complexity, both in the spec and implementations. Is there any other tangible value to adding this final ARC-Set? Does it help identify the failure point in the chain? Is there any other benefit? Kurt, can you speak to this? =Gene On Tue, Jun 20, 2017 at 7:08 PM, Kurt Andersen (b) <[email protected]> wrote: > Formerly, On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank <[email protected]> > wrote: > >> On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long <[email protected]> wrote: >> >>> The google implementation pre-dates cv=invalid, and when I went to >>> implement it, I couldn't find a good reason to do so, nor a great >>> bright-line rule for how to differentiate the two. >>> >>> I don't see the point of trying to continue the chain after a cv=fail, >>> so having a mechanism to do so, and the possibly complicated rules >>> associated with it, seem pointless. >>> >> >> Are you suggesting that we remove cv=invalid and leave everything under >> cv=fail, because that's all that matters to transmit downstream via the AS? >> >> And then, if someone wants to really make it clear what happened, that >> could be stamped in an A-R header like "arc=fail (invalid ARC set at i=3: >> too many headers)"? Or do you think at this juncture, in the A-R >> "arc=invalid" makes sense like "arc=invalid (missing AS for i=2)" to >> differentiate ARC set failures from all other failures? >> >> The alternative would be to strip the arc-set entirely and start fresh. >>> That seems to have minor benefit, so I didn't implement that, either, but I >>> could imagine doing that if some useful case came up. This is also >>> strictly more useful than trying to persist an invalid chain. I could see >>> a cv=restart as an equivalent to cv=none for this type of case, I guess. >>> >> >> I think "restarting" an ARC chain makes no sense. If the chain breaks, >> it's broken. Custody's been lost and you don't get to show up with a new >> message. >> >> > On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman <[email protected]> > replied: > >> >> Also, I don't think we should be relying on the contents of AR header >> fields to make determinations about ARC chains. It seems off to me to have >> to parse all AR headers to look for an arc=invalid or whatever to decide >> how to handle your ARC messages. >> > > I agree with Seth that putting this info into the AAR headers is not the > right approach. > > >> This leaves us with the option of sticking cv=invalid in the AS, and >> still the open question of if and how to generate the AS b= tag. Kurt's >> suggestion seems totally fine, although slightly awkward. Not sure I have >> any better ideas though. What is the value of creating this signature, as >> opposed to just not & relying solely on our AMS? I guess we are signing >> our new AAR then, which is worth something? >> > > Yes, you are signing your AAR and AMS (much like the i=1 ARC signer is > doing) attesting to the state of the message when you handled it. You can't > really say anything about previous handlers except that any traces of their > work has been thoroughly trashed. > > --Kurt > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
