Subject: [dmarc-ietf] Comments on ARC specification

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Jul 2017 10:02:22 +0200

I've started implementing ARC and have a few minor comments on the draft:

5.1.2.2.  Computing the 'b' Tag Value for ARC-Message-Signature

   As with ARC-Seal and DKIM-Signature header fields, the order of
   header fields signed MUST be done in bottom-up order.

Upon rereading this I am not sure this is very clear. Maybe give an example, especially if multiple instances of a particular header field are included.

ARC-Authentication-Results needs ABNF (I know the document says in prose that the syntax is effectively "i=<number>; ...", but also specifying this with ABNF would be much better, especially in order to avoid people inserting CFWS in places they shouldn't.)

Examples need updating.

Some "Authentication-Results" in examples are supposed to be "ARC-Authentication-Results"

In A.3.2.2: 

o  gmail.com adds it's own ARC-Seal: header, contents of which are

      *  version

 -- the version was removed?

Auth-Results is used in several places

 -- Use non abbreviated version of Authentication-Results, in case people are searching for occurrences of Authentication-Results in the document

Best Regards,
Alexey

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 18 Jul 2017 09:59:03 +0200

On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov <[email-masked]
> wrote:

> Upon rereading this I am not sure this is very clear. Maybe give an
> example, especially if multiple instances of a particular header field are
> included.
>

See section 5.1.1.3 of the document which specifies the way to build the
header list for hashing.

ARC-Authentication-Results needs ABNF (I know the document says in prose
> that the syntax is effectively "i=<number>; ...", but also specifying this
> with ABNF would be much better, especially in order to avoid people
> inserting CFWS in places they shouldn't.)
>

See the -06 version which I posted today with some extra notes regarding
open questions related to AAR. Once we settle those questions, I'll also
add details (and ABNF) for the AAR and handling multiple A-R headers
(another open question on the list). For now, if your environment creates
multiple A-R headers with the same authserv-id, they need to have the (not
"none") resinfo sections concatenated to create the AAR. I've taken a note
to update this in the next draft after we resolve the open questions
regarding content in Thursday's session.

Examples need updating.

Thanks - I'm sure that there's a lot more problems in the examples than
just the ones you listed :-/ I suspect that we should just entirely remove
the examples right now. If you want a real life example, you can find it
(for the next week or so) at https://pastebin.com/HyMriMKe or other
citations on the #ietf99 channel in the slack group.

--Kurt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Jul 2017 10:30:04 +0200

Hi Kurt,

> On 18 Jul 2017, at 09:59, Kurt Andersen (b) <[email-masked]> wrote:
> 
>> On Tue, Jul 18, 2017 at 10:02 AM, Alexey Melnikov <[email-masked]> wrote:
> See section 5.1.1.3 of the document which specifies the way to build the header list for hashing. 

Maybe add a cross reference then. Maybe it is just lack of coffee, but "bottom-up" sounded confusing and the opposite of the DKIM order.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Jul 2017 10:32:03 +0200

> Thanks - I'm sure that there's a lot more problems in the examples than just the ones you listed :-/ I suspect that we should just entirely remove the examples right now.

I think I like to see examples in the final version of the document when published as an RFC. They did help me to understand the document.

> If you want a real life example, you can find it (for the next week or so) at https://pastebin.com/HyMriMKe or other citations on the #ietf99 channel in the slack group.