On Tue, Jun 20, 2017 at 2:17 PM, Gene Shuman <geneshu...@gmail.com> wrote:
> 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. > I guess my question is, if the AS state is cv=fail vs cv=invalid, does the difference between these two statuses make any meaningful difference for a receiver to make a final delivery decision around a dmarc reject|quarantine? Brandon? Or is it useful later, when processing logs, to determine ARC signers who are signing improperly? If yes, then they should absolutely stay distinct states. Otherwise, maybe it's just trace information? And if so, that was the reason for the AAR, so it seems to me that's where the distinction is best catalogued. To be very clear: I'm thinking out loud here, I do not have a strong opinion one way or the other, and am very curious what the group thinks. > 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. > Oh, I agree. That's my point. From my vantage point (which could be wrong), if an invalid state does not offer any additional help to a receiver than a fail, then an AAR would never need to be parsed in-flight. However, this is a very good point and I'm sympathetic. If pulling ARC signatories who produce an invalid result end up being crucial, it's most likely way easier to do this from the AS cv= than from the AARs. > > 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? > I also don't have any better ideas. > > =Gene > > On Tue, Jun 20, 2017 at 1:44 PM, Seth Blank <s...@sethblank.com> wrote: > >> 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 >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols s...@valimail.com +1-415-894-2724 <415-894-2724>
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
