Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dmarc-rfc7601bis-00.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Jan 2018 23:14:06 -0800

As requested, I'm spinning up a revision effort of RFC7601 to accommodate
ARC's needs.

The first version is exactly the text of RFC7601.  This is so that the IESG
(and anyone else) can look at the differences between the -00 of this draft
and the final version and see the full set of changes between the existing
RFC and what we're proposing for the new one.

-01 will be up soon, incorporating the suggested changes in prose and ABNF
discussed previously on this list.

-MSK

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Jan 18, 2018 at 11:11 PM
Subject: New Version Notification for
draft-kucherawy-dmarc-rfc7601bis-00.txt
To: "Murray S. Kucherawy" <[email-masked]>

A new version of I-D, draft-kucherawy-dmarc-rfc7601bis-00.txt
has been successfully submitted by Murray Kucherawy and posted to the
IETF repository.

Name:           draft-kucherawy-dmarc-rfc7601bis
Revision:       00
Title:          Message Header Field for Indicating Message Authentication
Status
Document date:  2018-01-18
Group:          Individual Submission
Pages:          52
URL:            https://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-
rfc7601bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-
rfc7601bis/
Htmlized:       https://tools.ietf.org/html/draft-kucherawy-dmarc-
rfc7601bis-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-kucherawy-
dmarc-rfc7601bis-00

Abstract:
   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Jan 2018 10:49:34 -0800

On 1/18/2018 11:14 PM, Murray S. Kucherawy wrote:
> -01 will be up soon, incorporating the suggested changes in prose and 
> ABNF discussed previously on this list.

If I missed this, I apologize, but would it be possible to post a 
message which summarizes the nature/goals of the changes that are planned?

I'm not challenging the work, but just wanting to make sure the wg is in 
synch about how the doc should be adjusted.

Thanks.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 19 Jan 2018 13:41:33 -0800

On Fri, Jan 19, 2018 at 10:49 AM, Dave Crocker <[email-masked]> wrote:

> If I missed this, I apologize, but would it be possible to post a message
> which summarizes the nature/goals of the changes that are planned?
>

The intent is outlined in high level within the -10 version (section 5.2)
of the protocol doc. The better explanation is in Seth's email from
September (
https://mailarchive.ietf.org/arch/msg/dmarc/xUUbT15vqoBmH7RraJ_pesrd9z0):

1) The optimal ABNF for AAR would inherit the A-R payload ABNF from 7601.
Unfortunately, authres-header was defined in a way that makes this
difficult. Is there a better way to say that the AAR inherits the A-R
payload, and if anything modifies the definition of authres-header in 7601,
the AAR also needs to inherit this change?

To be super specific, this is the current authres-header ABNF from 7601:

     authres-header = "Authentication-Results:" [CFWS] authserv-id
              [ CFWS authres-version ]
              ( no-result / 1*resinfo ) [CFWS] CRLF

Optimally, there would be:

     authres-payload = [CFWS] authserv-id
              [ CFWS authres-version ]
              ( no-result / 1*resinfo ) [CFWS] CRLF

And then we could have:

   arc-authres-header = "ARC-Authentication-Results:" [CFWS] arc-info
authres-payload

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 19 Jan 2018 18:06:27 -0500

If I may budge in here, any chance we could put in a few tweaks for
EAI mail?

I think the main changes would be that if the A-R or AAR header is in
an EAI message, domain names and local parts can be UTF-8 rather than
ASCII.  I specifically do not want to change any of the keywords or
codes, since they're for software, not for people.

I realize that we should update RFC 6376 at the same time for DKIM
signatures, but I'll take what I can get.

R's,
John

---

From: Seth Blank <[email-masked]>
Date: Fri, 19 Jan 2018 16:11:00 -0800

On Fri, Jan 19, 2018 at 1:41 PM, Kurt Andersen (b) <[email-masked]> wrote:

> September (https://mailarchive.ietf.org/arch/msg/dmarc/
> xUUbT15vqoBmH7RraJ_pesrd9z0):
>
>
So to be really specific, those are the implications for the ARC draft
post-7601bis, not the initial intent for 7601bis itself (which is tied
closely, but distinct).

The ARC impetus for an update to 7601 was twofold:
1) To allow for ARC information to be encoded in the A-R in a way that is
allowed in the registry
    a) to keep the AAR definition crisp
    b) to avoid hacks like a header.ds tuple
    c) to allow all the information needed for a DMARC report to be
properly stamped without resorting to shenanigans or a 4th header
2) To allow for authres ABNF to be inheritable

Seth

---

From: [email-masked]
Date: Fri, 19 Jan 2018 19:43:12 -0800 (PST)

Given that this work is specificall for the benefit of DMARC/ARC, it
makes sense to me to do the work on this list/in this group.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Fri, 19 Jan 2018 22:52:07 -0500

On 1/19/2018 1:49 PM, Dave Crocker wrote:
>> -01 will be up soon, incorporating the suggested changes in prose
>> and ABNF discussed previously on this list.
>
>

+1

> I'm not challenging the work, but just wanting to make sure the wg is
> in synch about how the doc should be adjusted.
>
> Thanks.

If this is done, then shouldn't the ARC proposal be standard track 
rather than experimental?

-- 
HLS

---

From: [email-masked]
Date: Sun, 21 Jan 2018 10:01:34 -0800 (PST)

This would need to be coordinated with the EAI people/list, but as long
as it isn't controversial I don't see a reason not to put it in.

				Ned

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

---

From: "John Levine" <[email-masked]>
Date: 21 Jan 2018 15:14:39 -0500

>as it isn't controversial I don't see a reason not to put it in.

It's not supposed to be controversial, the minimum changes to make
stuff work with EAI UTF-8 messages.

R's,
John