Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

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 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?
>
> Yes, that's a feature. If you want your subdomains to send reports to
> some particular place, tell them to do that. If you don't, that's OK
> too.
>
> Any domain can put a "rua" tag into its DMARC record so this isn't
> really anything new.
>
> R's,
> John
>
> >On 2/23/2023 6:13 PM, John R. Levine 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.300INTXT"v=DMARC1; p=quarantine;
> >>> fo=1;
> >>> rua=mailto:dmarc_...@emaildefense.proofpoint.com;
> >>> ruf=mailto:dmarc_...@emaildefense.proofpoint.com;
> >>>
> >>> _dmarc.cuny.edu.3325INTXT"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"
> >>
> >> Good catch, although in this case I think the most likely result is
> >> that the people at bmcc.cuny.edu will say "who set up
> >> Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use
> >> Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to
> >> O365.  There's some other strangeness; www.cuny.edu is a CNAME for
> >> web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A
> >> records pointing to machines running sendmail.
> >>
> >> It might be interesting to set up a web page where you can put in a
> >> mail domain and it'll tell you whether its treatment will change with
> >> the tree walk.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[John Levine]

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 subdomain's would stop getting 
>the sub's DMARC reports?

Yes, that's a feature. If you want your subdomains to send reports to
some particular place, tell them to do that. If you don't, that's OK
too.

Any domain can put a "rua" tag into its DMARC record so this isn't
really anything new.

R's,
John

>On 2/23/2023 6:13 PM, John R. Levine 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.300INTXT"v=DMARC1; p=quarantine; 
>>> fo=1;
>>> rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
>>> ruf=mailto:dmarc_...@emaildefense.proofpoint.com;
>>>
>>> _dmarc.cuny.edu.3325INTXT"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"
>>
>> Good catch, although in this case I think the most likely result is 
>> that the people at bmcc.cuny.edu will say "who set up 
>> Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use 
>> Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to 
>> O365.  There's some other strangeness; www.cuny.edu is a CNAME for 
>> web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A 
>> records pointing to machines running sendmail.
>>
>> It might be interesting to set up a web page where you can put in a 
>> mail domain and it'll tell you whether its treatment will change with 
>> the tree walk.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

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?


- Mark Alley

On 2/23/2023 6:13 PM, John R. Levine 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.300INTXT"v=DMARC1; p=quarantine; 
fo=1;
rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
ruf=mailto:dmarc_...@emaildefense.proofpoint.com;


_dmarc.cuny.edu.3325INTXT"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"


Good catch, although in this case I think the most likely result is 
that the people at bmcc.cuny.edu will say "who set up 
Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use 
Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to 
O365.  There's some other strangeness; www.cuny.edu is a CNAME for 
web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A 
records pointing to machines running sendmail.


It might be interesting to set up a web page where you can put in a 
mail domain and it'll tell you whether its treatment will change with 
the tree walk.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
Dummies",

Please consider the environment before reading this e-mail. https://jl.ly

___
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

[Douglas Foster]

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 organizations want.   Therefore, for purposes of DMARCbis, the
policy domain will be the organizational domain, and the alignment scope
will be the subtree below the policy domain.   When the policy domain is "
dmas.virginia.gov", this means that "virginia.gov" can no longer sign to
authenticate the message.

This could be symmetric or asymmetric.   The one-sided tree walk would only
look at the "From" domain.   If the From domain is "virginia.gov" or a
descendant of it that does not have a DMARC policy, the "virginia.gov" is
the organizational domain.If we don't do a tree walk on "
dmas.virginia.gov", then we conclude that it is in the same organization,
so "dmas.virginia.gov" can sign for both "virgina.gov" and "scc.virginia.gov"
 The two-sided tree walk looks at both domains, sees that "dmas.virginia.gov"
is in its own organization, and is therefore unable to sign for either "
virginia.gov" or siblings like "scc.virginia.gov".

The two-sided tree walk is the most logically consistent, but requires more
effort at evaluation time.   Either choice may break some existing usage.
Both are still guessing strategies, so I still prefer some policy options
to allow domain owners fine-grained control over the process.

Doug Foster

On Wed, Mar 1, 2023 at 10:08 AM 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" both have
> DMARC policies with relaxed alignment.   Should "dmas.virginia.gov" be
> prohibited from authenticating "virginia.gov"?
> My gut says yes, but it adds some overhead to enforce that rule.
>
> My gut says that might break ESPs who are using subdomains for SPF relaxed
> alignment. Unless you are saying that it's safe for treewalk changes to
> break MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then
> maybe there is some data to suggest that it is rare.
>
> Dare I suggest that virginia.gov be able to define the subdomains to
> which SPF relaxed alignment should apply? As a domain owner, I might be
> inclined to reserve something like bounces.virginia.gov for all MAIL FROM
> sub-sub-domains that are used for delegating ESP traffic and manage it
> similar to DKIM selectors. aspf=s for any subdomains that aren't otherwise
> defined.
>
> In my experience talking to state governments (as well as reflecting back
> on my own time in state government), domain owners are seeing a lot of ESP
> usage sprawl among their sub-domains/agencies/departments and they are
> frustrated that they can't manage or govern it effectively. In this late
> stage of the game, they won't be able to publish aspf=s to keep agencies
> from delegating ESP usage of virginia.gov when the domain owner would
> otherwise not want them to.
>
> Jesse
> ___
> 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

[Alessandro Vesely]

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 " and "dmas.virginia.gov " 
both have DMARC policies with relaxed alignment.   Should "dmas.virginia.gov " be prohibited from 
authenticating "virginia.gov "?
My gut says yes, but it adds some overhead to enforce that rule.


My gut says that might break ESPs who are using subdomains for SPF relaxed 
alignment. Unless you are saying that it's safe for treewalk changes to break 
MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
is some data to suggest that it is rare.



That's a curious example, as both virginia.gov and dmas.virginia.gov have DMARC 
records defined without the _dmarc prefix.


