Subject: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 5 Nov 2018 10:01:03 +0700

I think that we could possibly already read this into the existing charter,
but the following one sentence patch makes it explicit:

diff --git a/dmarc-wg-charter b/dmarc-wg-charter
index a1d0fac..c8ac6bc 100644
--- a/dmarc-wg-charter
+++ b/dmarc-wg-charter
@@ -81,6 +81,9 @@ the working group can consider extending the base DMARC
specification
 to accommodate such a standard, should it be developed during the
 life of this working group.

+Clarifying the handling of internationalized email addresses (EAI)
+throughout the authentication stack of SPF, DKIM, and DMARC.
+
 Improvements in DMARC features (identifier alignment, reporting,
 policy preferences) will be considered, such as:

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 04 Nov 2018 22:11:23 -0500

>  policy preferences) will be considered, such as:

I don't see anything about changes to SPF or DKIM being within the current 
charter, so if we are going to do this, then I think it definitely needs a 
charter change.

What needs changing in SPF/DKIM that we need to take this on?

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Mon, 5 Nov 2018 10:21:15 +0700

> What needs changing in SPF/DKIM that we need to take this on?

This came out of this morning's DISPATCH meeting at IETF103 (
https://tools.ietf.org/wg/dispatch/agenda) to be able to accept
http://tools.ietf.org/html?draft=draft-levine-appsarea-eaiauth into the WG
for advancing it to an RFC (probably informational).

--Kurt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 5 Nov 2018 11:03:46 +0700

I was about to propose something very similar, so I'm happy to go with
Kurt's text.  Alexey, do you think this will work?

DMARC working group, are you OK with that addition to the charter?
Any objections?

Barry
On Mon, Nov 5, 2018 at 10:01 AM Kurt Andersen (b) <[email-masked]> wrote:
>
> I think that we could possibly already read this into the existing charter, but the following one sentence patch makes it explicit:
>
> @@ -81,6 +81,9 @@ the working group can consider extending the base DMARC specification

-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2018 13:05:25 +0900

I proposed adding this right above "Work Items" (it accomplishes the same
thing):

4. Incidental related work

Any issues related to the email authentication space that are large enough
to mandate working group review but do not already fit under the charter of
an existing working group can be considered for adoption by DMARC.  A
prime example is draft-levine-appsarea-eaiauth, which provides EAI-related
updates to DMARC and the protocols upon which it depends.

On Mon, Nov 5, 2018 at 1:03 PM Barry Leiba <[email-masked]> wrote:

> > I think that we could possibly already read this into the existing
> charter, but the following one sentence patch makes it explicit:
> >

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Nov 2018 05:13:57 +0000

On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[email-masked]> wrote:
>> charter,

Thanks.  It doesn't appear that it proposes any changes for SPF.  It merely documents that non-ascii local parts don't match the related macros.  During the SPFbis working group we looked at this and explicitly decided on it.  It's not by accident.

Since local part macros are very rarely used, it seemed like very much a corner case not worth it to break the installed base over.

If there's going to be a charter change around this, I think it needs some words to constrain the work to limit interoperability implications.

I know less about the implications for DKIM and DMARC, but would imagine backward compatibility is important there too.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Mon, 5 Nov 2018 12:53:08 -0500

I think MSK’s text with Kitterman’s caveat cleanly carved out for
interoperability regressions is the optimal charter update.

On Mon, Nov 5, 2018 at 00:14 Scott Kitterman <[email-masked]> wrote:

> Thanks.  It doesn't appear that it proposes any changes for SPF.  It
> merely documents that non-ascii local parts don't match the related
> macros.  During the SPFbis working group we looked at this and explicitly
> decided on it.  It's not by accident.
>
> Since local part macros are very rarely used, it seemed like very much a
> corner case not worth it to break the installed base over.
>
> If there's going to be a charter change around this, I think it needs some
> words to constrain the work to limit interoperability implications.
>
> I know less about the implications for DKIM and DMARC, but would imagine
> backward compatibility is important there too.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>