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