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

Scott Kitterman <sklist@kitterman.com> Mon, 05 November 2018 05:14 UTC

Return-Path: <sklist@kitterman.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E4E129C6B for <dmarc@ietfa.amsl.com>; Sun, 4 Nov 2018 21:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=kitterman.com header.b=3YfnQGKG; dkim=pass (2048-bit key) header.d=kitterman.com header.b=KJk63oiJ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xp1gvl4rNV2 for <dmarc@ietfa.amsl.com>; Sun, 4 Nov 2018 21:14:03 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB38E128CF2 for <dmarc@ietf.org>; Sun, 4 Nov 2018 21:14:03 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803e; t=1541394841; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=kCw+tzqLiI2RdLauXemxgt/veF92DxA/BmQs/LWw+Cg=; b=3YfnQGKG4oWvmeIDDB+Vp+wYnWlT8jK1hetvli/P0P29bD3V8IbELFPF 3xwZYlh8xLosUUSl6lnobUCAirAYCw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201803r; t=1541394841; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id : date : subject : from; bh=kCw+tzqLiI2RdLauXemxgt/veF92DxA/BmQs/LWw+Cg=; b=KJk63oiJG4DwvwQt9MSKMZQI7H9Qrks7+GPA7/jz/siCsUm1dqa1ChAA GJ+cDVBjZyysUpbJHpYUeYCU/7wgLJd3BOOm3xrQjbQauHmog6W0Am3Plh QpBE6NyKSO+SeoeG+bqnbXARUuFDpCBZ9QGes7xsmhmBnm17tIXcICyJ7k sDMLCO6+9cTd4E63oToB3yGsOtL+Nf/8Br/6MKCzHKfNoFm5izks1VjNoM jbdluf2HRhHWb9/L4VJIrTVL0aygkjD5L0sIykHYP/XfVECw3e+GKyJ666 kuHuvxQVvGmHmTW1pNoM03/tzJlMt+p+7zlDXMx1XpGRC45iP+8Wvg==
Received: from [192.168.1.146] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BB933C400D3; Sun, 4 Nov 2018 23:14:01 -0600 (CST)
Date: Mon, 05 Nov 2018 05:13:57 +0000
In-Reply-To: <CABuGu1oQLCmmuKhfFZdgq9tmN-GOpCLikmu4OpN3MyAv3whw4g@mail.gmail.com>
References: <CABuGu1qC=Hwu=2zzmApHKQ68H-X0UmLBZnvzABeXAfD_A4F6TQ@mail.gmail.com> <2393746.3XrAvFVKfY@kitterma-e6430> <CABuGu1oQLCmmuKhfFZdgq9tmN-GOpCLikmu4OpN3MyAv3whw4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: "Kurt Andersen (b)" <kboth@drkurt.com>
CC: "dmarc@ietf.org" <dmarc@ietf.org>
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <5694407E-6D84-4266-93DE-21FB90D803B2@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/zlGVt8BrmG9Ma3OcGPgH3ldNevQ>
Subject: Re: [dmarc-ietf] Proposed charter spiff to accept EAI clarification within email authentication stack
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 05:14:06 -0000


On November 5, 2018 3:21:15 AM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> wrote:
>On Mon, Nov 5, 2018 at 10:11 AM Scott Kitterman <sklist@kitterman.com>
>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