I'd have exemplified a service which provides signing to the whole 
organization.  Their own department can be ready for strict policies, so they 
may want to publish p=reject, while the whole organization sticks to a more 
conservative policy.  Adding rua= addresses is another reason to publish a 
separate record.




If an org domain doesn't want to have subdomain used then they need to use 
strict alignment.  There's no need to turn relaxed alignment into some sort of 
almost strict, but more complicated.  We've gotten this far without redesigning 
alignment, let's not start now.  As far as I remember, it's still the same as 
RFC 7489 and that's a good thing.



Somewhat similar to defining strict alignment, the org domain can avail of the 
new possibility to define psd=y.  Even if hey are not open to public 
registrations, they may want to enforce a clear-cut subdivision.



Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Scott Kitterman]

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 " both have DMARC policies with 
>> relaxed alignment.   Should "dmas.virginia.gov " 
>> be prohibited from authenticating "virginia.gov "?
>> My gut says yes, but it adds some overhead to enforce that rule.
>
>My gut says that might break ESPs who are using subdomains for SPF relaxed 
>alignment. Unless you are saying that it's safe for treewalk changes to break 
>MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
>is some data to suggest that it is rare.
>
>Dare I suggest that virginia.gov be able to define the subdomains to which SPF 
>relaxed alignment should apply? As a domain owner, I might be inclined to 
>reserve something like bounces.virginia.gov for all MAIL FROM sub-sub-domains 
>that are used for delegating ESP traffic and manage it similar to DKIM 
>selectors. aspf=s for any subdomains that aren't otherwise defined.
>
>In my experience talking to state governments (as well as reflecting back on 
>my own time in state government), domain owners are seeing a lot of ESP usage 
>sprawl among their sub-domains/agencies/departments and they are frustrated 
>that they can't manage or govern it effectively. In this late stage of the 
>game, they won't be able to publish aspf=s to keep agencies from delegating 
>ESP usage of virginia.gov when the domain owner would otherwise not want them 
>to.
>

If an org domain doesn't want to have subdomain used then they need to use 
strict alignment.  There's no need to turn relaxed alignment into some sort of 
almost strict, but more complicated.  We've gotten this far without redesigning 
alignment, let's not start now.  As far as I remember, it's still the same as 
RFC 7489 and that's a good thing.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Jesse Thompson]

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.   Should "dmas.virginia.gov " be 
> prohibited from authenticating "virginia.gov "?
> My gut says yes, but it adds some overhead to enforce that rule.

My gut says that might break ESPs who are using subdomains for SPF relaxed 
alignment. Unless you are saying that it's safe for treewalk changes to break 
MAILFROM=bounces.dmas.virginia.gov rfc5322.From=virginia.gov, then maybe there 
is some data to suggest that it is rare.

Dare I suggest that virginia.gov be able to define the subdomains to which SPF 
relaxed alignment should apply? As a domain owner, I might be inclined to 
reserve something like bounces.virginia.gov for all MAIL FROM sub-sub-domains 
that are used for delegating ESP traffic and manage it similar to DKIM 
selectors. aspf=s for any subdomains that aren't otherwise defined.

In my experience talking to state governments (as well as reflecting back on my 
own time in state government), domain owners are seeing a lot of ESP usage 
sprawl among their sub-domains/agencies/departments and they are frustrated 
that they can't manage or govern it effectively. In this late stage of the 
game, they won't be able to publish aspf=s to keep agencies from delegating ESP 
usage of virginia.gov when the domain owner would otherwise not want them to.

Jesse
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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 NO
POLICY or false PASS that can occur when the PSL (or any other jumping
algorithm) jumps to the wrong organizational domain.

We can partially test for negative impacts of this change by looking for
messages where:
- The organizational domain is different from the policy domain, and
- Alignment is only possible using a parent of the policy domain.
Do you think we can get that assessment from one of the big players?

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.   Should "dmas.virginia.gov" be
prohibited from authenticating "virginia.gov"?
My gut says yes, but it adds some overhead to enforce that rule.

Doug


On Tue, Feb 28, 2023 at 8:47 AM Mark Alley  wrote:

> 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 very common configuration.
> On 2/28/2023 6:07 AM, Laura Atkins wrote:
>
> 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 the
> bottom-most policy.
>
> laura
>
>
> On 28 Feb 2023, at 11:52, Douglas Foster
> 
>  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 have a hard time
> deciding whether to use DMARC because the results are unreliable.  The PSD
> discussion merely highlights the fact that DMARC results can be unreliable
> in both directions - PASS and FAIL.
>
> We were much closer to a plausible algorithm when the Tree Walk stopped at
> the top-most non-PSD policy.   We know that most PSOs and private
> registries do not publish DMARC policies, and we hope that those who do
> will add the PSD=Y flag.   Given both of these conditions, if a DNS path
> contains multiple DMARC policies, the top-most policy will be the
> organizational policy because we don't expect any non-PSD policies above
> the organizational domain.
>
> To get a Tree Walk algorithm that stops at the bottom-most policy, John
> added the assumption that domains will never publish sub-domain policies,
> so that a higher-level policy will either not exist at all, or will only
> exist as a registry policy, either of which can be ignored.This
> assumption was made without data and is simply implausible.
>
> If have trouble assuming that registries, especially private registries,
> will only publish PSD=Y policies, now and forever.   My goal in replacing
> the PSL is to give domain owners the responsibility and the control to
> define their own organizational domain boundary.  The current Tree Walk
> does not do that, so it cannot succeed.  The org=-n term places
> responsibility where it belongs.
>
> Doug Foster
>
>
>
> On Mon, Feb 27, 2023 at 10:04 AM 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, receiving mail from
>>> everywhere in the world, most of the PSL entries will never be examined and
>>> most of the PSL errors will never be exposed.   When an error is detected
>>> by an evaluator, it is a trivial effort to add or remove a record from the
>>> local copy of PSL.  For evaluators, the PSL works fine.
>>>
>>
>> The notion that different operators are using slightly different versions
>> of the PSL is one of the reasons we want to stop depending on the PSL.  I
>> don't think we should offer this as an option.
>>
>>
>>> Domain owners / message senders are the ones who should be powerfully
>>> motivated to replace the PSL.   If so, they should be willing to add a tag
>>> that invokes MUST USE TREE WALK because it eliminates ambiguity and
>>> protects them from the PSL.   With that elimination of ambiguity
>>> and corresponding MUSRT, evaluators have a reason to change.   Without
>>> that, evaluators have every reason to ignore this new, unproven, and
>>> imperfect algorithm;
>>>
>>
>> I'm worried about leaving operators with a choice here, for a number of
>> reasons:
>>
>> 1) "pct" also presented a choice, 

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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 effects on domain owners.


