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

[Kurt Andersen (b)]

On Wed, Apr 4, 2018 at 3:32 PM, Brandon Long  wrote:

> 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
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Brandon Long]

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

On Tue, Apr 3, 2018 at 4:05 PM Kurt Andersen (b)  wrote:

> 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  wrote:
>
>> On 21/03/18 15:18, Murray S. Kucherawy wrote:
>> > On Wed, Mar 21, 2018 at 3:00 PM,  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
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jeremy Harris]

On 21/03/18 15:18, Murray S. Kucherawy wrote:
> On Wed, Mar 21, 2018 at 3:00 PM,  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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Mar 21, 2018 at 3:00 PM,  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.
>
> Name:   draft-ietf-dmarc-arc-protocol
> Revision:   13
> Title:  Authenticated Received Chain (ARC) Protocol
> Document date:  2018-03-21
> Group:  dmarc
> Pages:  55
> URL:https://www.ietf.org/internet-drafts/draft-ietf-dmarc-arc-
> protocol-13.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-
> protocol/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-
> 13
> Htmlized:   https://datatracker.ietf.org/
> doc/html/draft-ietf-dmarc-arc-protocol
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-
> protocol-13
>
> Abstract:
>The Authenticated Received Chain (ARC) protocol creates a mechanism
>whereby a series of handlers of an email message can conduct
>authentication of the email message as it passes among them on the
>way to its destination, and create an attached, authenticated record
>of the status at each step along the handling path, for use by the
>final recipient in making choices about the disposition of the
>message.  Changes in the message that might break existing
>authentication mechanisms can be identified through the ARC set of
>header fields.
>

I just noticed this:

In Section 10.1, you're registering "header.selector" under DKIM, but I
think we want "header.s".

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc