Subject: Re: [dmarc-ietf] ARC spec clean up if 7601bis proceeds

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 17:12:57 +0000

On Fri, Dec 29, 2017 at 12:58 AM, Seth Blank <[email-masked]> 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