What do you propose?  It seems to me that such a study, to be useful, would 
either need a great deal of inference, or a great deal of time and effort. 
Or both.



Just mumbling...  We introduce to breaking factors, pct= to t= and inheritance 
rule change.  The former is a no-brainer to implementer; it's straightforward 
to support both, since the intention of the publisher is clear.  The latter 
seems to be hardly tractable in a case-by-case fashion, as domain owner's 
expectations are going to adapt as the new spec spreads.  It is important to 
get it right, also in view of future extensions.



Best
Ale
--









___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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 2419200 3600
bmcc.cuny.edu.  300 IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
ret.bmcc.cuny.edu. (no SOA)

(Those funny serials cannot begin with the year.  We had no DMARC in 2008.)


I don’t see how that changes anything. You walk up the DNS hierarchy and stop 
when you find a DMARC policy statement. You don’t bypass that statement and 
keep walking, IMO.



You may want to keep walking if you need to establish which is the org domain, 
for alignment purposes.  Part of the walk can be optimized out when (one of) 
the verified identifiers lies within the subtree explored thus far. I'm not 
sure how I'm going to implement that.



Best
Ale
--





___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Laura Atkins]

> 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 in the same zone?  Controlling inheritance obviously has 
>>> different tastes depending on the case.  Which case is more common?
>> 
>> If it’s a zone cut, then that supports the “bottom-most” policy even more 
>> than  if it’s in the same zone, IMO.
> 
> 
> For clarity, let me point out that bottom-most refers to the convention that 
> abstract trees have their roots at the top.  IOW, since ret.bmcc is in the 
> same zone as bmcc it seems better for the former to inherit from the latter 
> than from its org domain.

Thank you for the clarification. I was adopting the terminology from the post I 
was responding to rather than confusing the conversation by changing it. 

> 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 2419200 3600
> bmcc.cuny.edu.300 IN  SOA acme.ucc.cuny.edu. 
> hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
> ret.bmcc.cuny.edu. (no SOA)
> 
> (Those funny serials cannot begin with the year.  We had no DMARC in 2008.)

I don’t see how that changes anything. You walk up the DNS hierarchy and stop 
when you find a DMARC policy statement. You don’t bypass that statement and 
keep walking, IMO.

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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 tastes depending on the case.  Which case is more common?


If it’s a zone cut, then that supports the “bottom-most” policy even more than  
if it’s in the same zone, IMO.



For clarity, let me point out that bottom-most refers to the convention that 
abstract trees have their roots at the top.  IOW, since ret.bmcc is in the same 
zone as bmcc it seems better for the former to inherit from the latter than 
from its org domain.

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 2419200 3600
bmcc.cuny.edu.  300 IN  SOA acme.ucc.cuny.edu. 
hostmaster.acme.ucc.cuny.edu. 200804826 300 3600 2419200 3600
ret.bmcc.cuny.edu. (no SOA)

(Those funny serials cannot begin with the year.  We had no DMARC in 2008.)


Best
Ale
--










___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Murray S. Kucherawy]

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 to me that such a study, to be useful, would
either need a great deal of inference, or a great deal of time and effort.
Or both.

-MSK, still no hat
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

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 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 inheritance
obviously has
different tastes depending on the case.  Which case is more common?


Even if we know the answer to this question today, it could change 
tomorrow.  It probably changes from one domain to the next already.


Do we really want to base protocol decisions on this?

-MSK, participating

___
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

[Murray S. Kucherawy]

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 have a hard time
> deciding whether to use DMARC because the results are unreliable.  The PSD
> discussion merely highlights the fact that DMARC results can be unreliable
> in both directions - PASS and FAIL.
>

I'm pretty confused now.

A false DMARC "pass" means some combination of a false positive from DKIM,
a false positive from SPF, and false alignment, somehow resulting in a
"pass" when some other result was expected.  That strikes me as
extraordinarily unlikely.  Are we saying such a threat exists, and the
proposed tree walk exacerbates this to the point where it's a concern?

A false DMARC "fail" can be caused by any of the three of those severally.
This strikes me as more likely, but that's a known problem with DMARC and
is a large part of the solution space this WG is exploring even if we leave
the PSL in place.  Are we saying that the tree walk makes solving this even
harder?

In either case, I'd love to see an example, even a contrived one, showing
the potential impact you're describing.  The discussion is a little too
abstract for me to be able to picture.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Murray S. Kucherawy]

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 inheritance obviously
> has
> different tastes depending on the case.  Which case is more common?
>

Even if we know the answer to this question today, it could change
tomorrow.  It probably changes from one domain to the next already.

Do we really want to base protocol decisions on this?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

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 our implementation process of DMARC, we 
explicitly published (and still have) several explicit DMARC policies 
for our e-commerce and other sending subdomain DMARC policies (ex. 
em.tjmaxx.tjx.com) to prevent them from inheriting the organizational 
domain's policy (tjx.com) to allow us to publish stricter policy for the 
org domain and subdomains that were ready for a stricter policy, leaving 
only the explicitly published policies of subdomains used for 
e-commerce/comms/logistics, etc traffic to tend to for a policy of 
"p=none" until they too, were ready.


