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
