Re: [dmarc-ietf] Treewalk causing changes

Okay. That was my understanding, but wanted to make sure it was crystal clear. Thanks for the clarification. On Thu, Mar 9, 2023, 2:53 PM John Levine wrote: > It appears that Mark Alley said: > >-=-=-=-=-=- > > > >This question probably has an obvious answer, but asking for > >clarification on

Re: [dmarc-ietf] Treewalk causing changes

It appears that Mark Alley said: >-=-=-=-=-=- > >This question probably has an obvious answer, but asking for >clarification on this - Policy difference aside, in this example >provided, does this mean with the Treewalk behavior, cuny.edu's DMARC >feedback addresses that differ from the subdom

Re: [dmarc-ietf] Treewalk causing changes

This question probably has an obvious answer, but asking for clarification on this - Policy difference aside, in this example provided, does this mean with the Treewalk behavior, cuny.edu's DMARC feedback addresses that differ from the subdomain's would stop getting the sub's DMARC reports? -

Re: [dmarc-ietf] Treewalk causing changes

We are stopping at the bottom-most policy because we cannot know for certain whether the parent is part of the organization, or a private registrar. We are also inclined to assume that the difference does not matter, because RFC 7489 allows relaxed alignment to be more relaxed than complex organiz

Re: [dmarc-ietf] Treewalk causing changes

On Wed 01/Mar/2023 16:28:49 +0100 Scott Kitterman wrote: On March 1, 2023 3:08:16 PM UTC, Jesse Thompson wrote: On 3/1/2023 6:12 AM, Douglas Foster wrote: A sub-issue to consider:   Should we do a Tree Walk on the authenticating domain? For example, assume that "virgina.gov

Re: [dmarc-ietf] Treewalk causing changes

On March 1, 2023 3:08:16 PM UTC, Jesse Thompson wrote: >On 3/1/2023 6:12 AM, Douglas Foster wrote: > >> A sub-issue to consider:   Should we do a Tree Walk on the authenticating >> domain? >> For example, assume that "virgina.gov " and >> "dmas.virginia.gov

Re: [dmarc-ietf] Treewalk causing changes

On 3/1/2023 6:12 AM, Douglas Foster wrote: > A sub-issue to consider:   Should we do a Tree Walk on the authenticating > domain? > For example, assume that "virgina.gov " and > "dmas.virginia.gov " both have DMARC policies with > relaxed alignment. 

Re: [dmarc-ietf] Treewalk causing changes

Mark and Laura's perspective solves my objections. We propose a deliberate change to use the bottom-most policy because we believe it better meets the needs of large organizations, of which regional governments are a good example. A supporting benefit is that we eliminate the possibility of false

Re: [dmarc-ietf] Treewalk causing changes

On Wed 01/Mar/2023 02:33:14 +0100 Murray S. Kucherawy wrote: On Tue, Feb 28, 2023 at 5:13 PM Mark Alley wrote: It does vary widely, agreed; I believe knowing how the behavior changes can affect existing implementation and common usage scenarios may be useful for at least consideration of its

Re: [dmarc-ietf] Treewalk causing changes

On Wed 01/Mar/2023 11:12:06 +0100 Laura Atkins wrote: On 1 Mar 2023, at 09:07, Alessandro Vesely wrote: However, in that case both zones are under the same master server: cuny.edu. 2801IN SOA acme.ucc.cuny.edu. hostmaster.acme.ucc.cuny.edu. 2019022032 3600 1800 24

Re: [dmarc-ietf] Treewalk causing changes

> On 1 Mar 2023, at 09:07, Alessandro Vesely wrote: > > Thanks to you and Mark! > > > On Tue 28/Feb/2023 19:00:22 +0100 Laura Atkins wrote: >>> On 28 Feb 2023, at 17:51, Alessandro Vesely wrote: >>> What changes when there is a zone cut (delegation) rather than having >>> sub-subdomains all

Re: [dmarc-ietf] Treewalk causing changes

Thanks to you and Mark! On Tue 28/Feb/2023 19:00:22 +0100 Laura Atkins wrote: On 28 Feb 2023, at 17:51, Alessandro Vesely wrote: What changes when there is a zone cut (delegation) rather than having sub-subdomains all in the same zone?  Controlling inheritance obviously has different taste

Re: [dmarc-ietf] Treewalk causing changes

On Tue, Feb 28, 2023 at 5:13 PM Mark Alley wrote: > It does vary widely, agreed; I believe knowing how the behavior changes > can affect existing implementation and common usage scenarios may be useful > for at least consideration of its effects on domain owners. > What do you propose? It seems

Re: [dmarc-ietf] Treewalk causing changes

It does vary widely, agreed; I believe knowing how the behavior changes can affect existing implementation and common usage scenarios may be useful for at least consideration of its effects on domain owners. On 2/28/2023 6:58 PM, Murray S. Kucherawy wrote: On Tue, Feb 28, 2023 at 9:51 AM Aless

Re: [dmarc-ietf] Treewalk causing changes

On Tue, Feb 28, 2023 at 3:53 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Murray, I think we need to acknowledge that we are already in a long > tail.A small percentage of domain owners publish DMARC policies, a > still smaller percentage publish "reject", and evaluators h

Re: [dmarc-ietf] Treewalk causing changes