Or vice versa, some of the subdomains we published stricter policies for 
(similar to Elizabeth's original example) converse to the organizational 
domain's policy.


Not all delegations are necessarily done because a separate organization 
"owns" the subdomain; in these cases, some of these have NS records 
pointing outside of an org's normal nameservers, but are still 
controlled/managed as such by the org itself, or on behalf of the org. 
Our E-commerce group (and therefore TJX) still owns these subdomains, 
but the ESP controls the DNS with governance/requests still allowed.


Similar and in someways slightly different from the former example, 
another might be alabama.gov (and subdomains) of which their structure 
follows a PSD-style usage of DMARC. (Except without psd=y currently)


Alabama.gov is the organizational domain, but each agency (i.e. 
oit.alabama.gov, dhr.alabama.gov, medicaid.alabama.gov, etc.) are 
functionally separate orgs within the state government, but IT policies 
and DNS are governed and owned/operated by OIT (with a few exceptions). 
Each agency's subdomain has its own explicit DMARC record, published for 
the same reasons as the previous example. The few outliers are also 
following the same structure, the subdomain zones for an agency not 
under jurisdiction of OIT are delegated to their respective agency, of 
which has a separate DMARC record and policy that were created during 
implementation.


- Mark Alley


On 2/28/2023 11: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 inheritance 
obviously has different tastes depending on the case. Which case is 
more common?



Best
Ale

On Tue 28/Feb/2023 14:46:54 +0100 Mark Alley wrote:
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 very common configuration.


On 2/28/2023 6:07 AM, Laura Atkins wrote:
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 the bottom-most policy.


laura


On 28 Feb 2023, at 11:52, Douglas Foster 
 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 have a hard time deciding whether to use DMARC because 
the results are unreliable.  The PSD discussion merely highlights 
the fact that DMARC results can be unreliable in both directions - 
PASS and FAIL.


We were much closer to a plausible algorithm when the Tree Walk 
stopped at the top-most non-PSD policy.   We know that most PSOs 
and private registries do not publish DMARC policies, and we hope 
that those who do will add the PSD=Y flag.   Given both of these 
conditions, if a DNS path contains multiple DMARC policies, the 
top-most policy will be the organizational policy because we don't 
expect any non-PSD policies above the organizational domain.


To get a Tree Walk algorithm that stops at the bottom-most policy, 
John added the assumption that domains will never publish 
sub-domain policies, so that a higher-level policy will either not 
exist at all, or will only exist as a registry policy, either of 
which can be ignored.    This assumption was made without data and 
is simply implausible.


If have trouble assuming that registries, especially private 
registries, will only publish PSD=Y policies, now and forever.   My 
goal in replacing the PSL is to give domain owners the 
responsibility and the control to define their own 

Re: [dmarc-ietf] Treewalk causing changes

[Laura Atkins]

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

> 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.  Which case is more common?

If it’s a zone cut, then that supports the “bottom-most” policy even more than 
if it’s in the same zone, IMO. 

laura 

> 
> 
> Best
> Ale
> 
> On Tue 28/Feb/2023 14:46:54 +0100 Mark Alley wrote:
>> 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 very 
>> common configuration.
>> On 2/28/2023 6:07 AM, Laura Atkins wrote:
>>> 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 the 
>>> bottom-most policy.
>>> 
>>> laura
>>> 
>>> 
 On 28 Feb 2023, at 11:52, Douglas Foster 
  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 have a hard time 
 deciding whether to use DMARC because the results are unreliable.  The PSD 
 discussion merely highlights the fact that DMARC results can be unreliable 
 in both directions - PASS and FAIL.
 
 We were much closer to a plausible algorithm when the Tree Walk stopped at 
 the top-most non-PSD policy.   We know that most PSOs and private 
 registries do not publish DMARC policies, and we hope that those who do 
 will add the PSD=Y flag.   Given both of these conditions, if a DNS path 
 contains multiple DMARC policies, the top-most policy will be the 
 organizational policy because we don't expect any non-PSD policies above 
 the organizational domain.
 
 To get a Tree Walk algorithm that stops at the bottom-most policy, John 
 added the assumption that domains will never publish sub-domain policies, 
 so that a higher-level policy will either not exist at all, or will only 
 exist as a registry policy, either of which can be ignored.This 
 assumption was made without data and is simply implausible.
 
 If have trouble assuming that registries, especially private registries, 
 will only publish PSD=Y policies, now and forever.   My goal in replacing 
 the PSL is to give domain owners the responsibility and the control to 
 define their own organizational domain boundary. The current Tree Walk 
 does not do that, so it cannot succeed.  The org=-n term places 
 responsibility where it belongs.
 
 Doug Foster
 
 
 
 On Mon, Feb 27, 2023 at 10:04 AM Murray S. Kucherawy  
 wrote:
 
 On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster
  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 never be examined and most of
 the PSL errors will never be exposed.   When an error is
 detected by an evaluator, it is a trivial effort to add or
 remove a record from the local copy of PSL.  For evaluators,
 the PSL works fine.
 
 
 The notion that different operators are using slightly different
 versions of the PSL is one of the reasons we want to stop
 depending on the PSL. I don't think we should offer this as an
 option.
 
 Domain owners / message senders are the ones who should be
 powerfully motivated to replace the PSL.   If so, they should
 be willing to add a tag that invokes MUST USE TREE WALK
 because it eliminates ambiguity and protects them from the
 PSL.   With that elimination of ambiguity and corresponding
 MUSRT, evaluators have a reason to change.  Without that,
 evaluators have every reason to ignore this new, unproven,
 and imperfect algorithm;
 
 
 I'm worried about leaving operators with a choice here, for a
 number of reasons:
 
 1) "pct" also presented a choice, and the consensus appears to be

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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.  Which case is more common?



