Yeah, we certainly shouldn't be restarting the chain, and I (& I think most everyone else) concur that when it's invalid, the end. However I also don't think we should be keeping everything as fail, as invalid is pretty sematically different. And there is a clear line. cv=invalid if and only if you can't reliably produce an AS b= value, given the current rules. I think I very much agree with Kurt on wrt this line.
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. But I possibly could be convinced otherwise. 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? =Gene 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. > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
