Re: [dmarc-ietf] Treewalk causing changes
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 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 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 >>
Re: [dmarc-ietf] Treewalk causing changes
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 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 > 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 >
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Feb 26 06:00:03 2023
Count| Bytes | Who ++--- 40 ( 100%) | 398053 ( 100%) | Total 6 (15.0%) | 40240 (10.1%) | Alessandro Vesely 5 (12.5%) | 91685 (23.0%) | Douglas Foster 5 (12.5%) | 31894 ( 8.0%) | Scott Kitterman 5 (12.5%) | 27581 ( 6.9%) | John R Levine 4 (10.0%) | 41748 (10.5%) | Barry Leiba 3 ( 7.5%) | 17545 ( 4.4%) | Dave Crocker 2 ( 5.0%) | 37967 ( 9.5%) | Brotman, Alex 2 ( 5.0%) | 26253 ( 6.6%) | Tim Wicinski 2 ( 5.0%) | 5836 ( 1.5%) | 1 ( 2.5%) | 32350 ( 8.1%) | Seth Blank 1 ( 2.5%) | 18546 ( 4.7%) | Trent Adams 1 ( 2.5%) | 8339 ( 2.1%) | Elizabeth Zwicky 1 ( 2.5%) | 6635 ( 1.7%) | Emil Gustafsson 1 ( 2.5%) | 6163 ( 1.5%) | Dotzero 1 ( 2.5%) | 5271 ( 1.3%) | John R. Levine ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
On Sun 26/Feb/2023 07:13:04 +0100 Barry Leiba 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? AIUI, Alex proposal is meant to soften the result change caused by the tree walk. Currently, subdomains inherit from the org domain. With tree walk, they inherit from the nearest ancestor. Why? As Alex pointed out, we didn't give it a ton of thought. Just note that it is not for saving lookups, since alignment evaluation requires to navigate to the org domain anyway. 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? Allow an intermediate subdomain to publish its own record without interfering with all the policies of the tree downwards. The complexity of the tree walk is not overturned by providing for inheritance. It would allow, for example, to add a rua= address without interfering with policy changes. A minimal change to ease a task, DNS maintenance, which we know to be hardly reachable by email staff. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Treewalk causing changes
On Sun 26/Feb/2023 00:19:57 +0100 Tim Wicinski wrote: On Sat, Feb 25, 2023 at 5:29 AM Alessandro Vesely wrote: On Fri 24/Feb/2023 21:21:15 +0100 Brotman, Alex wrote: 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 Oops, you're right. When I queried it I got a very different order ... Difference in mail management can be inferred from MX: $ dig +noall +answer cuny.edu mx cuny.edu. 3600IN MX 10 mail-relay.cuny.edu. $ dig +noall +answer bmcc.cuny.edu mx bmcc.cuny.edu. 1800IN MX 10 mxb-00029401.gslb.pphosted.com. bmcc.cuny.edu. 1800IN MX 10 mxa-00029401.gslb.pphosted.com. $ dig +noall +answer ret.bmcc.cuny.edu mx ret.bmcc.cuny.edu. 300 IN MX 10 ret-bmcc-cuny-edu.mail.protection.outlook.com. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
