On Wed, Jun 21, 2017 at 4:18 PM, Brandon Long <[email protected]> wrote:
> On Wed, Jun 21, 2017 at 2:05 PM, Kurt Andersen (b) <[email protected]> > wrote: > >> On Wed, Jun 21, 2017 at 1:53 PM, Gene Shuman <[email protected]> >> wrote: >> >>> >>> 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. >>> >> >> If you put arc=fail in an AR and then the next hop ignores and strips the >> AR (per spec), what good is it? >> > > None, but what good is the broken chain? If all you're doing is avoiding > reprocessing, that seems pretty minimal. > A message that doesn't have a chain that ends with "cv=fail" or "cv=invalid" has undetermined status. You (the receiver) now have to evaluate the chain. Why make everyone downstream of you go through that if you know it's bad? Of course, there's no reason they believe you if you say it's bad, but then what benefit do you have to lie? > > >> 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? >>> >> >> A terminal ARC-set with cv=invalid is the only way to "close" a chain and >> avoid reprocessing by each and every subsequent hop as far as I can see. >> > > Note that we don't have a temp fail, so cv=fail could just be due to DNS > being unavailable, so the next hop may actually be able to validate the > chain, assuming the failing hop was a non-modifying hop. > Should "cv=" have a way to indicate "pass up to here, but the hop that added this seal didn't/couldn't actually evaluate anything"? Maybe more importantly: Should the spec accommodate an operator that chooses to pass a message along with some chain status that isn't "pass" or "fail"? I would think that's a hole of some kind. Maybe we need to say you need to queue the message or tempfail it back out the front if you can't complete the evaluation. Would you expect the next hop to also had a cv=fail arc header that only > signs itself? > > I'm just fundamentally unclear what the utility of passing the fail state > forward is. > I suggested above that it tells the new receiver that this chain is probably not going to pass, so don't bother. There's no benefit to saying that when it's not true, or not saying it when it is. > That said, there are plenty of cv=fail which have nothing to do with the > chain structure, and could be dns or ams signature failures or whatever. > AR allows for a status that means "this couldn't be evaluated right now, and we decided to pass it along anyway". But DKIM signature evaluation is stateless from one hop to the next, so it's fine for DKIM. It's not-so-fine for ARC. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
