Subject: Re: [dmarc-ietf] What is a policy domain? an org domain? How do we not break existing DMARC?

From: Douglas Foster <[email-masked]>
Date: Tue, 1 Mar 2022 07:06:14 -0500

John overstates his case when he objects to creating a scheme which
requires everyone to update their policy records.    No such requirement
has been proposed.  Most participants MAY leave their policy records
unmodified, but there are good reasons for them to CHOOSE to add the role
indicator to their record.

The assumption that virtually no one will implement a role indicator seems
to assume that no one will read, understand, and act on our document
according to their understanding of their best interests.    If we actually
believe this is the case, we should stop wasting our time right now.

Let's look at who does not require an org-top role indicator:
- an organization which is registered with a PSD that does not have a
PSD-level DMARC policy.
- an organization which is registered with a PSD that has a DMARC policy
that is properly tagged.

When is a PSD flag necessary or useful?

1.       For all registrars, a registrar-level policy prevents
impersonation of unregistered domains.

2.       For registered organizations, an org-top policy prevents relaxed
alignment errors caused by

a.       a next-level parent domain DMARC policy that incorrectly lacks a
Registrar tag, and (b) a Registrar-tagged DMARC policy which is more than
one level above the organization top, leaving one or more levels with no
DMARC policy and therefore assumed to be part of the organization.

b.       For private registrars, a registrar-level policy prevents client
domains from impersonating each other.

3.       For private registration client organizations, an org-top policy
prevents impersonation by siblings within the private registration domain,
by the private registrar organization,  and by PSD-level siblings of the
private registrar.

4.       When an org-top policy is not detected, the evaluator must query
DNS until a PSD-level policy is detected or a TLD is queried.   Therefore,
domain owners who publish an org-top policy benefit evaluators and DNS
operators by improving efficiency.

I tend to believe that when participants read that a mis-labeled PSD policy
can cause false positives, that they will choose to publish org-type
policies as a risk management measure.   I expect regulators and insurance
companies to drive this action as well.

I also believe that a non-trivial number of domain owners will implement
the org-top tag for the efficiency of evaluators.

I have no opinion about  whether private registration clients will embrace
DMARC using relaxed alignment or SP pollicies, but if they do, they will be
the one group where role tagging is mandatory for correct results.

Regardless of the volume of participation, we need a role tagging
specification that allows participation and minimizes confusion.

Doug

On Mon, Feb 28, 2022 at 3:04 PM John R Levine <[email-masked]> wrote:

> >> I think it would be a cruel joke on our users to give it a name that
> looks
> >> like something that has to be in every org domain's record.
> >
> > You're welcome to suggest better names.
>
> Like I said, psd=y / psd=n
>
> > Hm...  However small, it's the only quality gain we can expect by
> switching
> > to tree walk.
>
> Sorry, that's just wrong.  The PSL is only an approximation to the
> boundaries for http cookies, and it's a worse approximation to DMARC
> boundaries.  The tree walk lets domains say what their actual policy is.
>
> > Roughly, I think it could grow to the size of the PSL private domains
> section, no?
>
> Yes, that might be the number of DMARC records with psd=y, although if
> the PSD doesn't do mail and doesn't have a PSD above it, which is the
> typical case, it doesn't need a DMARC record at all.
>
> Regards,
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>