Re: [dmarc-ietf] what to document about the tree walk
"Murray S. Kucherawy" <superuser@gmail.com> Wed, 13 July 2022 05:12 UTC
Return-Path: <superuser@gmail.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 32872C157B48 for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 22:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 c4zIqqT0xRzj for <dmarc@ietfa.amsl.com>; Tue, 12 Jul 2022 22:12:39 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692EFC157B3A for <dmarc@ietf.org>; Tue, 12 Jul 2022 22:12:39 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id bf9so17238983lfb.13 for <dmarc@ietf.org>; Tue, 12 Jul 2022 22:12:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IeJ3glpFfTunJWdL98umXYfG1d++XTAET3qiTivx8cg=; b=oikjIzDbxFJk24PSOOz8tOeMtOpTyLduy5yswjJ84v7w1t3rvjQxdIcltvwQq8mYiS doEvfV6z4PWJicEkQmStiVU2jlN+n9oh5rPa1NAo/6BgY1obd4HIoScBP2d+hg8lbvQT oU9pfUcJmeZfWV3OciWDEBcVefi23onrpn7AqW1oZzpAIqqajyd4zh+/dIvbpVTfcr7z uAmxjsy3qtGZq6JbmlJ2+GczldWcNStC+xH/Jjy2XrfX71owg8Db6G0wRexps/FIT14J jWk6Ih4H+l9Fkgu7tuptKBSg8UGGhI63rPQJ45s/Jj8Vtq/SaAEu0kq8otqyKpmMHzPc m0PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IeJ3glpFfTunJWdL98umXYfG1d++XTAET3qiTivx8cg=; b=7GF0lAwoC8ufVQdkZG4glotJ8nGJQELC5mM4PlZ/n8WbCm6w/SUqjBASReRs6iEHST 56ICqSOyVEsK/nPA2CKa143e5fyluFjlf82inGdQziXExhzJva0k3pej144j/g8On/MB IMvqz78leSlFGjna/hPqcotWV1pary0ziaDywrhDeEPNNSmflQ0yGKB623fWjVz6wsuF T2/Ix0XE5A9unR0kzHN6lQP6mZmiPCcMGPJtFTNBQhSytE++dmq9TyyXwWYzrkGN6eQm vxgYUkC50vst0nSQKItc10vrrPH442fVcySuiuH8pYZutuRIEAPMKY+mX23luAtIPsul PqOQ==
X-Gm-Message-State: AJIora/+JHxeIY6vTPDzBr7DBKirrxuM5uc3HZJ5C47QeUCMrVwPOKsn xulg2oTB0Kw+RaN2gaz01Vc77azVGTNvH5jru25U2snJock=
X-Google-Smtp-Source: AGRyM1vK0aLG3QKd79oHQVBRwC2o8QVKBn2EK46dS3yc+WBSxszb70CH8LCaJkF8TeW4BrotYWyS3MSdU4GzyVIJnPE=
X-Received: by 2002:a05:6512:1104:b0:487:34de:5f9d with SMTP id l4-20020a056512110400b0048734de5f9dmr927003lfg.162.1657689157083; Tue, 12 Jul 2022 22:12:37 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAH48ZfzoVocPRKeVTqf6AE6Z48AWKFObm7X5oDa1ic1sQ5V1zg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Tue, 12 Jul 2022 22:12:25 -0700
Message-ID: <CAL0qLwZFO_KK3+RUdzMLyjW0uOnzi4mXcVww1Mqx8tmhe-x2hA@mail.gmail.com>
To: Douglas Foster <dougfoster.emailstandards@gmail.com>
Cc: Todd Herr <todd.herr@valimail.com>, IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b296c05e3a8d5a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/BFPF7fATFXhyWnklSoMhTQ2gopU>
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: Wed, 13 Jul 2022 05:12:41 -0000
Hatless once again. On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster < dougfoster.emailstandards@gmail.com> wrote: > The tree walk solves the problem IF the policy has boundary information > provided by the domain owner. Without that, aren't we substituting one > insufficiently reliable solution for another insufficiently reliable one? > Another way to look at it: The PSL was never designed to provide the information for which DMARC has been using it. Hanging DMARC on it was a reasonable thing for a proof of concept, which is what RFC 7489 really was; it happens to give the right answer most of the time, but that's something of a coincidence. Here we're taking control over the input to the Organizational Domain and Policy Discovery algorithms, which is a more defensible way to do things if you're heading for the Standards Track. The tree walk also eliminates any concern that two compliant operators are using different versions of the input data. There is no guarantee that my copy of the PSL is any more or less up to date than yours is, leading us both to different determinations about the very same message. But once we're using the DNS for this, then, other than staleness caused by short-term caching, we're all talking about the same thing. There is indeed more of a burden on sending domains and registry operators to publish the needed markers in the DNS before this will all work the way we want it to. My view is that the working group perceives the risk of continued use of the PSL to be less favorable than taking on that burden. The tree walk has been a goal for years. Changes to nodes in the DNS tree are visible immediately; changes to the PSL take an unknown amount of time to be published and deployed globally. Changes to the DNS are made by the operator in charge of the name(s) being updated; as far as I'm aware, changes to the PSL are made by a limited community not involved in (or perhaps even interested in, or cognizant of) DMARC. If we want a migration period, some kind of hybrid model might work: Do the DNS tree walk, but at each step, if you find you've hit a name that's present in the PSL, you can stop and pretend you found a marker you're looking for. When those markers are all (or mostly) actually published, then stop doing that. For bonus points, find some non-DoS way to notify those operators that they really should be publishing the missing markers. (The 1990s DNS "lame delegation" stuff comes to mind.) We just need to remember that SPF had a not-so-great transition plan, so we need to be careful how we craft this one. -MSK
- [dmarc-ietf] "psd=" tag early assignment Barry Leiba
- Re: [dmarc-ietf] "psd=" tag early assignment Douglas Foster
- Re: [dmarc-ietf] "psd=" tag early assignment John Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] "psd=" tag early assignment Barry Leiba
- Re: [dmarc-ietf] "psd=" tag early assignment Scott Kitterman
- Re: [dmarc-ietf] "psd=" tag early assignment Barry Leiba
- Re: [dmarc-ietf] "psd=" tag early assignment Douglas Foster
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] "psd=" tag early assignment John Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Douglas Foster
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] "psd=" tag early assignment Murray S. Kucherawy
- Re: [dmarc-ietf] "psd=" tag early assignment Barry Leiba
- Re: [dmarc-ietf] "psd=" tag early assignment John R Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Douglas Foster
- Re: [dmarc-ietf] "psd=" tag early assignment Barry Leiba
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] "psd=" tag early assignment Scott Kitterman
- Re: [dmarc-ietf] "psd=" tag early assignment John Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] "psd=" tag early assignment Scott Kitterman
- Re: [dmarc-ietf] "psd=" tag early assignment John R Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Scott Kitterman
- Re: [dmarc-ietf] "psd=" tag early assignment Alessandro Vesely
- Re: [dmarc-ietf] what to document about the tree … John R Levine
- Re: [dmarc-ietf] "psd=" tag early assignment Douglas Foster
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] what to document about the tree … John R Levine
- Re: [dmarc-ietf] what to document about the tree … Douglas Foster
- Re: [dmarc-ietf] what to document about the tree … Todd Herr
- Re: [dmarc-ietf] what to document about the tree … Douglas Foster
- Re: [dmarc-ietf] what to document about the tree … John Levine
- Re: [dmarc-ietf] what to document about the tree … Scott Kitterman
- Re: [dmarc-ietf] what to document about the tree … Murray S. Kucherawy
- Re: [dmarc-ietf] "psd=" tag early assignment Murray S. Kucherawy
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] what to document about the tree … Douglas Foster
- Re: [dmarc-ietf] what to document about the tree … Murray S. Kucherawy
- Re: [dmarc-ietf] what to document about the tree … Murray S. Kucherawy
- Re: [dmarc-ietf] what to document about the tree … Scott Kitterman
- Re: [dmarc-ietf] what to document about the tree … Barry Leiba
- Re: [dmarc-ietf] what to document about the tree … John Levine
- Re: [dmarc-ietf] what to document about the tree … Douglas Foster
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] what to document about the tree … Scott Kitterman
- Re: [dmarc-ietf] what to document about the tree … John R Levine
- Re: [dmarc-ietf] what to document about the tree … Murray S. Kucherawy
- Re: [dmarc-ietf] what to document about the tree … Dotzero
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] PSDs still aren't important, aga… John Levine
- Re: [dmarc-ietf] what to document about the tree … John R. Levine
- Re: [dmarc-ietf] what to document about the tree … Scott Kitterman
- Re: [dmarc-ietf] what to document about the tree … Alessandro Vesely
- Re: [dmarc-ietf] PSDs still aren't important, aga… Alessandro Vesely
- Re: [dmarc-ietf] PSDs still aren't important, aga… John Levine