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

Alessandro Vesely <vesely@tana.it> Sat, 16 July 2022 10:41 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 4454BC14F745 for <dmarc@ietfa.amsl.com>; Sat, 16 Jul 2022 03:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.127
X-Spam-Level:
X-Spam-Status: No, score=-2.127 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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=vfF4afuk; dkim=pass (1152-bit key) header.d=tana.it header.b=BsUG3w2T
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 ZM55BCkJd-51 for <dmarc@ietfa.amsl.com>; Sat, 16 Jul 2022 03:41:23 -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 68220C14F734 for <dmarc@ietf.org>; Sat, 16 Jul 2022 03:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=tana.it; s=epsilon; t=1657968075; bh=6aZb1/D48P6rOKPmXuoRL1N8x/BnS/nqPNZk8NDUuTo=; h=Date:Subject:To:References:From:In-Reply-To; b=vfF4afukfonLryEV+HgdhsyzNOub1OeyA81ozg3T3/vyYUt4fPGoqw8Q7nCSkiKfk wWz+f0xSFif9PQ276iMDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1657968075; bh=6aZb1/D48P6rOKPmXuoRL1N8x/BnS/nqPNZk8NDUuTo=; h=Date:To:References:From:In-Reply-To; b=BsUG3w2TDRT+pecjHGdRmqG1rxwByKdAyhBeyMujfxBXbtIIppxw2oJybRouxLY9N Sw5lI44g4Zv+r/sZNM/awVUqdGcjIbE1wZcucYWAMZ1RLZXmN+JYgBCm/lzj9JhHN9 Os3hcYC5ijtek7kWgKyC/IV7uVXVM21Ul5x2UOChW7RJRzp4Dbw9nUA99tdJI
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 00000000005DC033.0000000062D295CB.00005278; Sat, 16 Jul 2022 12:41:15 +0200
Message-ID: <29ce4a52-d45b-f705-9219-817f5e46a5d4@tana.it>
Date: Sat, 16 Jul 2022 12:41:13 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: dmarc@ietf.org
References: <20220710010547.DB3B04532F40@ary.qy> <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> <f5e3f92b-f95e-a3a5-c74d-bd0957bec61a@tana.it> <4293C636-9656-4122-80D6-5E2DE4D790B4@kitterman.com> <CAL0qLwZN8VfB2SLTindAO4P0_h47wphh2OZy8p8U3xM7-ZNGWA@mail.gmail.com> <66093339-4dae-4479-39e2-283ce7f8f21f@tana.it> <28c80b51-b11a-b1e7-76f3-a006b5e6078e@iecc.com> <D572951E-FBE6-46E6-8176-81AB8E3C27D7@kitterman.com>
Authentication-Results: tana.it; auth=pass (details omitted)
From: Alessandro Vesely <vesely@tana.it>
In-Reply-To: <D572951E-FBE6-46E6-8176-81AB8E3C27D7@kitterman.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/FzDJNyEsmKGJo8EvZlnXFguATtU>
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: Sat, 16 Jul 2022 10:41:30 -0000

On Fri 15/Jul/2022 21:28:09 +0200 Scott Kitterman wrote:
> On July 15, 2022 6:26:39 PM UTC, "John R. Levine" <johnl@iecc.com> wrote:
>> On Fri, 15 Jul 2022, Alessandro Vesely wrote:
>>> +1 from me too.  Note, though, that the (current) DNS is accidentally correct most of the time, as far as our Tree Walk is concerned.
>>
>> No, it's not an accident.  We designed the tree walk based on our knowledge of the way people publish DMARC records.
> 
> +1.  I was going to write something along these lines, but John got to it first.  PSL is the accidentally correct approach.  The DMARCbis design is aligned to how DMARC works.


I don't understand this unwearying opposition irrespective of the 
argument.  If you do a tree walk NOW (which is why I said currently) 
you have exactly 0 probability to determine an abnormal PSD, since the 
tag hasn't been assigned yet.


Best
Ale
--