On Fri, Dec 29, 2017 at 12:58 AM, Seth Blank <[email protected]> wrote:
> If 7601bis proceeds to allow content for filters in addition to humans, > then I believe the actions in the ARC draft (https://tools.ietf.org/html/ > draft-ietf-dmarc-arc-protocol-10) are as follows: > > Section 5.2 is cleaned up to inherit AAR ABNF from 7601bis. > Yes > Section 5.2.1 is stricken. > No - the instance variable is still germane. We may choose to move it elsewhere, but the info needs to stay. > New IANA registrations (I'm pretty certain this is wrong!): > authentication-results methods: dkim header.s > header.s is already defined in RFC6376 section 7.2 so I don't think that it needs further citation. > authentication-results methods: arc smtp.client-id > Should be smtp.client-ip no "id". > authentication-results methods: arc chain.closest-fail > See separate thread (Clarifying the value of arc.closest-fail) that I'm about to spin up. > authentication-results results: arc pass|fail|none|policy > Reading this, and initially conflating it with the cv values, I think that we should work on clarifying the wording to distinguish between the purely mechanical "did you check the ARC chain and, if so, is it valid?" vs the what did you do as a result of said information. Currently, this information is not called for in the A-R or AAR, just in the modified DMARC report to senders. Would we want to add it to the A-R/AAR as arc.effect? We could then have arc.cv for the mechanical result and arc.effect (none|pass|fail|other) for the policy-mediated impact on processing the message. > After this, I believe most of section 9 (except 9.3) can be stricken or > greatly reduced into verifier actions. > We can see. It may take a bit more work on the verifier section or better clarity/organization. --Kurt
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
