Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-rfc7601bis-01.txt

From: [email-masked]
Date: Tue, 20 Mar 2018 10:11:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-dmarc-rfc7601bis-01.txt
	Pages           : 48
	Date            : 2018-03-20

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-rfc7601bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-rfc7601bis-01
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-rfc7601bis-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-rfc7601bis-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Mar 2018 17:13:13 +0000

>    or to make sorting and filtering decisions.

This includes a registration for "header.a" and John's changes to support
EAI.  However, Barry has some concerns with how "local-part" is not left in
a good state by these changes.  Those of you in the WG with clue about EAI,
please help me sort this out, since I do not fall into that category.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Mar 2018 18:50:39 -0400

On Tuesday, March 20, 2018 05:13:13 PM Murray S. Kucherawy wrote:
> >         Title           : Message Header Field for Indicating Message
> > 
> > Authentication Status
> > 

In the diff I sent in, I also proposed header.s (selector).  I think that's 
important for troubleshooting.  Is there a reason you left it out?  I can do 
another draft for it, if you want, but it seems like a lot of process overhead 
for not very much more.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 20 Mar 2018 23:38:40 +0000

Agreed we should do header.s here instead of in ARC as per DCRUP
conversation so that it’s registered standards track vs experimental.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Mar 2018 12:44:21 +0000

> another draft for it, if you want, but it seems like a lot of process

It's in the base ARC draft.  Does it matter which document does it?

-MSK

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 21 Mar 2018 09:50:33 -0400

> On Mar 21, 2018, at 8:44 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
>> On Tue, Mar 20, 2018 at 10:50 PM, Scott Kitterman <[email-masked]> wrote:

As Scott and I pointed out when this question was brought up with regard to header.a, the base ARC draft is intended to be experimental, and this feature isn't.

Thanks,
Stan

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 21 Mar 2018 14:20:54 +0000

> It's in the base ARC draft.  Does it matter which document does it?

We had talked about putting the definitions into 7601bis because that doc
is standards track (so presumably more enduring) than the "experimental"
ARC spec.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Mar 2018 15:20:21 +0000

> is standards track (so presumably more enduring) than the "experimental"

Ah, OK.  I don't mind which one has it, but I do want to avoid duplicating
effort.  So I'm fine with either.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 21 Mar 2018 16:48:27 +0000

I definitely prefer it go in the standards track document.  There's nothing experimental about it.

Scott K

On March 21, 2018 3:20:21 PM UTC, "Murray S. Kucherawy" <[email-masked]> wrote:
>>> important for troubleshooting.  Is there a reason you left it out? 
>I can
>>>> do
>>>> another draft for it, if you want, but it seems like a lot of
>process
>>>> overhead
>>>> for not very much more.
>>>>
>>>

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2018 11:47:36 +0000

>please help me sort this out, since I do not fall into that category.

That would probably be me, but I don't know what the local-part
problem is.  My intention was to import the local-part changes from
the EAI RFC.

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 22 Mar 2018 14:17:09 +0000

> problem is.  My intention was to import the local-part changes from

The problem has to do with the ambiguity that is being imported along with
those local-part ABNF changes.

--Kurt

---

From: "John R Levine" <[email-masked]>
Date: 23 Mar 2018 01:05:17 +0000

> those local-part ABNF changes.

It's importing the changes directly from the EAI spec:

    "local-part" is defined in Section 3.4.1 of [MAIL], as modified by
    [RFC6531].

Unless there is some lurking bug in RFC 6531 I don't understand what the 
problem is unless it should be this:

    "local-part" is defined in Section 3.4.1 of [MAIL].  In an
    EAI-formatted message, the definition is modified as in
    [RFC6531].

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly