IETF Logo Mail Archive

Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work

Scott Kitterman <sklist@kitterman.com> Mon, 10 December 2018 22:08 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 23618131280 for <dmarc@ietfa.amsl.com>; Mon, 10 Dec 2018 14:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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=kXBFt7ly; dkim=pass (2048-bit key) header.d=kitterman.com header.b=g6Cv+E6d
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 HZP7RwwiPzm6 for <dmarc@ietfa.amsl.com>; Mon, 10 Dec 2018 14:08:33 -0800 (PST)
Received: from softlayer.kitterman.com (softlayer.kitterman.com [IPv6:2607:f0d0:3a01:a3::9]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541B013123B for <dmarc@ietf.org>; Mon, 10 Dec 2018 14:08:33 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812e; t=1544479710; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=11SFalTb/Nhsm7ufzJ+vRVYayUpI2KR/LQZ1/vPNlGo=; b=kXBFt7lySh1TGVXhlFIuJQpiDKvj6ZgwkMUXjKq5qAZXY/xYr4mNv6DQ C1tyMv5iZ8pODb0ZQbUvvil282B2Bg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com; i=@kitterman.com; q=dns/txt; s=201812r; t=1544479710; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : from : message-id : date : subject : from; bh=11SFalTb/Nhsm7ufzJ+vRVYayUpI2KR/LQZ1/vPNlGo=; b=g6Cv+E6dAfWtemCp5c4+VnA8UHViO/HEk7M7J44tM1IhlaQWWQT0GFh/ z7JM5QJrjDaoKDUA4xvPTjwDMfMd2UEoqaEWzZv6m9NYRd9eTpmnYK8MGk VfVZ3um/cF67BBuPGTOOkSXseu9LCqwUxaEuNnChUtuSiGiNZB1B/h7NO4 zINoCK86n3Cj3ejNZl52QcpsANK1nmbXBhxiow1qqBgrXTfbnZk980A6i2 Eo3xodRv9H1iG7D8+O8KJ2IrO6VBqZRifn0NofBxmAZ+sLgDFIYeadcNC3 RzAcziWC8kBF6Lej7Zo7G16Yn9Q/FmBHZZ9KYHP2yE0ram/AEGfu+A==
Received: from [10.125.68.230] (mobile-166-170-33-176.mycingular.net [166.170.33.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by softlayer.kitterman.com (Postfix) with ESMTPSA id B1A262D4062B; Mon, 10 Dec 2018 16:08:30 -0600 (CST)
Date: Mon, 10 Dec 2018 22:08:27 +0000
In-Reply-To: <CABuGu1qHrfOggr=zpc3xM12d7obzEGfvGgET4U_iSE0aU1OChg@mail.gmail.com>
References: <CABuGu1oWd_5reSBSoCrL2KoFu1cr9nwWTsuFP+a4sKq572pPtA@mail.gmail.com> <D71CF379-350A-4FB0-A664-148B7C724BBE@kitterman.com> <CABuGu1rP9Udnzw4Ox1O501+OQc1LeHrQ1BUGGytCU8=-iiyL8w@mail.gmail.com> <5A5FC552-4CEC-42E9-B40B-6CFED1D86885@kitterman.com> <CABuGu1qHrfOggr=zpc3xM12d7obzEGfvGgET4U_iSE0aU1OChg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: dmarc@ietf.org
From: Scott Kitterman <sklist@kitterman.com>
Message-ID: <C84511E2-041D-4DAB-AFF8-F8E442796D56@kitterman.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/C_gf2e4KA8VVI9TH9jOAwDHSG74>
Subject: Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
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, 10 Dec 2018 22:08:35 -0000


On December 10, 2018 5:02:30 PM UTC, "Kurt Andersen (b)" <kboth@drkurt.com> wrote:
>On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>>
>>
>> On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)"
><kboth@drkurt.com>
>> wrote:
>> >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman
><sklist@kitterman.com>
>> >wrote:
>> >
>> >>
>> >> Since I'm most familiar with RFC 7208, I took a more detailed look
>at
>> >the
>> >> SPF updates.  Much of the current text is a restatement of what
>RFC
>> >7208
>> >> says.  I don't know that we need that.  The difference is to make
>> >explicit
>> >> what was  already implicit; s and l macros will never match if the
>> >local
>> >> part of the email address contains non-ascii characters.
>> >>
>> >
>> >Why not? If the non-ASCII (or non-7bit) characters are puny-coded,
>it
>> >seems
>> >like they should be able to match without any problems.
>> >
>> AIUI, local parts don't get puny-coded.
>>
>
>Even when attempting to look them up via the macro mechanism? It seems
>like
>that encoding should be a part of the macro processing.

We discussed this during spfbis and concluded this was enough of a corner case not to make an incompatible protocol change over it.

Almost no one uses SPF macros and even fewer use use the 'l' and 's' macros.  If such a change were introduced, every SPF library would need an update to help approximately no one.  I don't we should relitigate this here.

Between non-ascii local parts and SPF records using with the 'l' or 's' macros, you get to pick one.  Documenting this clearly is a good idea.

Scott K

v2.23.0 | Report a Bug | By Email