Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-05.txt

From: Gene Shuman <[email-masked]>
Date: Fri, 7 Jul 2017 15:34:38 -0700

I think there's still something missing from the draft wrt fail/invalid.
In section 5.2.2, it says that gross violations MUST be capped in the
manner specified. This seems to only encompass what we were previously
considering cv=invalid.  Does it say somewhere that cv=fail should be
handled in this fashion as well?  Or does what was previously cv=fail still
sign all arc sets?  Are we handling these differently?  I'm not necessarily
sure we should.  Also, the language here is MUST.  Shouldn't this be
optional, as we'd discussed?

On Fri, Jun 30, 2017 at 4:48 PM, Kurt Andersen <[email-masked]>
wrote:

>
> On Jun 30, 2017 2:37 PM, Brandon Long <[email-masked]> wrote:
>
> Looking through the changes, I see that in 5.2.2 we previously and still
> say that the AAR field should be unknown.  Unknown is a valid value for
> result names for dkim-adsp and rrvs, but I'm curious why we would use that
> and not just fail?  fail seems to match better, especially now that we
> don't differentiate between invalid and fail in the cv value.
>
>
> Fair point. I'll look at rephrasing that.
>
> We also discussed signing/verifying a cv=fail differently, which isn't in
> the draft yet (I don't think, I was looking at the diff not the whole
> document).
>
> We discussed that the signing/verifying of a cv=fail would only do so
> based on the single (presumably last) hop that contained the cv=fail.
>
> So, the AMS would be added/verified like normal, but the AS would only
> sign the as/ams/aar of that hop.
>
>
> That is already the specified handling in the case of fail.
>
> --Kurt
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Gene Shuman <[email-masked]>
Date: Mon, 10 Jul 2017 14:46:15 -0700

(resending from my personal account to avoid the spam filter)

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 10 Jul 2017 15:12:51 -0700

> optional, as we'd discussed?

I still think (and find it compatible with the tenor of other
conversational threads) that MUST is appropriate. As usual, people can
choose to not follow the spec :-(

To your other points:

   1. Section 6.1 para 2 says:  "Until the chain is determined to be
   failed, and marked with an ARC set bearing the "cv=fail" indication, each
   participating ADMD SHOULD apply their own seal."
   2. Section 5.2.2 para 2 says: "Because the violations can not be readily
   enumerated, the header fields signed by the AS header field in the case of
   a major violation MUST be only the matching 'i=' instance headers created
   by the MTA which detected the malformed chain, as if this newest ARC set
   was the only set present."
   I see now that I did not properly expand the scope of that directive to
   cover all cases where a cv=fail verdict is determined to be necessary, but
   I think that is the right approach. cv=fail --> sign only the current
   (latest) ARC set (regardless of the failure reason)

--Kurt

---

From: Gene Shuman <[email-masked]>
Date: Mon, 10 Jul 2017 15:32:25 -0700

OK cool, totally agreed with all of these points.

On Mon, Jul 10, 2017 at 3:12 PM, Kurt Andersen (b) <[email-masked]> wrote:

>    2. Section 5.2.2 para 2 says: "Because the violations can not be
>    readily enumerated, the header fields signed by the AS header field in the
>    case of a major violation MUST be only the matching 'i=' instance headers
>    created by the MTA which detected the malformed chain, as if this newest
>    ARC set was the only set present."
>    I see now that I did not properly expand the scope of that directive
>    to cover all cases where a cv=fail verdict is determined to be necessary,
>    but I think that is the right approach. cv=fail --> sign only the current