On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <[email protected]>
wrote:
>On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <[email protected]>
>wrote:
>
>> On Monday, November 05, 2018 10:01:03 AM Kurt Andersen wrote:
>> > 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
>>
>> 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?
>>
>
>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).
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 protected]
https://www.ietf.org/mailman/listinfo/dmarc
