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