Re: [dmarc-ietf] Treewalk causing changes
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 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 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 > > > 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 > > 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 > > 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 > > wrote: > > >>> > > > >>> >> > > >>> >> Elizabeth, > >
Re: [dmarc-ietf] Treewalk causing changes
I don't understand the issue here: either ret.bmcc inherits from bmcc... or it publishes its own. Why would anything else make sense? Barry On Sat, Feb 25, 2023 at 2:29 AM Alessandro Vesely wrote: > > On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex 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. > > > I like the ability of allowing a subdomain to publish its own policy without > affecting further subdomains. Indeed, bmcc.cuny.edu features a list of NSes > different from cuny.edu. Now, ret.bmcc.cuny.edu has no NS record, but has an > MX different from bmcc. Clearly its mail management is independent. > > OTOH, we cannot force bmcc to monitor the p= and sp= tags of their parent > domain and change their own sp= tag accordingly. > > However, I dislike refer:cuny.edu. What if they published refer:outlook.com? > > Rather I'd propose sp=inherit. A receiver has to navigate to cuny.edu anyway > if it needs to establish the organizational domain, so it can retrieve the > policy as well. > > > Best > Ale > -- > > > > > > > > > ___ > 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
Re: [dmarc-ietf] Treewalk causing changes
On February 26, 2023 12:15:09 AM UTC, John Levine wrote: >It appears that Alessandro Vesely said: >>I like the ability of allowing a subdomain to publish its own policy without >>affecting further subdomains. > >I very much do not. It adds vast complexity with insignificant value. > >If you care what policies your subdomains publish, call them up and >talk to them. If you don't know their phone numbers, you have much >larger problems than DMARC can solve. Agreed. Let's move on. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
It appears that Alessandro Vesely said: >I like the ability of allowing a subdomain to publish its own policy without >affecting further subdomains. I very much do not. It adds vast complexity with insignificant value. If you care what policies your subdomains publish, call them up and talk to them. If you don't know their phone numbers, you have much larger problems than DMARC can solve. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
Ale, On Sat, Feb 25, 2023 at 5:29 AM Alessandro Vesely wrote: > On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex 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. > > > I like the ability of allowing a subdomain to publish its own policy > without > affecting further subdomains. Indeed, bmcc.cuny.edu features a list of > NSes > different from cuny.edu. Now, ret.bmcc.cuny.edu has no NS record, but > has an > MX different from bmcc. Clearly its mail management is independent. > > Are you sure? # dig cuny.edu NS +noall +answer cuny.edu. 3600 IN NS ext-ns1.columbia.edu. cuny.edu. 3600 IN NS ns10.customer.level3.net. cuny.edu. 3600 IN NS ns15.customer.level3.net. cuny.edu. 3600 IN NS acme.ucc.cuny.edu. cuny.edu. 3600 IN NS lavinia.cis.cuny.edu. # dig bmcc.cuny.edu NS +noall +answer bmcc.cuny.edu. 300 IN NS ns10.customer.level3.net. bmcc.cuny.edu. 300 IN NS ext-ns1.columbia.edu. bmcc.cuny.edu. 300 IN NS ns15.customer.level3.net. bmcc.cuny.edu. 300 IN NS acme.ucc.cuny.edu. bmcc.cuny.edu. 300 IN NS lavinia.cis.cuny.edu. they look the same to me tim OTOH, we cannot force bmcc to monitor the p= and sp= tags of their parent > domain and change their own sp= tag accordingly. > > However, I dislike refer:cuny.edu. What if they published refer: > outlook.com? > > Rather I'd propose sp=inherit. A receiver has to navigate to cuny.edu > anyway > if it needs to establish the organizational domain, so it can retrieve the > policy as well. > > > Best > Ale > -- > > > > > > > > > ___ > 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
Re: [dmarc-ietf] Treewalk causing changes
On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex 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. I like the ability of allowing a subdomain to publish its own policy without affecting further subdomains. Indeed, bmcc.cuny.edu features a list of NSes different from cuny.edu. Now, ret.bmcc.cuny.edu has no NS record, but has an MX different from bmcc. Clearly its mail management is independent. OTOH, we cannot force bmcc to monitor the p= and sp= tags of their parent domain and change their own sp= tag accordingly. However, I dislike refer:cuny.edu. What if they published refer:outlook.com? Rather I'd propose sp=inherit. A receiver has to navigate to cuny.edu anyway if it needs to establish the organizational domain, so it can retrieve the policy as well. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