Best
Ale

On Tue 28/Feb/2023 14:46:54 +0100 Mark Alley wrote:
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 very common 
configuration.


On 2/28/2023 6:07 AM, Laura Atkins wrote:
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 the 
bottom-most policy.


laura


On 28 Feb 2023, at 11:52, Douglas Foster 
 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 have a hard time 
deciding whether to use DMARC because the results are unreliable.  The PSD 
discussion merely highlights the fact that DMARC results can be unreliable 
in both directions - PASS and FAIL.


We were much closer to a plausible algorithm when the Tree Walk stopped at 
the top-most non-PSD policy.   We know that most PSOs and private registries 
do not publish DMARC policies, and we hope that those who do will add the 
PSD=Y flag.   Given both of these conditions, if a DNS path contains 
multiple DMARC policies, the top-most policy will be the organizational 
policy because we don't expect any non-PSD policies above the organizational 
domain.


To get a Tree Walk algorithm that stops at the bottom-most policy, John 
added the assumption that domains will never publish sub-domain policies, so 
that a higher-level policy will either not exist at all, or will only exist 
as a registry policy, either of which can be ignored.    This assumption was 
made without data and is simply implausible.


If have trouble assuming that registries, especially private registries, 
will only publish PSD=Y policies, now and forever.   My goal in replacing 
the PSL is to give domain owners the responsibility and the control to 
define their own organizational domain boundary. The current Tree Walk does 
not do that, so it cannot succeed.  The org=-n term places responsibility 
where it belongs.


Doug Foster



On Mon, Feb 27, 2023 at 10:04 AM Murray S. Kucherawy  
wrote:


    On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster
     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 never be examined and most of
    the PSL errors will never be exposed.   When an error is
    detected by an evaluator, it is a trivial effort to add or
    remove a record from the local copy of PSL.  For evaluators,
    the PSL works fine.


    The notion that different operators are using slightly different
    versions of the PSL is one of the reasons we want to stop
    depending on the PSL. I don't think we should offer this as an
    option.

    Domain owners / message senders are the ones who should be
    powerfully motivated to replace the PSL.   If so, they should
    be willing to add a tag that invokes MUST USE TREE WALK
    because it eliminates ambiguity and protects them from the
    PSL.   With that elimination of ambiguity and corresponding
    MUSRT, evaluators have a reason to change.  Without that,
    evaluators have every reason to ignore this new, unproven,
    and imperfect algorithm;


    I'm worried about leaving operators with a choice here, for a
    number of reasons:

    1) "pct" also presented a choice, and the consensus appears to be
    that this didn't work out at all, for the reasons previously
    given (mostly related to variance in implementations).

    2) "Stop using the PSL" as a goal is delayed or even thwarted if
    we add such a tag.  It creates an undefined, possibly infinite,
    period of migration during which operators can opt out.  If we're
    going to do this, we should discuss including some kind of firm
    sunset period for the PSL.  But now we're walking in the
    direction of having a flag day, and everybody hates those.

    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.

    -MSK

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

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 very common configuration.


On 2/28/2023 6:07 AM, Laura Atkins wrote:
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 the bottom-most policy.


laura


On 28 Feb 2023, at 11:52, Douglas Foster 
 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 have a 
hard time deciding whether to use DMARC because the results are 
unreliable.  The PSD discussion merely highlights the fact that DMARC 
results can be unreliable in both directions - PASS and FAIL.


We were much closer to a plausible algorithm when the Tree Walk 
stopped at the top-most non-PSD policy.   We know that most PSOs and 
private registries do not publish DMARC policies, and we hope that 
those who do will add the PSD=Y flag.   Given both of these 
conditions, if a DNS path contains multiple DMARC policies, the 
top-most policy will be the organizational policy because we don't 
expect any non-PSD policies above the organizational domain.


To get a Tree Walk algorithm that stops at the bottom-most policy, 
John added the assumption that domains will never publish sub-domain 
policies, so that a higher-level policy will either not exist at all, 
or will only exist as a registry policy, either of which can be 
ignored.    This assumption was made without data and is simply 
implausible.


If have trouble assuming that registries, especially private 
registries, will only publish PSD=Y policies, now and forever.   My 
goal in replacing the PSL is to give domain owners the responsibility 
and the control to define their own organizational domain boundary.  
The current Tree Walk does not do that, so it cannot succeed.  The 
org=-n term places responsibility where it belongs.


Doug Foster



On Mon, Feb 27, 2023 at 10:04 AM Murray S. Kucherawy 
 wrote:


On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster
 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 never be examined and most of
the PSL errors will never be exposed.   When an error is
detected by an evaluator, it is a trivial effort to add or
remove a record from the local copy of PSL.  For evaluators,
the PSL works fine.


The notion that different operators are using slightly different
versions of the PSL is one of the reasons we want to stop
depending on the PSL. I don't think we should offer this as an
option.

Domain owners / message senders are the ones who should be
powerfully motivated to replace the PSL.   If so, they should
be willing to add a tag that invokes MUST USE TREE WALK
because it eliminates ambiguity and protects them from the
PSL.   With that elimination of ambiguity and corresponding
MUSRT, evaluators have a reason to change.  Without that,
evaluators have every reason to ignore this new, unproven,
and imperfect algorithm;


I'm worried about leaving operators with a choice here, for a
number of reasons:

1) "pct" also presented a choice, and the consensus appears to be
that this didn't work out at all, for the reasons previously
given (mostly related to variance in implementations).

2) "Stop using the PSL" as a goal is delayed or even thwarted if
we add such a tag.  It creates an undefined, possibly infinite,
period of migration during which operators can opt out.  If we're
going to do this, we should discuss including some kind of firm
sunset period for the PSL.  But now we're walking in the
direction of having a flag day, and everybody hates those.

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.

-MSK

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


--
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Email Delivery Blog: http://wordtothewise.com/blog







