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 organizat

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] I-D Action: draft-ietf-dmarc-dmarcbis-27.txt

[Tim Wicinski]

Fantastic Whitespace Engineering Mr Levine.

Looks Good.

tim


On Tue, Feb 28, 2023 at 11:17 AM Todd Herr  wrote:

> This draft is a merge of the pull request that Mr. Levine mentioned in the
> "Question on RFC7489: trailing whitespaces" thread.
>
> It also automagically updated references to the two associated reporting
> documents to their current versions.
>
> On Tue, Feb 28, 2023 at 11:14 AM  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This Internet-Draft is a work item of the Domain-based Message
>> Authentication, Reporting & Conformance WG of the IETF.
>>
>> Title   : Domain-based Message Authentication, Reporting,
>> and Conformance (DMARC)
>> Authors : Todd M. Herr
>>   John Levine
>>   Filename: draft-ietf-dmarc-dmarcbis-27.txt
>>   Pages   : 71
>>   Date: 2023-02-28
>>
>> Abstract:
>>This document describes the Domain-based Message Authentication,
>>Reporting, and Conformance (DMARC) protocol.
>>
>>DMARC permits the owner of an email author's domain name to enable
>>verification of the domain's use, to indicate the Domain Owner's or
>>Public Suffix Operator's message handling preference regarding failed
>>verification, and to request reports about the use of the domain
>>name.  Mail receiving organizations can use this information when
>>evaluating handling choices for incoming mail.
>>
>>This document obsoletes RFCs 7489 and 9091.
>>
>>
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-27
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>> :internet-drafts
>>
>>
>> ___
>> dmarc mailing list
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
> --
>
> *Todd Herr * | Technical Director, Standards and Ecosystem
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for the use of individual(s)
> authorized to receive it. If you are not an intended and authorized
> recipient you are hereby notified of any use, disclosure, copying or
> distribution of the information included in this transmission is prohibited
> and may be unlawful. Please immediately notify the sender by replying to
> this email and then delete it from your system.
> ___
> 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] I-D Action: draft-ietf-dmarc-dmarcbis-27.txt

[Todd Herr]

This draft is a merge of the pull request that Mr. Levine mentioned in
the "Question
on RFC7489: trailing whitespaces" thread.

It also automagically updated references to the two associated reporting
documents to their current versions.

On Tue, Feb 28, 2023 at 11:14 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This Internet-Draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance WG of the IETF.
>
> Title   : Domain-based Message Authentication, Reporting,
> and Conformance (DMARC)
> Authors : Todd M. Herr
>   John Levine
>   Filename: draft-ietf-dmarc-dmarcbis-27.txt
>   Pages   : 71
>   Date: 2023-02-28
>
> Abstract:
>This document describes the Domain-based Message Authentication,
>Reporting, and Conformance (DMARC) protocol.
>
>DMARC permits the owner of an email author's domain name to enable
>verification of the domain's use, to indicate the Domain Owner's or
>Public Suffix Operator's message handling preference regarding failed
>verification, and to request reports about the use of the domain
>name.  Mail receiving organizations can use this information when
>evaluating handling choices for incoming mail.
>
>This document obsoletes RFCs 7489 and 9091.
>
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-27
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-27.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Domain-based Message Authentication, 
Reporting & Conformance WG of the IETF.

Title   : Domain-based Message Authentication, Reporting, and 
Conformance (DMARC)
Authors : Todd M. Herr
  John Levine
  Filename: draft-ietf-dmarc-dmarcbis-27.txt
  Pages   : 71
  Date: 2023-02-28

Abstract:
   This document describes the Domain-based Message Authentication,
   Reporting, and Conformance (DMARC) protocol.

   DMARC permits the owner of an email author's domain name to enable
   verification of the domain's use, to indicate the Domain Owner's or
   Public Suffix Operator's message handling preference regarding failed
   verification, and to request reports about the use of the domain
   name.  Mail receiving organizations can use this information when
   evaluating handling choices for incoming mail.

   This document obsoletes RFCs 7489 and 9091.


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-27.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmarc-dmarcbis-27


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

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
https://www.ietf.org/mailman/listinfo/dmarc_

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