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

From: Seth Blank <[email-masked]>
Date: Thu, 28 Dec 2017 16:44:50 -0800

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.

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

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)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Dec 2017 09:29:06 -0800

Chairs, should we start using the WG's issue tracker for this stuff?

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 (

+1.

> 8.2 should be moved to protocol elements

+1 to all of those.

> 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