___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Treewalk causing changes

[Laura Atkins]

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 the 
bottom-most policy. 

laura 


> On 28 Feb 2023, at 11:52, Douglas Foster 
>  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 have a hard time deciding whether 
> to use DMARC because the results are unreliable.  The PSD discussion merely 
> highlights the fact that DMARC results can be unreliable in both directions - 
> PASS and FAIL.
> 
> We were much closer to a plausible algorithm when the Tree Walk stopped at 
> the top-most non-PSD policy.   We know that most PSOs and private registries 
> do not publish DMARC policies, and we hope that those who do will add the 
> PSD=Y flag.   Given both of these conditions, if a DNS path contains multiple 
> DMARC policies, the top-most policy will be the organizational policy because 
> we don't expect any non-PSD policies above the organizational domain.
> 
> To get a Tree Walk algorithm that stops at the bottom-most policy, John added 
> the assumption that domains will never publish sub-domain policies, so that a 
> higher-level policy will either not exist at all, or will only exist as a 
> registry policy, either of which can be ignored.This assumption was made 
> without data and is simply implausible.
> 
> If have trouble assuming that registries, especially private registries, will 
> only publish PSD=Y policies, now and forever.   My goal in replacing the PSL 
> is to give domain owners the responsibility and the control to define their 
> own organizational domain boundary.  The current Tree Walk does not do that, 
> so it cannot succeed.  The org=-n term places responsibility where it belongs.
> 
> Doug Foster
> 
> 
> 
> On Mon, Feb 27, 2023 at 10:04 AM Murray S. Kucherawy  > wrote:
>> On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster 
>> > > 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 never be examined and 
>>> most of the PSL errors will never be exposed.   When an error is detected 
>>> by an evaluator, it is a trivial effort to add or remove a record from the 
>>> local copy of PSL.  For evaluators, the PSL works fine.
>> 
>> The notion that different operators are using slightly different versions of 
>> the PSL is one of the reasons we want to stop depending on the PSL.  I don't 
>> think we should offer this as an option.
>>  
>>> Domain owners / message senders are the ones who should be powerfully 
>>> motivated to replace the PSL.   If so, they should be willing to add a tag 
>>> that invokes MUST USE TREE WALK because it eliminates ambiguity and 
>>> protects them from the PSL.   With that elimination of ambiguity and 
>>> corresponding MUSRT, evaluators have a reason to change.   Without that, 
>>> evaluators have every reason to ignore this new, unproven, and imperfect 
>>> algorithm;
>> 
>> I'm worried about leaving operators with a choice here, for a number of 
>> reasons:
>> 
>> 1) "pct" also presented a choice, and the consensus appears to be that this 
>> didn't work out at all, for the reasons previously given (mostly related to 
>> variance in implementations).
>> 
>> 2) "Stop using the PSL" as a goal is delayed or even thwarted if we add such 
>> a tag.  It creates an undefined, possibly infinite, period of migration 
>> during which operators can opt out.  If we're going to do this, we should 
>> discuss including some kind of firm sunset period for the PSL.  But now 
>> we're walking in the direction of having a flag day, and everybody hates 
>> those.
>> 
>> 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.
>> 
>> -MSK
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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 merely highlights the fact that DMARC results can be unreliable
in both directions - PASS and FAIL.

We were much closer to a plausible algorithm when the Tree Walk stopped at
the top-most non-PSD policy.   We know that most PSOs and private
registries do not publish DMARC policies, and we hope that those who do
will add the PSD=Y flag.   Given both of these conditions, if a DNS path
contains multiple DMARC policies, the top-most policy will be the
organizational policy because we don't expect any non-PSD policies above
the organizational domain.

To get a Tree Walk algorithm that stops at the bottom-most policy, John
added the assumption that domains will never publish sub-domain policies,
so that a higher-level policy will either not exist at all, or will only
exist as a registry policy, either of which can be ignored.This
assumption was made without data and is simply implausible.

If have trouble assuming that registries, especially private registries,
will only publish PSD=Y policies, now and forever.   My goal in replacing
the PSL is to give domain owners the responsibility and the control to
define their own organizational domain boundary.  The current Tree Walk
does not do that, so it cannot succeed.  The org=-n term places
responsibility where it belongs.

Doug Foster



On Mon, Feb 27, 2023 at 10:04 AM 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, receiving mail from
>> everywhere in the world, most of the PSL entries will never be examined and
>> most of the PSL errors will never be exposed.   When an error is detected
>> by an evaluator, it is a trivial effort to add or remove a record from the
>> local copy of PSL.  For evaluators, the PSL works fine.
>>
>
> The notion that different operators are using slightly different versions
> of the PSL is one of the reasons we want to stop depending on the PSL.  I
> don't think we should offer this as an option.
>
>
>> Domain owners / message senders are the ones who should be powerfully
>> motivated to replace the PSL.   If so, they should be willing to add a tag
>> that invokes MUST USE TREE WALK because it eliminates ambiguity and
>> protects them from the PSL.   With that elimination of ambiguity
>> and corresponding MUSRT, evaluators have a reason to change.   Without
>> that, evaluators have every reason to ignore this new, unproven, and
>> imperfect algorithm;
>>
>
> I'm worried about leaving operators with a choice here, for a number of
> reasons:
>
> 1) "pct" also presented a choice, and the consensus appears to be that
> this didn't work out at all, for the reasons previously given (mostly
> related to variance in implementations).
>
> 2) "Stop using the PSL" as a goal is delayed or even thwarted if we add
> such a tag.  It creates an undefined, possibly infinite, period of
> migration during which operators can opt out.  If we're going to do this,
> we should discuss including some kind of firm sunset period for the PSL.
> But now we're walking in the direction of having a flag day, and everybody
> hates those.
>
> 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.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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 lets deprecate relaxed alignment.   Domain
owners who are serious about DMARC will sign every message.  When signing a
message, it is no great inconvenience to sign it using the exact match
domain.   Relaxed alignment is not necessary.   With this change, the tree
walk is used to determine whether a higher-level policy exists or not.  If
none exists on the From domain, but one does exist above, then the result
is FAIL.

