Re: [dmarc-ietf] What is a policy domain? an org domain? How do we not break existing DMARC?
Douglas Foster <dougfoster.emailstandards@gmail.com> Sun, 27 February 2022 21:17 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 B57273A1340 for <dmarc@ietfa.amsl.com>; Sun, 27 Feb 2022 13:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCjPDmLb6RoG for <dmarc@ietfa.amsl.com>; Sun, 27 Feb 2022 13:17:18 -0800 (PST)
Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFA103A133F for <dmarc@ietf.org>; Sun, 27 Feb 2022 13:17:17 -0800 (PST)
Received: by mail-oo1-xc33.google.com with SMTP id d134-20020a4a528c000000b00319244f4b04so15958717oob.8 for <dmarc@ietf.org>; Sun, 27 Feb 2022 13:17:17 -0800 (PST)
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=G+NpJf4DLYKuQnpaIAiQv6psfHvjzl0GuuBkN5BlB9Q=; b=OHiqnGzIhpzjqOPJ/6Mgr0Hlj7xvZy+VzN3cg3BMBVEvqdlWf+6F57r72yQdbfGgGT BCURX3H7uFKzUr/A6BXDN1zGPrgEiKw7Z2wpcVNq9loijxZQ4oc/OJSQ5b5euP8zWXZh oURkvw5abQ/WDxJGD1obaZ3MhyU5MP+sxaU8eS40iGweRnerr1Uw40FCsU5xmgmXd7Rv VPSK+eRuBWnAQH3qKUDdgwAhaZT+YOGibql2t/vIscqI7pZiDbWK8B1eBQbH+bE95LUz Yg/VE3c5DDvCPoxGmdaKfa78uEnZTCKznc1fYnJXfesFvIYQtNg0nD+Hmr52G05H3/7n rggQ==
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=G+NpJf4DLYKuQnpaIAiQv6psfHvjzl0GuuBkN5BlB9Q=; b=sZq8S7LLi+6HvQe5uWbvMkq9CF0I4u2bNF0u5crGiVB3gw5qVTFdOjzAoSxyccW9oG 3YsJ4NA7Y3u5YeeztjvUxPeHVqHLsFjMWhhp1B3xqdEpxGCr2XKZSiZbVcwYmDlzOhq2 zDlRvKEt6phnYl/WHCTPztZt42ss8yn3K3sqUMToC+f08lsZQDQhhZtEIR2UTeNGNeX9 rmONikth1AVCBL+Q2f5XaiST6aGw1zfsSSkY7ObMAKlWK/yq5CURzwYlOMZHTD9keySK tmnhv82zsxhHL6i+8MQOmpkmcNWcdj7qWXRF+edeXVfSDvJx/PgM1rQIP+Jsj3cuABhv CDiQ==
X-Gm-Message-State: AOAM530LpnAqqAexoCTlr+AvU9dfkNR1rZCGrYmfjADnw6eq3F2BiOMI Pb1A/+/6T12AjZTPRqrxvObEB+WMswrNCU1HZvEEqe7w
X-Google-Smtp-Source: ABdhPJws5hMR8/VJDI5IcN37rDOEFFUz6/Wi9SKWxIAJvJCYZ5PGZEi91I7Nuc/7aBQN9a/GY1phjWRVwQDvRm6rPnM=
X-Received: by 2002:a05:6870:c98a:b0:d6:ffaf:931b with SMTP id hi10-20020a056870c98a00b000d6ffaf931bmr4320497oab.92.1645996636812; Sun, 27 Feb 2022 13:17:16 -0800 (PST)
MIME-Version: 1.0
References: <20220225205123.4C77737E87F2@ary.qy> <23124bf3-133b-45f0-4b92-1a48a29672fc@taugh.com> <CAH48Zfx6Uq8K5V+n2c4bfQtSGXhxRJVJzk+QLS+tZhUzPue9-g@mail.gmail.com> <45721479.oX8D4LbsGD@localhost>
In-Reply-To: <45721479.oX8D4LbsGD@localhost>
From: Douglas Foster <dougfoster.emailstandards@gmail.com>
Date: Sun, 27 Feb 2022 16:17:04 -0500
Message-ID: <CAH48ZfxUJPAVmCL891p7PtwdkbQ=_MJP-PR=9xmFjt2rmGdEtg@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d6bae805d90674af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/dwHCMYmZnT9N0rb7K74XBu66Gss>
Subject: Re: [dmarc-ietf] What is a policy domain? an org domain? How do we not break existing DMARC?
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: Sun, 27 Feb 2022 21:17:23 -0000
If you are determined to submit your own text, perhaps you could read and acknowledge the draft that has already been posted. On Sat, Feb 26, 2022, 7:41 PM Scott Kitterman <sklist@kitterman.com> wrote: > Which has nothing to do with what is a policy domain, an org domain, or > how > not to break existing DMARC. As I suggested earlier, we can decide what > to > call the tags independent of the policy lookup and org domain > determination. > I think we have those things resolved, modulo me having time to write it > up in > detail. Perhaps you could start a new thread on this topic. > > Scott K > > On Saturday, February 26, 2022 6:19:25 PM EST Douglas Foster wrote: > > It helps to know the assumptions that have led John to such incorrect > > conclusions. > > > > When moving from a PSL to the DNS, the primary obstacle has always been > > missing information. Therefore, one goal of this project is exactly to > > induce people to update their DMARC records, to supply information that > is > > currently missing. We are attempting to do what DBOUND tried and failed > > to do - insert boundary information into DNS using information published > by > > registrars and the registered organizations. > > > > Ale has correctly assessed that in the new design, a DMARC record can > play > > one of four roles. Evaluators must code for all four of these > > possibilities, regardless of how many token values we define. With four > > roles, we have five information states: explicit indicators for > Registrar, > > Org, Both, None, and the fallback result of NULL. Anyone who has ever > > tried to interpret incomplete data knows that a null result is different > > from a default value, and that explicit data is always preferable to > > guessing a default value to use when confronted with null. > > > > Evaluators will be required to cope with a NULL result by assigning those > > policy records to one of the four roles. The assigned role will be > > context-sensitive, which is one of the reasons that NULL and NONE are not > > equivalent. Fortunately, we expect that the correct default can be > > applied most of the time. However, the proposal to project five states > > into three, using "psd=(y,n,null)", is an unforced error that cannot be > > justified. > > > > There is also a huge communication error introduced by assuming that > > "psd=n" will be reliably configured to mean "org=y". There are a > > relatively small number of registrars who will be publishing DMARC > > information, against millions of organizations that are publishing, or > will > > publish, DMARC policies. We need the language optimized to ensure that > > organizations publish their flag data correctly. > > > > We also have a nomenclature problem connected to the choice of > "psd=value" > > as a token. We have recognized that there are public registrars and > > private registrars, and that DMARC must cope with both types. Private > > registrars are not PSOs and we should not bless them with a title that > they > > do not deserve. Our document needs to be updated to reflect this > > reality. Throughout the text, we should have "Registrars", and > > "Registration Domains", not PSOs and PSDs, except for introductory > material > > where we explain the difference between the two and its implications for > > tree walk. The registrar role should be indicated with "REG", not with > > "PSD". > > > > Doug Foster > > > > On Sat, Feb 26, 2022 at 12:14 PM John R Levine <johnl@taugh.com> wrote: > > > >> No. This just adds more useless complexity that is unlikely to get > > > > > > implemented. > > > > > > > While composing a DMARC record, setting role=org seems more likely > than > > > > > > psd=n. > > > > > > For the umpteenth time, the goal here is to be as compatible as > possible > > > with the way that DMARC works now. An important part of that is not to > > > ask people to change their existing DMARC records because we know that > > > most of them won't. > > > > > > The normal case, like 99.99% of the time, is that the PSD does not > publish > > > a DMARC record at all. The org domain has a DMARC record if it sends > mail > > > or its subdomains use relaxed alignment. The way Scott and I propose > to > > > do a tree walk, that will get the same alignment as now with no > changes to > > > the DMARC record. That includes millions, maybe tens of millions of > > > domains. > > > > > > A few PSDs publish DMARC records, either because they have a policy > about > > > their registrants' mail, or because the PSD itself has an MX. We want > > > them to add psd=y. That includes 52 domains. (I counted them.) > > > > > > As an extreme corner case, if you are registered under a PSD that > > > publishes a DMARC record but erroneously doesn't include psd=y, you > can > > > use psd=n as a kludge to prevent evil sibling alignment. That > currently > > > includes about 45 of those 52 domains, but I think we can get it close > to > > > zero because we have contacts at many of them. > > > > > > I'm finding it hard to understand the advantage of a scheme that > requires > > > millions of DMARC records to change rather than one that changes 52. > > > > > > Regards, > > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > > Please consider the environment before reading this e-mail. > https://jl.ly > > > > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
- [dmarc-ietf] Let's Work on the Tree Walk Text Todd Herr
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Todd Herr
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John R Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Alessandro Vesely
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Alessandro Vesely
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John R Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text John Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Alessandro Vesely
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Alessandro Vesely
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Alessandro Vesely
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Douglas Foster
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] Let's Work on the Tree Walk Text Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Alessandro Vesely
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … Alessandro Vesely
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Alessandro Vesely
- Re: [dmarc-ietf] What is a policy domain? an org … John R Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Alessandro Vesely
- Re: [dmarc-ietf] What is a policy domain? an org … John Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster
- Re: [dmarc-ietf] What is a policy domain? an org … Scott Kitterman
- Re: [dmarc-ietf] What is a policy domain? an org … Alessandro Vesely
- Re: [dmarc-ietf] What is a policy domain? an org … John R Levine
- Re: [dmarc-ietf] What is a policy domain? an org … Douglas Foster