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
