Re: [dmarc-ietf] "psd=" tag early assignment
Douglas Foster <dougfoster.emailstandards@gmail.com> Tue, 12 July 2022 00:57 UTC
Return-Path: <dougfoster.emailstandards@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 3314CC16ECB6 for <dmarc@ietfa.amsl.com>; Mon, 11 Jul 2022 17:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level:
X-Spam-Status: No, score=-2.103 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_DNSWL_BLOCKED=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, 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=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 mBhk9LgR1PxU for <dmarc@ietfa.amsl.com>; Mon, 11 Jul 2022 17:57:35 -0700 (PDT)
Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 0CAF1C15A733 for <dmarc@ietf.org>; Mon, 11 Jul 2022 17:57:30 -0700 (PDT)
Received: by mail-oi1-x22c.google.com with SMTP id s188so8743618oib.6 for <dmarc@ietf.org>; Mon, 11 Jul 2022 17:57:29 -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; bh=XE0eg8Xq6/qLsIV1NeHiW3G1ZAcWRqdvvw1+wpI2RKE=; b=N+caUvBnH1Fw9jG8GEZs08fqjgSNO3sGMF3r02RYCw7jfybra28rwlYI4tu7omEllo xrVf3TfE70AJUTVlVtpi2D+lxs5lFr4NGDyGQ+hMfrMzAjrK+jIyESQBr59IYtNaj1oW Yh5KKhSyG3i5dkQRAMEdbUFfV0apXM1VL+yWL+1/tvyPUF+Oe92zn+aItxDKKS98Cr8C 288Vr0lIXVjare53Ej5Eu1QMjuq78TIJ3GgHdl5QCbxCSyZ6nyGsM6vtYEt3yc2gXKkU Px7jwZJoa0dmTdbQlzKWcHwN219Tx0og6EEB8IinpkeVx7/ZND5jBsZo8vcmWna2focD bhYA==
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; bh=XE0eg8Xq6/qLsIV1NeHiW3G1ZAcWRqdvvw1+wpI2RKE=; b=wHgdang0yNTCYxxv7FEFRNRXYPpDeLEc867QwzENBxzlozxRC/zYJiBeChObN9jN6V DiO8d9afkf3OvBUbWFMvbyQbzxW/PfaeOzogvEMwD2dbtX6q1J2h6+QZUPwq+cqODs5R 6YKJ79ft/MjFn1RjnyaB2v90SYnJrLcPwajJsQ3a/HI6VknYJAZ5tlixl7myjENpJmli PSwb0sk6FyKPcsxuw8fBSbLWC/SyKy4ehwi7RPr2VPAwUKpOPiIVkzBoZErN4mBVvoQK JFn4BRKsVkyA5eIrIgKbmlin/yyOh4yBxsYqCTNTqcMofZhDopkM+xgYVwa+WpsBlidE 8J9w==
X-Gm-Message-State: AJIora9GARalxy3/r/4OseBH3UVBoMg4cWVBAD5QXSkHmRVWIXeB4ud+ qeVXbBBwz6w4FN1tv2bM7f3hEiBhPZvazSnXD7iuvcxt
X-Google-Smtp-Source: AGRyM1tmWJT2ks5rY2GPCqAqfNCAOmBrpxR0W7VWCO5VALoh5sAHf5zQnFlBBC4bNdZo1wVfb3voupd1oCVkzARkgR0=
X-Received: by 2002:aca:1803:0:b0:337:e764:9927 with SMTP id h3-20020aca1803000000b00337e7649927mr684757oih.51.1657587448842; Mon, 11 Jul 2022 17:57:28 -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>
In-Reply-To: <c4a7fd03-eae8-497f-3133-73523a9c1ca2@tana.it>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Mon, 11 Jul 2022 20:57:20 -0400
Message-ID: <CAH48ZfxnAyD6dBoT7kuX9TL0q0i+y3=UNxao0f506vurACnhLg@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000128d1f05e391271c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/sfGjLbhfFuZqFbJPvjAxo9XlI3o>
Subject: Re: [dmarc-ietf] "psd=" tag early assignment
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: Tue, 12 Jul 2022 00:57:37 -0000
We should talk about "correct results". The PSL gets the correct results in 99-dot-something percent of messages, but we are proposing a new algorithm because it is wrong on some fraction of a percent. The size of the fraction is not a reason to ignore a problem. I support a change. But is the proposed change an improvement? We also think the proposed tree walk will also return a correct result in 99-dot-something percent. But are they better answers? On what basis would we answer that question? What matters is whether the new algorithm produces correct answers when the PSL produces wrong ones, and whether it does this without introducing new errors that are not present in the PSL solution. On that question, the answer is at best uncertain. When the PSL and Tree Walk produce different results, we simply have no basis for choosing between the two, because the proposed Tree Walk is sourced on no new information. However, when the Tree Walk result is based on explicit tagging provided by the domain owner, then we do have a better answer than the PSL, because the domain owner knows more about his organizational structure than the PSL volunteers, and we have every reason to trust the domain owner's assertions. Consequently, we need DMARC policies that explicitly identify the organization domain and explicitly document the presence or absence of private registries. This is why I have proposed tags to that effect, with full intent of encouraging domain owners to use them. An alternate solution is to encourage domain owners to use exact-match identifiers, but we assume that option is a non-starter. Doug On Mon, Jul 11, 2022, 7:29 AM Alessandro Vesely <vesely@tana.it> wrote: > On Sun 10/Jul/2022 19:04:08 +0200 Scott Kitterman wrote: > > > On July 10, 2022 11:17:13 AM UTC, Alessandro Vesely <vesely@tana.it> > wrote: > >> On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote: > >>> It appears that Scott Kitterman <sklist@kitterman.com> said: > >>>> On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely <vesely@tana.it> > wrote: > >>>>>>> Yeah, /should/! The very fact that you yourself changed your mind > about how it works, without going into the hassle of explaining your > reasoning, > >>>>>> Um, what? Scott and I went through some rounds of debugging to be > sure the tree walk handled some obscure edge cases in a reasonable way. It > was all on this very mailing list with examples. I think what we have now > is OK but if you find something in the tree walk that is unclear or gets an > unreasonable result, let us know, preferably with a concrete example.>>> > >>>>> I think I received all list messages (although I don't check against > your weekly count) and I read all of them. Perhaps I've been inattentive, > but I don't recall the switch from stop on psd=y to continue on psd=y if > it's the first lookup. Any pointer?>> > >>>> I don't recall having changed this. If you can check the previous > draft revisions to see when it changed, maybe I could find it. I'm > confident that any changes to the way the tree walk works have been > discussed on the list.> > >>> I changed it in a pull request a few weeks ago. > >>> > >>> If you don't stop on the first psd=y that is not the original domain, > >>> you get the wrong result if there are DMARC records above the psd=y. > >> > >> That's undoubtedly correct. The point I'm raising is the one at point > 2 (both sections). For org discovery, it's in the hunk tagged @@ -720,13 > +722,13 @@ in the same pull request, here: > >> > https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47/files#diff-758de98ab8f970604c5891fceb8cb498ffe212c02060fdbf0e6ee5bffbb0a3cbL720 > >> > >> That affects messages From: psd@c.b.a, in John's example below. In > that case, the change sets the org domain at b.a (assuming that blah stands > for a DMARC record) instead of c.b.a. That is, a PSD domain itself is a > regular subdomain of the org domain below. Apart from slightly > complicating the algorithm, that might be a reasonable position. IIRC, it > wasn't discussed on list. More importantly, it isn't explained in the > draft. > > > > I don't understand what you want. > > > An appendix exposing a walk through the algorithm. > > > > I think (and I might be wrong) you agree the current draft gets the > correct results, but you think there was some kind of process foul about > how it got fixed. > > > > I don't think your assertion that it wasn't discussed is correct. > > > Well, we're discussing it now. However, we're keeping on a meta-level > above the matter. > > > > John posted a pointer to the changes [1] and asked for comment. You > participated in the thread. I don't know what else you want. If a > document author provides proposed changes and no one asks questions about > one of the changes, I don't think it's incumbent upon the author to point > out not everything was discussed. > > > I reviewed the thread you cited. I did ask questions about one of the > changes when I replied. John's answer, however, simply repeated the > words of the draft. He previously only said that if you are sending > mail you are not really a PSD. Then, one may wonder whether a filter > should still consider a specific psd=y to be an error if it is going > to meet it in subsequent steps, because once it received mail (or > signatures) from that domain. > > > > I also don't know what explanation you want in the draft. In my > experience, IETF documents focus on what to do and do not generally have > significant expositions on why or all the potential implications of a > particular design choice. > > > We are proposing an alternative to the PSL without having any > experience of it. I think a Proposed Standard should give full > explanations of design choices, so that possible, future amendments > can be thoughtful and considered. > > > > As I said in that thread, I think going too far into corner cases like > this is likely to make the document more confusing. > > > An appendix is usually not normative, and people not interested in > delving into the specific detail just skip it. > > > > Finally, I struggle to understand how this detail is relevant to the > question of early assignment of psd=? > > > It is not. Neither suggests a better term. > > > > Please help me understand what the issue is here? It might be useful > for you to start a new thread with specific text you think needs to be in > the document? > > > Hm... could do. > > > Best > Ale > -- > > > [1] > https://mailarchive.ietf.org/arch/msg/dmarc/OaaC-N1MV-JlnpdDm0HTMVeSQrs/ > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [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