On Tue, Jun 20, 2017 at 1:18 PM, Brandon Long <bl...@google.com> 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
