Subject: Re: [dmarc-ietf] ARC draft-10 protocol elements section and question about reducing section 8

From: Stan Kalisch <[email-masked]>
Date: Tue, 2 Jan 2018 11:18:54 -0500

> On Dec 29, 2017, at 12:29 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Chairs, should we start using the WG's issue tracker for this stuff?

Speaking as an observer, I personally would find that helpful.

Thanks,
Stan

>> On Thu, Dec 28, 2017 at 4:44 PM, Seth Blank <[email-masked]> wrote:
>> Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the protocol elements section of the latest draft (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4)
>> 
>> I spoke with Kurt, and this appears to have been an oversight.
>> 
>> To be clear about the protocol elements section, I've cribbed it from DKIM and proposed it to:
>> a) provide context for the entire ARC Chain
>> b) define protocol components that are not specific to only sealing or validating the chain
>> 
>> As such, I believe both the concept of chain validation status and the ordering of hops belong in protocol elements.
> 
> +1.
> 
>> This also opens the question of where Section 8 (https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8) belongs. This section now feels more like a kitchen sink and implementation guidance.
>> 
>> I would suggest:
>> 
>> 8.1 be stricken as it's a normative modification of DKIM, or replaced with language to the effect of "ARC MUST be the last signer of the message; otherwise it cannot be validated on receipt." which can go in signer actions
>> 
>> 8.2 should be moved to protocol elements
>> 
>> 8.3 to signer actions
>> 
>> 8.4 to verifier actions
> 
> +1 to all of those.
> 
>> 8.5 should be stricken (this is bad advice that could result in backscatter, and I'm unsure where it came from, I can find no working group conversation around this)
> 
> It is a reasonable choice, however.  That is: If you're going to give an SMTP reply, this is the right one to use, but maybe warn that backscatter (and provide or reference a definition of that term) can result.
> 
> -MSK
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 2 Jan 2018 18:48:34 +0000

On Fri, Dec 29, 2017 at 12:44 AM, Seth Blank <[email-masked]> wrote:

> Sections 4.7 and 4.8 from my proposal (https://mailarchive.ietf.org/
> arch/msg/dmarc/yl1HWdNbmQR1wHlCvG3eRl9ph5E) were not moved into the
> protocol elements section of the latest draft (
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-4)
>
> This also opens the question of where Section 8 (
> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-10#section-8)
> belongs. This section now feels more like a kitchen sink and implementation
> guidance.
>

Both section changes noted in my edits-in-progress for -11.

--Kurt