OK cool, totally agreed with all of these points. On Mon, Jul 10, 2017 at 3:12 PM, Kurt Andersen (b) <[email protected]> wrote:
> On Mon, Jul 10, 2017 at 2:46 PM, Gene Shuman <[email protected]> wrote: > >> (resending from my personal account to avoid the spam filter) >> >> 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? >> > > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