- - - -

On my earlier proposal, I am surprised that you are willing to assume that
everyone of importance will embrace this new and unproven algorithm to kill
the PSL, but no one is willing to add a clause to their policy record.
Which is the greater effort?

Doug Foster


On Mon, Feb 27, 2023 at 12:51 PM John Levine  wrote:

> 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
> you can keep using your current DMARC software. Not our problem.
>
> Like everyone else, I see no reason to encruft our design with hacks
> intended
> to address hypothetical problems that do not actually exist.
>
> R's,
> John
>
> PS: On my list of things I may or may not get around to doing is a web
> page where you can enter a domain name and it'll tell you whether
> you'll get different results with old and new 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

Re: [dmarc-ietf] Treewalk causing changes

[John Levine]

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
you can keep using your current DMARC software. Not our problem.

Like everyone else, I see no reason to encruft our design with hacks intended
to address hypothetical problems that do not actually exist.

R's,
John

PS: On my list of things I may or may not get around to doing is a web
page where you can enter a domain name and it'll tell you whether
you'll get different results with old and new DMARC. 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Tim Wicinski]

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 attempting to work out a
success path for DBOUND2)

On Mon, Feb 27, 2023 at 10:08 AM Scott Kitterman 
wrote:

>
>
> On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> 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, receiving mail from
> >> everywhere in the world, most of the PSL entries will never be examined
> and
> >> most of the PSL errors will never be exposed.   When an error is
> detected
> >> by an evaluator, it is a trivial effort to add or remove a record from
> the
> >> local copy of PSL.  For evaluators, the PSL works fine.
> >>
> >
> >The notion that different operators are using slightly different versions
> >of the PSL is one of the reasons we want to stop depending on the PSL.  I
> >don't think we should offer this as an option.
> >
> >
> >> Domain owners / message senders are the ones who should be powerfully
> >> motivated to replace the PSL.   If so, they should be willing to add a
> tag
> >> that invokes MUST USE TREE WALK because it eliminates ambiguity and
> >> protects them from the PSL.   With that elimination of ambiguity
> >> and corresponding MUSRT, evaluators have a reason to change.   Without
> >> that, evaluators have every reason to ignore this new, unproven, and
> >> imperfect algorithm;
> >>
> >
> >I'm worried about leaving operators with a choice here, for a number of
> >reasons:
> >
> >1) "pct" also presented a choice, and the consensus appears to be that
> this
> >didn't work out at all, for the reasons previously given (mostly related
> to
> >variance in implementations).
> >
> >2) "Stop using the PSL" as a goal is delayed or even thwarted if we add
> >such a tag.  It creates an undefined, possibly infinite, period of
> >migration during which operators can opt out.  If we're going to do this,
> >we should discuss including some kind of firm sunset period for the PSL.
> >But now we're walking in the direction of having a flag day, and everybody
> >hates those.
> >
> >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.
> >
> >-MSK
>
> 100 percent agree.  The only way to stop doing something is to stop doing
> it.  The specification is all we control.  Implementers will adjust and
> transition to the IETF design based on their own business timelines.
>
> Scott K
>
> ___
> 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

[Scott Kitterman]

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, receiving mail from
>> everywhere in the world, most of the PSL entries will never be examined and
>> most of the PSL errors will never be exposed.   When an error is detected
>> by an evaluator, it is a trivial effort to add or remove a record from the
>> local copy of PSL.  For evaluators, the PSL works fine.
>>
>
>The notion that different operators are using slightly different versions
>of the PSL is one of the reasons we want to stop depending on the PSL.  I
>don't think we should offer this as an option.
>
>
>> Domain owners / message senders are the ones who should be powerfully
>> motivated to replace the PSL.   If so, they should be willing to add a tag
>> that invokes MUST USE TREE WALK because it eliminates ambiguity and
>> protects them from the PSL.   With that elimination of ambiguity
>> and corresponding MUSRT, evaluators have a reason to change.   Without
>> that, evaluators have every reason to ignore this new, unproven, and
>> imperfect algorithm;
>>
>
>I'm worried about leaving operators with a choice here, for a number of
>reasons:
>
>1) "pct" also presented a choice, and the consensus appears to be that this
>didn't work out at all, for the reasons previously given (mostly related to
>variance in implementations).
>
>2) "Stop using the PSL" as a goal is delayed or even thwarted if we add
>such a tag.  It creates an undefined, possibly infinite, period of
>migration during which operators can opt out.  If we're going to do this,
>we should discuss including some kind of firm sunset period for the PSL.
>But now we're walking in the direction of having a flag day, and everybody
>hates those.
>
>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.
>
>-MSK

100 percent agree.  The only way to stop doing something is to stop doing it.  
The specification is all we control.  Implementers will adjust and transition 
to the IETF design based on their own business timelines.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Murray S. Kucherawy]

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 never be examined and
> most of the PSL errors will never be exposed.   When an error is detected
> by an evaluator, it is a trivial effort to add or remove a record from the
> local copy of PSL.  For evaluators, the PSL works fine.
>

The notion that different operators are using slightly different versions
of the PSL is one of the reasons we want to stop depending on the PSL.  I
don't think we should offer this as an option.


> Domain owners / message senders are the ones who should be powerfully
> motivated to replace the PSL.   If so, they should be willing to add a tag
> that invokes MUST USE TREE WALK because it eliminates ambiguity and
> protects them from the PSL.   With that elimination of ambiguity
> and corresponding MUSRT, evaluators have a reason to change.   Without
> that, evaluators have every reason to ignore this new, unproven, and
> imperfect algorithm;
>

I'm worried about leaving operators with a choice here, for a number of
reasons:

