This feels too complicated, and like it adds back in complexity that jumps between labels, which was the exact confusion (jumping instead of walking) that the tree walk aimed to fixed.
Seth, hatless On Fri, Feb 24, 2023 at 12:21 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 > -- *Seth Blank * | Chief Technology Officer *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
