Subject: [dmarc-ietf] Comments on certain drafts

From: Peter Occil <[email-masked]>
Date: Mon, 23 Jul 2018 05:33:45 -0400

draft-ietf-dmarc-arc-protocol

The production “arc-info” includes a semicolon after “instance”, which in turn has a semicolon at the end.  However, a great number of Arc-Authentication-Results header fields I’ve seen in practice include only one semicolon between the instance and the “authres-payload”; for example: “i=1; mx.example.com; …”.

draft-ietf-dmarc-rfc7601bis

I also want to report on another form of the Authentication-Results field that I've seen in practice.  It has the form:

     authserv from=domain; method=result (comment); from=domain; method=result (comment)

where "authserv" (from what I've seen) is a domain name that always ends in "yahoo.com".

--Peter

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2018 12:08:43 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>The production “arc-info” includes a semicolon after “instance”, which in turn has a semicolon at the
>end.  However, a great number of Arc-Authentication-Results header fields I’ve seen in practice include only
>one semicolon between the instance and the “authres-payload”; for example: “i=1; mx.example.com; …”.
>

You're right, that's a bug in the ABNF.  The definition of instance in section 3.6 shouldn't
have a semicolon because both places it's used, arc-info and arc-as-info, put a semicolon
after it.  I suppose we could take the semicolon out of arc-info and arc-as-info instead.

>where "authserv" (from what I've seen) is a domain name that always ends in "yahoo.com".

Yeah, Yahoo implemented it wrong.  I'll remind them when I see them at M3AAWG.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Wed, 25 Jul 2018 13:53:50 -0700

On Mon, Jul 23, 2018 at 2:33 AM, Peter Occil <[email-masked]> wrote:

> The production “arc-info” includes a semicolon after “instance”, which in
> turn has a semicolon at the end.  However, a great number of
> Arc-Authentication-Results header fields I’ve seen in practice include only

Great catch, thank you. Fixed.

---

From: Peter Occil <[email-masked]>
Date: Wed, 25 Jul 2018 18:39:11 -0400

Please take note: I have withdrawn this erratum.  This is because there would be optional CFWS (rather than required CFWS) between propspecs, which is actually erroneous.

--Peter

From: Peter Occil
Sent: Tuesday, July 24, 2018 7:54 AM
To: Dale R. Worley; RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [art] [Technical Errata Reported] RFC7601 (5435)

On further thought, it is indeed incorrect.  Therefore, the errata submission is withdrawn.

--Peter

From: Dale R. Worley
Sent: Monday, July 23, 2018 10:36 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [art] [Technical Errata Reported] RFC7601 (5435)

I think that the erratum is, strictly speaking, incorrect.  I've not
worked through examples in detail, but you can see that each propspec
contains exactly one "=" (other than in certain quoted contexts), which
makes it unlikely that two successive propspecs could be parsed as a
single propspec.  If there really is an ambiguity, the way to
demonstrate it is to provide an example.