Barry, I think you have forgotten that organizational domain is needed for relaxed alignment as well as disposition request. You cannot do relaxed alignment correctly unless you find and use the correct organizational domain.
The current text has an incentive problem. For an evaluator, the PSL works fine. Unless an evaluator is Google-class, receiving mail from everywhere in the world, most of the PSL entries will never be examined and most of the PSL errors will never be exposed. When an error is detected by an evaluator, it is a trivial effort to add or remove a record from the local copy of PSL. For evaluators, the PSL works fine. Domain owners / message senders are the ones who should be powerfully motivated to replace the PSL. If so, they should be willing to add a tag that invokes MUST USE TREE WALK because it eliminates ambiguity and protects them from the PSL. With that elimination of ambiguity and corresponding MUSRT, evaluators have a reason to change. Without that, evaluators have every reason to ignore this new, unproven, and imperfect algorithm; DF On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba <barryle...@computer.org> wrote: > I think the failure of this thinking is the idea that there's any > intent going on at cuny.edu, and we need to remind ourselves that it's > a *hierarchy*, and that that word means something specific. In a > hierarchy you expect to inherit things *through* the hierarchy, > without skipping levels. No one expects to inherit from a grandparent > and *not* from the parent: that's not how hierarchies work. > > The fact that using the PSL resulted in that is unintentional and is > extremely unlikely to be what anyone wanted. It's far more likely > that it's just what happened, without intent, and that no one noticed > nor cared. > > I don't think there's anything to fix here, as the tree walk has > already fixed this anomaly. Letting people put the anomaly back in > with a confusing tag that no one will ever deploy doesn't seem to be a > good approach. The real answer for anyone who needs to jump the > hierarchy for some reason is that they simply need to put in an > explicit DMARC record, and they get exactly what they want, *whatever* > that is. > > Now, if we can find any real-world cases where that isn't practical -- > something like a whole load of subdomains of bmcc.cuny.edu that truly > want to skip up and inherit from cuny.edu instead and will be broken, > rather than fixed, by tree walk -- then I really do want to hear about > that, and then I would think we need to revisit this. I do not think > that now. > > Barry > > On Sun, Feb 26, 2023 at 2:40 PM Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > > > I don't see that we have the right to tell cuny.edu and others that we > have sacrificed them to the greater good. We know exactly what their > configuration means under RFC 7489, and we need to make it supportable. > > > > We have talked about three ways of guessing the organizational domain: > > - PSL > > - Tree Walk with top-most policy selected > > - Tree Walk with bottom-most policy selected > > I am belatedly on-board that the last option is the least bad, but they > are all bad because they involve guessing. > > > > PSL is particularly hard on domain owners that have been victimized by > PSL errors (which can never be fully corrected), so domain owners have a > big stake in making the new algorithm work. I don't see how we can > propose unilaterally changing one end of the protocol without changing the > other end of the protocol as well. A configuration which is optimized for > RFC 7489 cannot be assumed to be optimized for DMARCbis. > > > > Alex and Ale have the right idea, because a DMARCbis-compliant policy > record should eliminate guessing completely. My variant of their concept > is to add this term to the DMARC policy: > > org=n, > > where > > > > n is the number of DNS segments in the organizational domain > > and is therefore a number between 2 and 4 > > and is less than or equal to the number of DMARC segments in the current > policy domain. > > > > When org=n matches the number of segments in the current policy, this is > explicitly asserted to be the organizational domain. > > > > Benefits: > > 1) The policy walk stops at the first policy, gaining all the > performance efficiency of the current walk definition. > > 2) Relaxed alignment is determined with simple compares: The "org=n" > values must be identical on both domains, and the rightmost N segments of > both domain names must be identical. > > 3) Domain owner is in full control of the computed organizational > domain. No more guessing. > > > > Protecting against malicious impersonation of a parent domain: > > 1) The policies selected for the From domain and the authenticating > domain must both contain the same org=n term. > > 2) The organizational domain policy must be queried, must exist, and > must contain the same org=n term. This helps to prevent impersonation of > private registry and PSO domains. > > 3) Private registries and PSOs can protect themselves against > child-to-parent impersonation by (a) not publishing a DMARC policy or (b) > by publishing a policy with the PSD=Y term. > > > > If the org=n terms are not uniformly present, the policy is treated as > an RFC7489-compliant policy definition. Evaluators can choose between > the PSL, the Tree Walk, and local policy rules, whichever technique they > consider to be the most error-free. > > > > The aggregate reports should indicate whether the Tree Walk or RFC7489 > were used for evaluation, and should explicitly indicate whether alignment > was detected or not. > > > > DF > > > > > > On Sun, Feb 26, 2023 at 1:13 AM Barry Leiba <barryle...@computer.org> > wrote: > >> > >> What does the proposal add that's useful? The current situation > >> appears to be what we'd want: with the tree walk, ret.bmcc inherits > >> the p=quarantine from bmcc. If it wants otherwise, it can specify it > >> explicitly. Saying it wants to inherit from cuny.edu but wants to use > >> bmcc's p= policy... is odd. Where's the benefit? > >> > >> For me, the bottom line is that either you inherit from your parent... > >> or you don't want to and you specify that with an explicit record. > >> What, beyond that, is useful? > >> > >> Barry > >> > >> On Fri, Feb 24, 2023 at 12:21 PM Brotman, Alex > >> <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: > >> > > >> > While discussing this with someone at the conference yesterday, we > thought perhaps we could introduce something of a referral. > >> > > >> > Currently: > >> > _dmarc.ret.bmcc.cuny.edu NULL > >> > _dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; rua=mailto: > dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > >> > _dmarc.cuny.edu "v=DMARC1;p=none;rua=mailto: > dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu > ;ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto: > post.mas...@cuny.edu;fo=1" > >> > > >> > Proposed: > >> > _dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; > fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto: > dmarc_...@emaildefense.proofpoint.com" > >> > > >> > Adding the "sp=refer:cuny.edu" would allow the existing policy to be > used for undeclared subdomains under the third-level domain. This could be > useful in the situation where an OrgDomain would like to still maintain > some control over policy for the undeclared domains. > >> > > >> > We didn't give it a ton of thought, so if others believe it to be > problematic, that's understandable. > >> > > >> > -- > >> > Alex Brotman > >> > Sr. Engineer, Anti-Abuse & Messaging Policy > >> > Comcast > >> > > >> > > -----Original Message----- > >> > > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Alessandro Vesely > >> > > Sent: Friday, February 24, 2023 6:54 AM > >> > > To: dmarc@ietf.org > >> > > Subject: Re: [dmarc-ietf] Treewalk causing changes > >> > > > >> > > As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is > >> > > bmcc.cuny.edu, so the policy is p=quarantine. However, the > organizational > >> > > domain is cuny.edu, so a signature having d=anothersub.cuny.edu is > aligned. > >> > > > >> > > Correct? > >> > > > >> > > Best > >> > > Ale > >> > > > >> > > > >> > > On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote: > >> > > > I don't understand your point here, Doug. It seems more likely > that a > >> > > > subdomain of a subdomain should be following the latter > subdomain's > >> > > > policy by default, rather than the higher-level domain's. That > is, > >> > > > for a.b.c.d, "a" would be more likely to expect to follow "b" than > >> > > > "c". Which means that the tree walk will give the desired result > when > >> > > > the PSL would generally not have done so. > >> > > > > >> > > > Are you disagreeing with that, as it seems? Or am I > misunderstanding you? > >> > > > > >> > > > Barry > >> > > > > >> > > > On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster > >> > > > <dougfoster.emailstanda...@gmail.com> wrote: > >> > > >> > >> > > >> I seem to have missed this redesign. I thought the plan had > always been to > >> > > take the top-most policy not flagged as PSD=Y. Taking the first > policy found is > >> > > less work, but it turns subdomain policies into organizational > domain policies. I > >> > > expect that to be an unwanted surprise to many domain owners, since > the > >> > > subdomain policies will typically lack an sp clause. > >> > > >> > >> > > >> On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman < > skl...@kitterman.com> > >> > > wrote: > >> > > >>> > >> > > >>> I don't find this to be a surprise. > >> > > >>> > >> > > >>> I believe we discussed this specific type of case early in the > tree walk > >> > > discussion. An early proposal was to walk up the tree to find the > PSD and then > >> > > reverse back down the tree to find the org domain (PSD +1). This > approach > >> > > would have provided an identical result to the PSL design for this > case, but we > >> > > concluded the added complexity and potential other issues made it > not the best > >> > > approach. > >> > > >>> > >> > > >>> Up to now, I don't think anyone has suggested that DMARCbis > needs to > >> > > produce 100% identical results with RFC 7489. We know it won't, > but the > >> > > differences are at the margins and we assessed that they're okay. > >> > > >>> > >> > > >>> Scott K > >> > > >>> > >> > > >>> > >> > > >>> On February 24, 2023 12:36:03 AM UTC, Barry Leiba > >> > > <barryle...@computer.org> wrote: > >> > > >>> >The issue here, Tim, is that the current way of checking the > PSL > >> > > >>> >would send you to the DMARC record for cuny.edu and p=none, > while > >> > > >>> >using the new tree walk would send you to the DMARC record for > >> > > bmcc.cuny.edu and p=quarantine. > >> > > >>> > > >> > > >>> >In this case, it’s showing that the tree walk is the better > >> > > >>> >mechanism, because it’s pretty clear that it matches the > >> > > >>> >publisher’s intent. But Elizabeth is pointing out that it DOES > >> > > >>> >change the result, which means that the result depends upon > which > >> > > >>> >version of the DMARC spec the receiving domain is using. > >> > > >>> > > >> > > >>> >Barry > >> > > >>> > > >> > > >>> >On Thu, Feb 23, 2023 at 3:51 PM Tim Wicinski < > tjw.i...@gmail.com> > >> > > wrote: > >> > > >>> > > >> > > >>> >> > >> > > >>> >> Elizabeth, > >> > > >>> >> > >> > > >>> >> (speaking as a DNS person). I think this is "OK" - at my > last > >> > > >>> >> job we set up DMARC records which stricter in certain > subdomains > >> > > >>> >> than the parent domain. (Now I need to go find the machine > where > >> > > >>> >> I left my code which did all this validation). > >> > > >>> >> > >> > > >>> >> > >> > > >>> >> (As a DNS person I want to find the folks who put in the TXT > >> > > >>> >> record for _ dmarc.cuny.edu and ask them to quote their > string. > >> > > >>> >> But that's my OCD). > >> > > >>> >> > >> > > >>> >> tim > >> > > >>> >> > >> > > >>> >> > >> > > >>> >> On Thu, Feb 23, 2023 at 5:30 PM Elizabeth Zwicky <zwicky= > >> > > >>> >> 40otoh....@dmarc.ietf.org> wrote: > >> > > >>> >> > >> > > >>> >>> > >> > > >>> >>> I haven’t done extensive research but here is a live example > >> > > >>> >>> where treewalk will cause a result change. > >> > > >>> >>> > >> > > >>> >>> From: is in the domain Ret.bmcc.cuny.edu which has no > DMARC record. > >> > > >>> >>> > >> > > >>> >>> _dmarc.bmcc.cuny.edu. 300 IN TXT "v=DMARC1; > p=quarantine; > >> > > >>> >>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; > >> > > ruf=mailto: > >> > > >>> >>> dmarc_...@emaildefense.proofpoint.com" > >> > > >>> >>> > >> > > >>> >>> _dmarc.cuny.edu. 3325 IN TXT "v=DMARC1;" > "p=none;" > >> > > >>> >>> "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto: > >> > > >>> >>> post.mas...@cuny.edu;" > >> > > >>> >>> "ruf=mailto:dmarc_...@emaildefense.proofpoint.com > >> > > >>> >>> ,mailto:post.mas...@cuny.edu;"; "fo=1" > >> > > >>> >>> > >> > > >>> >>> Elizabeth Zwicky > >> > > >>> >>> _______________________________________________ > >> > > >>> >>> dmarc mailing list > >> > > >>> >>> dmarc@ietf.org > >> > > >>> >>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf > >> > > >>> >>> > >> > > o/dmarc__;!!CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwM > >> > > >>> >>> uukRSdaNZHWyhEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > > >>> >>> > >> > > >>> >> _______________________________________________ > >> > > >>> >> dmarc mailing list > >> > > >>> >> dmarc@ietf.org > >> > > >>> >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo > >> > > >>> >> > >> > > /dmarc__;!!CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwMuu > >> > > >>> >> kRSdaNZHWyhEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > > >>> >> > >> > > >>> > >> > > >>> _______________________________________________ > >> > > >>> dmarc mailing list > >> > > >>> dmarc@ietf.org > >> > > >>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dm > >> > > >>> > >> > > arc__;!!CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwMuukRSd > >> > > aN > >> > > >>> ZHWyhEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > > >> > >> > > >> _______________________________________________ > >> > > >> dmarc mailing list > >> > > >> dmarc@ietf.org > >> > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dma > >> > > >> > >> > > rc__;!!CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwMuukRSda > >> > > NZH > >> > > >> WyhEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > > > > >> > > > _______________________________________________ > >> > > > dmarc mailing list > >> > > > dmarc@ietf.org > >> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmar > >> > > > > >> > > c__;!!CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwMuukRSdaN > >> > > ZHWy > >> > > > hEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > > > >> > > _______________________________________________ > >> > > dmarc mailing list > >> > > dmarc@ietf.org > >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__ > ;! > >> > > !CQl3mcHX2A!B_Bf1vMKDjGBQFyTPOn3IjLfkuf0NttoF0aHqKSwMuukRSdaNZHW > >> > > yhEPD1_sSUCElho2Xwvc6xqMYhNIhBw$ > >> > _______________________________________________ > >> > 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 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
