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
<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.
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
<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
_______________________________________________
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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
