Re: [dmarc-ietf] what to document about the tree walk

Alessandro Vesely <vesely@tana.it> Thu, 14 July 2022 12:12 UTC

Return-Path: <vesely@tana.it>
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 29694C16ECBC for <dmarc@ietfa.amsl.com>; Thu, 14 Jul 2022 05:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.129
X-Spam-Level:
X-Spam-Status: No, score=-7.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b=87TZc8Gk; dkim=pass (1152-bit key) header.d=tana.it header.b=B+kInzPr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvK4BnxD1huX for <dmarc@ietfa.amsl.com>; Thu, 14 Jul 2022 05:12:09 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2D6C16ECB9 for <dmarc@ietf.org>; Thu, 14 Jul 2022 05:12:04 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1657800718; bh=9Vg2E6PYWRzsiyD11AEiYfknzkCZyHvtqDxv1xgMyZ4=; h=Date:Subject:To:References:From:In-Reply-To; b=87TZc8Gkm7e/Zy09QN2rSvrT8Yv7miE114ycF+ii1iVAiPOiNjuUXFHpc10P3LMS0 IwI+H42Pj2cpER5VjrbBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1657800718; bh=9Vg2E6PYWRzsiyD11AEiYfknzkCZyHvtqDxv1xgMyZ4=; h=Date:To:References:From:In-Reply-To; b=B+kInzPr0QyCncnCPBY9QRce0ioxhjp1Uuo1Bo7fsmMkOdjpYoUq++L5CBYPlLcYY aP/9VAsymxcjRRQ+ZkzqKJ1DRp+lZXWa/86dsJApL+W+BYNjiUiBxOPNjmppp+2POE g+ZnM7xVmdiZXHYeVfMK1OIijJcM4YBs2hC4R6XblivD0pncZmS6trqo41lHJ
Author: Alessandro Vesely <vesely@tana.it>
Received: from [192.168.1.108] (host-87-4-196-130.retail.telecomitalia.it [87.4.196.130]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0BB.0000000062D0080E.00001748; Thu, 14 Jul 2022 14:11:58 +0200
Message-ID: <f5e3f92b-f95e-a3a5-c74d-bd0957bec61a@tana.it>
Date: Thu, 14 Jul 2022 14:11:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: dmarc@ietf.org
References: <20220710010547.DB3B04532F40@ary.qy> <d8716435-8a52-dac4-ede2-6c27fced7f0f@tana.it> <84DDA91C-26E2-4803-8C6C-0369ED67298F@kitterman.com> <c4a7fd03-eae8-497f-3133-73523a9c1ca2@tana.it> <5197ba5f-9de4-d838-1579-eae67683e2d4@taugh.com> <650cadee-db8f-a54a-4d14-082c2d0bed02@tana.it> <0f3a343b-e7ea-7509-ceab-e5670aac8616@taugh.com> <CAH48ZfxHgxZwu3zLh99pc1JS4s==9bxU-0nS78O=7UAnZ=DtUQ@mail.gmail.com> <CAHej_8nkpGo30b9-ZkRc_wokymJ2ry_hsMgzaB2m4EH-WWG_zw@mail.gmail.com> <CAH48ZfzoVocPRKeVTqf6AE6Z48AWKFObm7X5oDa1ic1sQ5V1zg@mail.gmail.com> <CAL0qLwZFO_KK3+RUdzMLyjW0uOnzi4mXcVww1Mqx8tmhe-x2hA@mail.gmail.com> <CAH48ZfwTaf75HiJS2_VJKez8s3FqMh-K_6eD2eqaJatXWwcKww@mail.gmail.com> <CAL0qLwbxoijfdfxpS5-LRPifxg+4e_ndBGQhne5s5of0zxBbMQ@mail.gmail.com> <D3807517-98C3-4F20-A594-F3109BCB831A@kitterman.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <D3807517-98C3-4F20-A594-F3109BCB831A@kitterman.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/H8xbuhQkwL65wDquJxAPj5T8W9Q>
Subject: Re: [dmarc-ietf] what to document about the tree walk
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 14 Jul 2022 12:12:15 -0000

On Wed 13/Jul/2022 17:56:08 +0200 Scott Kitterman wrote:
> On July 13, 2022 3:10:38 PM UTC, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
>> Once again, participating only:
>> On Wed, Jul 13, 2022 at 3:43 AM Douglas Foster wrote:
>>> [...]
>>
>>> 3) The critical question is whether we can treat the PSL as replaced
>>> without obtaining the markers first.   On this issue, John and I have a
>>> different assessment of the risk.   I can accept a solution which lays out
>>> the assumptions and risks to the evaluator, and lets them decide what to
>>> do.  This is what sections 4.7. and 4.8 in my text from Sunday night
>>> attempted to do.
>>
>> My suggestion would be that if we are going to offer a choice, there should
>> be some eventual path toward convergence rather than an open-ended period
>> of people doing either.  Otherwise, the PSL will be a part of DMARC for far
>> longer than we'd like.
> 
> I think a choice within DMARCbis is a bad idea.  Effectively the choice exists.  Evaluators will have the choice to stay with an RFC 7489 design or to upgrade to DMARCbis.


The incentive to upgrade is not clear.  DMARC filters can run based on 
an obsolete version of the PSL with no inconvenience, for a different 
flavor of "upgrade".  Indeed, according to John's figures, we could 
have done without any psd= tag.

Doug's idea of checking the results is a means to draw the attention 
of operators on both the PSL version they use and its agreement with 
the DNS at large.  New implementations could be encouraged to track 
the differences and produce some kind of report about them.  IME, 
although running a very small mail site, it does happen to hit some 
PSL entry, a fact which I realized by chance —browsing the logs— so I 
cannot tell figures.


> We can't get rid of the PSL without getting rid of the PSL.
> 
> There's no way to constrain it within the document.  If we have a 'choice', we are essentially signing up the IETF to a future effort to produce an update to actually get rid of it.


Right, that would be the Internet Standard.


Best
Ale
--