On Tue, Feb 28, 2023 at 9:51 AM Alessandro Vesely wrote: > What are subdomains being used for? > > Is that more often done for email reasons (MX) or for something else? > > What changes when there is a zone cut (delegation) rather than having > sub-subdomains all in the same zone? Controlling i

Re: [dmarc-ietf] Treewalk causing changes

In some (if not most) cases involving explicit DMARC policies for subdomains (that aren't part of PSDs), it's for subdomains that send mail for an organization either as a whole, or as a subset of said organization. I'll give a live example or two I've experienced. In my time with TJX, during

Re: [dmarc-ietf] Treewalk causing changes

> On 28 Feb 2023, at 17:51, Alessandro Vesely wrote: > > > What are subdomains being used for? If it’s DMARC policy, then it’s email. > Is that more often done for email reasons (MX) or for something else? DMARC is an email authentication protocol so everything about DMARC is for email re

Re: [dmarc-ietf] Treewalk causing changes

What are subdomains being used for? Is that more often done for email reasons (MX) or for something else? What changes when there is a zone cut (delegation) rather than having sub-subdomains all in the same zone? Controlling inheritance obviously has different tastes depending on the case.

Re: [dmarc-ietf] Treewalk causing changes

I agree with Laura's stance. Many organizations (that are not PSDs, and not on a PSL) will publish explicit subdomain-specific DMARC policies to prevent inheritance from a higher level, or the organizational domain (which may not be ready for a stricter policy), during implementation. This is a

Re: [dmarc-ietf] Treewalk causing changes

As someone who has worked with companies, educational institutions, and governments to set DMARC policy it makes no sense to me that we’d argue the top-most-non-PSD policy is the one that should apply. Given how DNS works technically and how policies are set in practice, I support stopping at th

Re: [dmarc-ietf] Treewalk causing changes

Murray, I think we need to acknowledge that we are already in a long tail. A small percentage of domain owners publish DMARC policies, a still smaller percentage publish "reject", and evaluators have a hard time deciding whether to use DMARC because the results are unreliable. The PSD discussion

Re: [dmarc-ietf] Treewalk causing changes

The current algorithm effectively says that you can have subdomain policies, or you can have relaxed alignment, but you cannot have both. This does not meet my definition of upward-compatible. However, if we are willing to deprecate major functionality in the pursuit of freedom from the PSL, then

Re: [dmarc-ietf] Treewalk causing changes

It appears that Murray S. Kucherawy said: >3) Since the goal is to wind down dependence on the PSL, I suggest that an >implementation might choose to make the algorithm selectable, but I don't >think the specification should. If for some inexplicable reason you really want to keep using the PSL

Re: [dmarc-ietf] Treewalk causing changes

I can not agree more than 100 percent on this. The PSL has issues. We need to stop depending on it. If anything, the PSD work has shown the W3C folks that there is a path forward for folks who need to do PSL-like things without boiling the ocean. tim (who has spent a bit too much time recently a

Re: [dmarc-ietf] Treewalk causing changes

On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" wrote: >On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> The current text has an incentive problem. For an evaluator, the PSL >> works fine. Unless an evaluator is Google-class, rece

Re: [dmarc-ietf] Treewalk causing changes

On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The current text has an incentive problem. For an evaluator, the PSL > works fine. Unless an evaluator is Google-class, receiving mail from > everywhere in the world, most of the PSL entries will nev

Re: [dmarc-ietf] Treewalk causing changes

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

Re: [dmarc-ietf] Treewalk causing changes

On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba wrote: > 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 th

Re: [dmarc-ietf] Treewalk causing changes

defense.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

Re: [dmarc-ietf] Treewalk causing changes

ought, 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 Alessandr

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

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_...@emaildefens

Re: [dmarc-ietf] Treewalk causing changes

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.

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

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

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

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.

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_..

Re: [dmarc-ietf] Treewalk causing changes

On February 25, 2023 5:57:54 AM UTC, John Levine wrote: >It appears that Seth Blank said: >>-=-=-=-=-=- >> >>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 fi

Re: [dmarc-ietf] Treewalk causing changes

It appears that Seth Blank said: >-=-=-=-=-=- > >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. It also adds all the problems you get with CNAMEs, like long

Re: [dmarc-ietf] Treewalk causing changes

t'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 > > Sub

Re: [dmarc-ietf] Treewalk causing changes

able. > > -- > 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:

Re: [dmarc-ietf] Treewalk causing changes

cy 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 &

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

Re: [dmarc-ietf] Treewalk causing changes

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 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, ra

Re: [dmarc-ietf] Treewalk causing changes

It appears that Douglas Foster said: >-=-=-=-=-=- > >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. The current design has been in the draft since October, and we discussed it on this list at great length. R's, John

Re: [dmarc-ietf] Treewalk causing changes

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 th

Re: [dmarc-ietf] Treewalk causing changes

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 ow

Re: [dmarc-ietf] Treewalk causing changes

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.300INTXT"v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.c

Re: [dmarc-ietf] Treewalk causing changes

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 identi

Re: [dmarc-ietf] Treewalk causing changes

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, b

Re: [dmarc-ietf] Treewalk causing changes

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

[dmarc-ietf] Treewalk causing changes

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.300INTXT"v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; r