Oh well. It is hardly the first time that consensus did not involve my consent.
On Thu, Feb 23, 2023, 9:03 PM Barry Leiba <barryle...@computer.org> 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://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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