1) "pct" also presented a choice, and the consensus appears to be that this
didn't work out at all, for the reasons previously given (mostly related to
variance in implementations).

2) "Stop using the PSL" as a goal is delayed or even thwarted if we add
such a tag.  It creates an undefined, possibly infinite, period of
migration during which operators can opt out.  If we're going to do this,
we should discuss including some kind of firm sunset period for the PSL.
But now we're walking in the direction of having a flag day, and everybody
hates those.

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.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

tion 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
> >> > > 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

Re: [dmarc-ietf] Treewalk causing changes

[Dotzero]

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

Thank you.  +1

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Barry Leiba]

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

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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 Messag

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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

[Alessandro Vesely]

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

Re: [dmarc-ietf] Treewalk causing changes

[Barry Leiba]

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 t

Re: [dmarc-ietf] Treewalk causing changes

[Barry Leiba]

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

[Scott Kitterman]

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

[John Levine]

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

[Tim Wicinski]

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

[Alessandro Vesely]

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

Re: [dmarc-ietf] Treewalk causing changes

[Scott Kitterman]

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 fixed.
>
>It also adds all the problems you get with CNAMEs, like long chains
>and loops. If you have enough control over your DMARC records to add a
>"refer" thing, why couldn't you just copy the policy you want to use?
>
>While I agree that the results for ret.bmcc.cuny.edu will be
>different, I see precious little reason to think that anyone would
>care. If people can find examples where it's more plausible that the
>difference would matter, please send them along.

Agreed.  Adding sp=none to the bmcc.cuny.edu would achieve the same result 
without adding complexity to the protocol.  Let's not (add the complexity).

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[John Levine]

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 chains
and loops. If you have enough control over your DMARC records to add a
"refer" thing, why couldn't you just copy the policy you want to use?

While I agree that the results for ret.bmcc.cuny.edu will be
different, I see precious little reason to think that anyone would
care. If people can find examples where it's more plausible that the
difference would matter, please send them along.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

I am intrigued by Alex's idea.

We are trying to replace the PSL because of potential errors, but the
proposed Tree Walk also has ambiguity that leads to potential errors.   The
ideal solution would be for domain owners to publish apply an exact-match
policy for every valid From domain, just like SPF.Then the default
policy is used to block non-mail domains, and every published policy could
be used to ensure that this happens.

But policy multiplication causes management complexity, because each policy
triggers independent reporting to independently configured recipient
addresses.The REFER:url term would allow the referred domain to provide
any data that is not configured explicitly on the exact-match policy.
 Simplified administration without ambiguity.   Seems like a big win.

DF



On Fri, Feb 24, 2023 at 3: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

Re: [dmarc-ietf] Treewalk causing changes

[Seth Blank]

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.

Seth, hatless

On Fri, Feb 24, 2023 at 12:21 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.
> > >>>

Re: [dmarc-ietf] Treewalk causing changes

[Brotman, Alex]

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,
> >>> >>
> >>> >> (speaking as a DNS person).  I thi

Re: [dmarc-ietf] Treewalk causing changes

[Alessandro Vesely]

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,
>>
>> (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 > 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.300INTXT"v=DMARC1; p=quarantine;
>>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
>>> dmarc_...@emaildefense.proofpoint.com"
>>>
>>> _dmarc.cuny.edu.3325INTXT"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


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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

Re: [dmarc-ietf] Treewalk causing changes

[John Levine]

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Barry Leiba]

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,
>> >>
>> >> (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 > >> 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.300INTXT"v=DMARC1; p=quarantine;
>> >>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
>> >>> dmarc_...@emaildefense.proofpoint.com"
>> >>>
>> >>> _dmarc.cuny.edu.3325INTXT"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

Re: [dmarc-ietf] Treewalk causing changes

[Douglas Foster]

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,
> >>
> >> (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  >> 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.300INTXT"v=DMARC1; p=quarantine;
> >>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
> >>> dmarc_...@emaildefense.proofpoint.com"
> >>>
> >>> _dmarc.cuny.edu.3325INTXT"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

Re: [dmarc-ietf] Treewalk causing changes

[John R. Levine]

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; 
ruf=mailto:dmarc_...@emaildefense.proofpoint.com;

_dmarc.cuny.edu.3325INTXT"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"


Good catch, although in this case I think the most likely result is that 
the people at bmcc.cuny.edu will say "who set up Ret.bmcc.cuny.edu?"  I 
see that bmcc.cuny.edu and cuny.edu both use Proofpoint in front of O365, 
while Ret.bmcc.cuny.edu goes directly to O365.  There's some other 
strangeness; www.cuny.edu is a CNAME for web.cuny.edu which has an MX to 
mail-relay.cuny.edu. which has 7 A records pointing to machines running 
sendmail.


It might be interesting to set up a web page where you can put in a mail 
domain and it'll tell you whether its treatment will change with the tree 
walk.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Scott Kitterman]

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,
>>
>> (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 > 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.300INTXT"v=DMARC1; p=quarantine;
>>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
>>> dmarc_...@emaildefense.proofpoint.com"
>>>
>>> _dmarc.cuny.edu.3325INTXT"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

Re: [dmarc-ietf] Treewalk causing changes

[Barry Leiba]

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,
>
> (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  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.300INTXT"v=DMARC1; p=quarantine;
>> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
>> dmarc_...@emaildefense.proofpoint.com"
>>
>> _dmarc.cuny.edu.3325INTXT"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

Re: [dmarc-ietf] Treewalk causing changes

[Tim Wicinski]

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  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.300INTXT"v=DMARC1; p=quarantine;
> fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com; ruf=mailto:
> dmarc_...@emaildefense.proofpoint.com"
>
> _dmarc.cuny.edu.3325INTXT"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-ietf] Treewalk causing changes

[Elizabeth Zwicky]

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; ruf=mailto:dmarc_...@emaildefense.proofpoint.com"_dmarc.cuny.edu.3325INTXT"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