Subject: Re: [dmarc-ietf] New Version Notification for draft-ietf-dmarc-arc-protocol-13.txt

From: Jeremy Harris <[email-masked]>
Date: Tue, 3 Apr 2018 23:23:47 +0100

On 21/03/18 15:18, Murray S. Kucherawy wrote:
> On Wed, Mar 21, 2018 at 3:00 PM, <[email-masked]> wrote:
> 
>> A new version of I-D, draft-ietf-dmarc-arc-protocol-13.txt
>> has been successfully submitted by Kurt Andersen and posted to the
>> IETF repository.

I see that Google are still listed as implementing Version 6 -
and indeed, if you don't supply a t= tag in the AS (which is not
required, as far as I can find in Version 13) then gmail.com says:

  "arc=fail (missing mandatory fields);"

in it's A-R.

Which should I implement?
De-jure, or de-facto (and too-big-to-fail)?

-- 
Cheers,
  Jeremy

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 3 Apr 2018 16:05:48 -0700

Please implement -13, but there are almost no protocol changes between -6
and -13. It's mostly editorial. We may have made some tags optional but if
Google wants 'em, it's probably best to include them, but that doesn't mean
you aren't implementing -13.

--Kurt

On Tue, Apr 3, 2018 at 3:23 PM, Jeremy Harris <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Brandon Long <[email-masked]>
Date: Wed, 04 Apr 2018 22:32:40 +0000

Hmm, I guess this means the set of required/optional fields now stretches
between the DKIM and ARC specs, eh?

Is t the only one that's now optional?

For Seal, I have i, a, s, d, b, cv (removed t based on this thread)
For AMS, I have i, a, s, c, d, d, b, h, bh

Brandon

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 4 Apr 2018 16:05:10 -0700

> For AMS, I have i, a, s, c, d, d, b, h, bh

Looks like that was an unintended casualty of picking up more of the
DKIM-based definitions when we restructured the ARC protocol between -06
and -07. At this point, I don't feel that it's critical to the evaluation
of the ARC chain so making it optional seems reasonable.

--Kurt