Subject: [dmarc-ietf] Let's Work on the Tree Walk Text

From: Todd Herr <[email-masked]>
Date: Wed, 16 Feb 2022 11:02:16 -0500

Greetings.

When dmarcbis-04 was published, there was discussion on the list that the
text specific to tree walk and organizational domain was wildly off the
mark.

Based on that discussion, I made another stab at the text and released it
in dmarcbis-05, which has engendered further comment that the text isn't
right.

So let's work on it.

In this message, I'll show the current text for section 4.5
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#name-dns-tree-walk>,
currently titled "DNS Tree Walk". I'll post a separate message for the
reverse tree walk, which will focus on section 4.6
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#name-determining-the-organizatio>,
which is currently titled "Determining the Organizational Domain".

My goal here is to have something to put in one or more new revs prior to
IETF 113 so that there can perhaps be further discussion of the topics
during that meeting.

Thank you.

Current text of section 4.5 follows.

------------------------------------------- cut here
----------------------------------------------
4.5.
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5>DNS
Tree Walk
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#name-dns-tree-walk>

While the DMARC protocol defines a method for communicating information
through the publishing of records in DNS, it is not necessarily true that a
DMARC policy record for a given domain will be found in DNS at the same
level as the name label for the domain in question. Instead, some domains
will inherit their DNS policy records from parent domains one level or more
above them in the DNS hierarchy, and these records can only be discovered
through a technique described here, one known colloquially as a "DNS Tree
Walk".
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-1>

The process for a DNS Tree Walk will always start at the point in the DNS
hierarchy that matches the domain in the RFC5322.From header of the
message, and will always end no later than the Public Suffix Domain that
terminates the RFC5322.From domain. To prevent possible abuse of the DNS, a
shortcut is built into the process so that RFC5322.From domains that have
more than five labels do not result in more than five DNS queries.
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-2>

The generic steps for a DNS Tree Walk are as follows:
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-3>

   1.

   Query the DNS for a DMARC TXT record at the DNS domain matching the one
   found in the RFC5322.From domain in the message. A possibly empty set of
   records is returned.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.1.1>
   2.

   Records that do not start with a "v=" tag that identifies the current
   version of DMARC are discarded.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.2.1>
   3.

   If the set is now empty, or the set contains one valid DMARC record that
   does not contain the information sought, then determine the target for
   additional queries, using steps 4 through 8 below.
   4.

   Break the subject DNS domain name into a set of "n" ordered labels.
   Number these labels from right to left; e.g., for "a.mail.example.com",
   "com" would be label 1, "example" would be label 2, "mail.example.com"
   would be label 3, and so forth.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.4.1>
   5.

   Count the number of labels found in the subject DNS domain. Let that
   number be "x". If x < 5, remove the left-most (highest-numbered) label from
   the subject domain. If x >= 5, remove the left-most (highest-numbered)
   labels from the subject domain until 4 labels remain. The resulting DNS
   domain name is the new target for subsequent lookups.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.5.1>
   6.

   Query the DNS for a DMARC TXT record at the DNS domain matching this new
   target in place of the RFC5322.From domain in the message. A possibly empty
   set of records is returned.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.6.1>
   7.

   Records that do not start with a "v=" tag that identifies the current
   version of DMARC are discarded.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.7.1>
   8.

   If the set is now empty, or the set contains one valid DMARC record that
   does not contain the information sought, then determine the target for
   additional queries by removing a single label from the target domain as
   described in step 5 and repeating steps 6 and 7 until there are no more
   labels remaining or a valid DMARC record containing the information sought
   has been retrieved.
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.8.1>

For determining the Organizational Domain used for determining relaxed
alignment, the same process is followed, except in the reverse order.
See Section
4.6
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#determining-the-organizational-domain>
for
further details.
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-5>

To illustrate, for a message with the arbitrary RFC5322.From domain of "
a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require the
following five queries, in order to locate the policy domain:
<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-6>

   - _dmarc.a.b.c.d.e.mail.example.com
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.1>
   - _dmarc.e.mail.example.com
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.2>
   - _dmarc.mail.example.com
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.3>
   - _dmarc.example.com
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.4>
   - _dmarc.com
   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-7.5>

------------------------------------------- cut here
----------------------------------------------

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*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.

---

From: "John Levine" <[email-masked]>
Date: 16 Feb 2022 18:52:42 -0500

It appears that Todd Herr  <[email-masked]> said:
>message, and [will always end no later than the Public Suffix Domain that
>terminates the RFC5322.From domain. ]

I expect that in about 98% of cases, the tree walk will not find a PSD record, so
that's not true.

I'd just combine the sentences to "and ends five labels above the From domain
if no DMARC records have been found."

>   <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.5.1>

This says that if the name is more than six labels deep, you immediately jump to the five
label super-parent to start the tree walk.  What I originally intended was to walk five
labels and then stop, e.g.

h.g.f.e.d.c.b.a
g.f.e.d.c.b.a
f.e.d.c.b.a
e.d.c.b.a
d.c.b.a

I don't feel strongly either way and since there are close to zero valid
domain names with more than six labels, it makes little practical difference, but we
need to be sure we agree which one we mean.

>alignment, the same process is followed, except in the reverse order.

I don't see the point.  The domain this process just found is the org domain, and walking down can
be misleading, e.g. consider www.abc.uk.com.

it happens that uk.com is a sort-of-registry so the org domain you want is abc.uk.com but a walk
down is likely to stop at uk.com since it has a DMARC record.

R's,
John

---

From: Todd Herr <[email-masked]>
Date: Thu, 17 Feb 2022 12:20:46 -0500

> if no DMARC records have been found."
In the interests of precision, since many domains won't have five labels,
would you support the following?

"and ends no more than five labels above the From domain if no DMARC
records have been found."

> >   <
> https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-05.html#section-4.5-4.5.1
> >
>

Step 5 here first appeared in dmarcbis-04, and was proposed by Mr.
Kitterman here -
https://mailarchive.ietf.org/arch/msg/dmarc/iOuQzCPlD99dxqt8_q-9C1gl24o/ -
but yes, let's come to agreement on which method we want.

> be misleading, e.g. consider www.abc.uk.com.

This is not what I understood the purpose of the tree walk to be. My
understanding was that it was meant to find the DMARC policy that's
applicable to the message, not to identify the Org Domain for the
RFC5322.From domain.

As I understood it, the tree walk was designed to allow for a situation
such as:

   - RFC5322.From domain = a.b.example.com
   - _dmarc.a.b.example.com = NXDOMAIN
   - _dmarc.b.example.com = properly formatted DMARC TXT record
   - _dmarc.example.com = properly formatted DMARC TXT record, one that's
   perhaps different than _dmarc.b.example.com

RFC 7489 doesn't allow for discovery of _dmarc.b.example.com, but the tree
walk would, and example.com would still be the Org Domain.

I allow that I could be very wrong here.

--

---

From: "John R Levine" <[email-masked]>
Date: 17 Feb 2022 14:17:30 -0500

> records have been found."

Sure.

>> [ tree walk starting at the From domain ]

I took another look at Scott's original message, and now I'm trying to 
figure out if there are situations where an upward vs downward tree walk 
will make a significant difference and the downward walk is a surpsise.

Consider the domain us.com which acts as a pseudo-registry, and say we 
have these records for their customer cust.us.com

_dmarc.com NXDOMAIN
_dmarc.us.com something (it has an MX)
_dmarc.cust.us.com something (it also has an MX)
_dmarc.sales.cust.us.com NXDOMAIN

They send a messge from sales.cust.us.com.  If you believe the PSL, the 
org domain is cust.us.com.  If you do an upward tree walk, the first DMARC 
record is cust.us.com.  If you do a downward tree walk, ???

I suppose _dmarc.us.com should have psd=y but it's also a domain that 
sends and receives mail.  This sort of ambguity is surprisingly common.

For extra excitement, imagine the mail is from mail.cust.svc.firenet.ch, 
where the PSL says the org is cust.svc.firenet.ch.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 18 Feb 2022 14:39:03 +0100

On Thu 17/Feb/2022 20:17:30 +0100 John R Levine wrote:
> I took another look at Scott's original message, and now I'm trying to figure 
> out if there are situations where an upward vs downward tree walk will make a 
> significant difference and the downward walk is a surpsise.
> 
> Consider the domain us.com which acts as a pseudo-registry, and say we have 
> these records for their customer cust.us.com
> 
> _dmarc.com NXDOMAIN
> They send a message from sales.cust.us.com.  If you believe the PSL, the org 
> domain is cust.us.com.  If you do an upward tree walk, the first DMARC record 
> is cust.us.com.  If you do a downward tree walk, ???
> 
> I suppose _dmarc.us.com should have psd=y but it's also a domain that sends and 
> receives mail.  This sort of ambiguity is surprisingly common.

If they have MX and non-trivial SPF records, they probably are using the domain 
to send and receive mail.  Yet, they also host independent subdomains.  IMHO, 
we should trait [email-masked] as a regular domain, without the limitations we 
apply to PSDs.  At the same time we should allow cust.us.com to claim 
independence from us.com, as far as DMARC is involved.  We need to allow org=y.

Note that this is a point where we can do better than relying on the PSL.  RFC 
7489 proposed to use heuristics /in the absence of more accurate methods/. 
After years of experience, can we propose a new method which can be more 
accurate?  Accuracy comes from publishing DMARC records with psd/org/sub flags.

In the quoted scenario, assuming "something" is a DMARC record without flags, a 
tree walk delivers us.com as the org domain.  To avoid BEC, there must be a 
transition period during which mail filters check the PSL in such cases; that 
is, in the absence of flags.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 18 Feb 2022 17:47:18 -0500

It appears that Alessandro Vesely  <[email-masked]> said:
>independence from us.com, as far as DMARC is involved.

So far so good.

>  We need to allow org=y.

If you mean we can allow DMARC records to contain org=y which evaluators ignore,
sure.  Otherwise no, it's painfully not backward compatible.

>is, in the absence of flags.

Um, surely you've been around long enough to know that "transition period"
means "forever".

Just treat the first DMARC record you find in an upward walk as an org.  It
seems to me that will get the desired result at least as often as the PSL does,
and does not require an incompatible flag or a forever period.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sat, 19 Feb 2022 00:04:03 -0500

I am working on more specific language, but here is a statement of the
approach that I believe will provide an appropriate solution:

Design Requirements and Implications:

1) DMARCbis must provide protection for PSO-registered organizations,
Private Registrar clients, and organizational subunits that wish to be
evaluated as if they were a Private Registration client.  This feature
represents a significant security improvement over RFC 7489 and is the
primary incentive for abandoning the PSL.

2) DMARCbis must support PSD policies, including PSDs with variable
depth.

PSDs that publish DMARC policies can be required and expected to use the
“psd=y” term.  However, to mitigate the risk of a misconfigured PSD policy,
organizations should be encouraged to use the “org=y” term to explicitly
identify their top-of-organization domain name.

A DMARC policy may contain both “psd=y” and “org=y”, because a single
domain may be PSO-registered and also act as a Private Registrar to all of
its subdomains.   When both exist, the “psd=y” flag takes precedence when
walking up the tree, while the “org=y” applies when starting the walk at
exact-match.   In all other cases, an “org=y” policy will be below any
“psd=y” policy, and “org=y” will take precedence during the tree walk
upward.

3) DMARCbis must be able to identify “same organization” for relaxed
alignment with an accuracy very similar to that of the PSL, albeit with
different sources of risk.

I assert without proof that most DMARC-participating organizations will
have an organization-level policy, as the design of RFC 7489 causes
publication of an organizational policy to be natural and desirable.
Therefore, in the absence of a policy tagged with either “psd=y” or
“org=y”, the topmost DMARC policy can be treated as the organizational
domain, without consulting the PSL.

If the top-most policy found is actually below the organizational domain,
relaxed alignment will be applied on this more restrictive scope.   An
organization which is unhappy with this result will be incented to publish
a DMARC policy at the organizational domain level, so that relaxed
alignment will be performed correctly.

4) DMARCbis should implement two tests for non-existence, organizational
existence and From domain existence.

Organizational existence is satisfied if any resource record is found in
the organization’s domain subtree.   If a DMARC policy is found anywhere
within the organization structure, this also proves organization
existence.   If the policy search ends with only a “psd=y” policy, then the
organization must be tested by doing a DNS query on the organizational
domain.   A result of NXDOMAIN means that the organization is not
registered and the DMARC result is the special-case result of
FAIL-UNREGISTERED.   The NP clause is redundant when the “psd=y” flag is
present, because the NP clause of a "psd=y" policy is only applied to the
organizational domain.

Relaxed alignment permits a FROM domain to have no presence in DNS.
However, a domain owner may publish an NP policy which asserts that the
FROM domain will and must exist in DNS.   When the NP policy is present on
an organization’s DMARC policy record, a DNS lookup is performed on the
FROM domain.   It it returns NXDOMAIN, then the DMARC result is the special
case of FAIL-NONEXISTENT

5) The tree walk must produce the equivalent of a complete walk from the
FROM domain to the TLD.    A walk upward can end as soon as the first
"org=y" or "psd=y" term is found, while a  walk down cannot exit early.
 Therefore, the technical advantage is on the side of a walk up.   The
Subdomain default policy and the Relaxed Alignment boundary occur at the
same point, which is the organizational domain.  Therefore these attributes
are determined together, on the first tree walk.

6) Determining whether the authenticating domain is in the same
organization, including absence of any Private Registrar boundaries, is
usually determined with a second tree walk.   Sometimes, a domain mismatch
can be detected without the cost of a second tree walk.

Examples:

PSO-registered domain example:  "subdomainpath.example.bank"

DMARCbis must always be able to find the DMARC policy at example.bank,
regardless of name depth, if it exists.   DMARCbis must always be able to
find the DMARC policy at .Bank if none exists at example.bank

Private-registrar domain example: "
subdomainpath.MyDomain.Clients.PrivateRegistrar.com"

DMARCbis must be able to find the policy at MyDomain if it exists, and
should be able to find a lower level policy if the depth is not excessive.
 Private Registrar clients may provide sufficient reason to use a depth
limit slightly greater than 5.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 19 Feb 2022 18:37:12 +0100

> sure.  Otherwise no, it's painfully not backward compatible.

Non-upgraded DMARC filters will ignore those (and use just the PSL).  Upgraded 
filters can use the flags, and obtain more accurate results.

As a DMARC filter developer, I'd be rather skeptic of modifying a working code 
to introduce oversimplifications.  However, I could take a look at the domains 
between the From: domain and its PSD, in order to gain accuracy.

If DMARC is successful —I mean raising to some two-digit percentage— those 
flags could be used to update the PSL.

> Um, surely you've been around long enough to know that "transition period" 

Yes, if the PSL lasts forever.

> and does not require an incompatible flag or a forever period.

To me, it seems you get the right result more often if you take the last 
(topmost) DMARC record found.  Didn't we have some numbers on that?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 19 Feb 2022 12:47:33 -0500

> Yes, if the PSL lasts forever.

No, if old DMARC verifiers last forever, which they will.  For example, we 
published the RFC 8463 about new DKIM signatures four years ago.  How many 
ed25519 signatures do you see?

>> seems to me that will get the desired result at least as often as the PSL 
>> does, and does not require an incompatible flag or a forever period.
>

I don't remember, perhaps someone else can remind us.  In the situation 
Mike's been warning about, the topmost record fails dangerously.

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Sun, 20 Feb 2022 14:07:40 -0500

Below is draft language which implements the design principles in my
previous email.     Some additional content is needed to discuss NP policy
within an organization, and to describe the mechanics of the first tree
walk, and to define the second tree walk.

Doug Foster

Organizational Domain

The organizational domain is a boundary point which serves as the upper
bound for relaxed alignment tests, and provides the reference point for
default subdomain policies.   DMARC recognizes these types of
organizational boundaries:

A PSO Registration obtains its DNS subtree allocation from a Public Suffix
Operator.   The organizational domain is an FQDN comprised of the public
suffix plus one segment.

A Private Registration obtains its DNS subtree allocation from a
PSO-registered organization.  The organizational domain is the registration
domain plus one segment.   These arrangements are not recommended, but for
accurate email authentication they are being acknowledged.

A Partitioned Subunit chooses to have its DNS subtree treated as an
independent unit for purposes of DMARC validation.

Specifying the Organizational Domain

Each registered organization SHOULD publish a DMARC record for its
organizational domain name, and SHOULD include the term “org=y” to indicate
that this name should be identified as an organizational domain.

PSOs MAY publish DMARC policy records to serve as default policies for
registered domains within their subtree.   When this is done, the policy
MUST contain the term “psd=y” to indicate that this policy is used only for
disposition and reporting, but not for alignment, because every subdomain
of this name is an independent entity.

Private Registrars SHOULD publish a DMARC policy at the domain below which
private registrations are issued, and this policy MUST contain the term
“psd=y” to indicate that this policy is used only for disposition and
reporting, but not for alignment, for the subtrees below this point.   The
psdy term prevents relaxed alignment from allowing one client domain from
impersonating another client and having the impersonation incorrectly
accepted using relaxed authentication.   The presence of “psd=y” does not
indicate that the domain is actually a PSO, only that subdomains should be
treated as independent entities for purposes of DMARC evaluation.

A single DMARC record may include both the “org=y” clause and the “psd=y”
clause, since a domain may be registered with a PSO and may also grant
private registrations using subdomains of its organizational domain.   The
“org=y” indicates that a boundary exists between this domain and the parent
domain, while the “psd=y” indicates that a boundary exists between this
domain and all subdomains.   Consequently, the “org=y” term takes
precedence when testing for strict alignment, while the “psd=y” term
applies when walking up from a subdomain to detect the boundary for relaxed
alignment.

Because an Organizational Domain must be registered, that registration must
be verifiable, as evidenced by a detected resource record within the
organizational subtree.   This requirement is satisfied if a DMARC policy
is found within the organizational subtree.   However, if DMARC is applied
because of a “psd=y” policy occurring on the organizational parent,
existence is uncertain.   To provide certainty, a DNS lookup MUST be
performed on the organizational domain.  If the lookup returns NXDOMAIN,
the organizational domain has no resource records, and the DMARC result is
FAIL-UNREGISTERED.

Finding the Organizational Domain

The organizational domain is determined by walking up from the RFC5322.From
domain to toward the top-level domain.

-          If a DMARC policy with “org=y” is found, the associated domain
is the organizational domain.

-          If a DMARC policy with “psd=y” is found, the first child of the
associated domain is the organizational domain.

-          If no policy is found containing either “org=y” or “psd=y”, then
the top-most policy found is the organizational domain.

-          If no policy is found, the domain does not participate in DMARC.

Note that the organizational domain is not used, and the evaluator does not
need to compute it, when:

-          a DMARC policy is published for the RFC5322.From domain, and

-          the policy requires strict alignment for both SPF and DKIM, or
DKIM PASS is achieved using identifiers that have strict alignment.

Security Considerations -- Improper Alignment

If a PSO publishes a policy record without the “psd=y” term, and
organizations publish no policy or publish a policy without the “org=y”
term, then the PSD policy will be treated as an organizational domain and
relaxed alignment may allow intra-PSD impersonations to be
authentication.   This is why PSD policies MUST include the “psd=y” term.
To mitigate the risk from an error of this type, and to improve processing
efficiency, organizations SHOULD publish an organizational domain policy
with the “org=y” term.

Similarly, if a Private Registrar publishes a DMARC policy for its
organization, but fails to publish a “psd=y” policy for his client
registration point, his clients may be able to impersonate each other and
improperly pass DMARC authentication using relaxed authentication
criteria.  Clients SHOULD mitigate this risk by publishing a DMARC policy
with “org=y” at their organization’s top-level domain.

Security Considerations – Altered Scope for Relaxed Alignment

Because RFC7489 uses an externally-obtained public suffix list for relaxed
alignment, the alignment test does not require a DMARC policy record at the
Organizational level.    By the algorithm used in this document, the
organization must publish a DMARC policy for the organizational domain, to
cause relaxed alignment to be applied correctly.    When an
organizational domain policy is missing, the scope used for relaxed
alignment will be restricted to a subset of the entire organization, based
on whatever lower-level policy is detected and applied.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Feb 2022 14:53:41 -0500

> Mike's been warning about, the topmost record fails dangerously.

As I understand it, yes, but I don't 100% agree that it's a protocol problem.  
Typically if a company you have hired to do a job does so poorly, then you 
hire someone else.  I don't think it's possible to write protocol to avoid 
problems like this entirely.

To jump back to your us.com example:

> ... customer cust.us.com

Using the RFC 7489/PSL approach, the org domain is cust.us.com (PSL domain 
[us.com] plus one label).

Walking up the tree one would look for DMARC records in:
_dmarc.sales.cust.us.com
_dmarc.cust.us.com 

and then potentially:

_dmarc.us.com
_dmarc.com

If us.com had published a DMARC record with psd=y, then we would know for sure 
that cust.us.com is the org domain.  I think when walking up you want the first 
record for policy domain and the last non-PSD record for org domain.  

In your example both the first DMARC record and the org domain are the same, 
but imagine that later cust.us.com decided that for their sales subdomain they 
needed a different handling policy, so a new DMARC record appears at 
_dmarc.sales.cust.us.com.  If we take the first DMARC record as the org domain, 
then it changes from cust.us.com to sales.cust.us.com.  If they had been using 
dkim.cust.us.com it would suddenly fail to align.  I think this would be a 
very surprising property of the system and not really what we are after.

On the other hand, if you walk up starting with the 5322.From domain to find 
policy and walk down to find the org domain, stopping at the first, non-psd=y 
domain you find, I think it works better:

_dmarc.com
_dmarc.us.com
_dmarc.cust.us.com

Making changes below the org level no longer affects which domain is the org 
domain.

I do think that an exact match should always be used.  For example, let's 
imagine the operators of us.com decide to use it in email for their own email 
and publish a DMARC record, but they use psd=y so as to not disturb the 
alignment of their customer's mail.

When looking for the policy domain for a message with 5322.From of us.com, 
first _dmarc.us.com is looked up and a record is found, so that is the policy 
record.  Then the org domain is identified:

_dmarc.com
_dmarc.us.com

A record is found and even though it's got psd=y, it's the org domain because 
us.com is the 5322.From domain.

I think walk-up for policy and walk down for org yields less surprising 
results and will more consistently emulate the non-error results from the 
current PSL based approach (in RFC 7489 domains between the exact domain and 
the org domain are ignored, walking down the tree would also preserve that 
property of the existing system).

The only "new" requirement it imposes is for the org domain to have a DMARC 
record.  There may be a non-zero number of domains that don't have one now, 
but I think it will be exceedingly rare.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Feb 2022 15:00:32 -0500

On Wednesday, February 16, 2022 6:52:42 PM EST John Levine wrote:
> This says that if the name is more than six labels deep, you immediately
> jump to the five label super-parent to start the tree walk.  What I
> originally intended was to walk five labels and then stop, e.g.
> 
> h.g.f.e.d.c.b.a
> g.f.e.d.c.b.a
> f.e.d.c.b.a
> e.d.c.b.a
> d.c.b.a
> 
> domain names with more than six labels, it makes little practical
> difference, but we need to be sure we agree which one we mean.

This goes back to October last year.  See starting at:

https://mailarchive.ietf.org/arch/msg/dmarc/Bpi5FsMgkdM_EutFameAGvcg8-I/
Date: Fri, 29 Oct 2021 10:03:06 -0400
Message-ID: <2499275.yImaVS0A6X@zini-1880>
Subject: [dmarc-ietf] Nature of the PSL as related to DMARC,  was: Re:  Topic 
for IETF 112 - Policy Discovery

Although you did talk me out of the private domain suggestion I made in that 
email, but recollection is that because the longest "real" PSL entry was four 
deep, jumping to 5 and going from there would cover all the real cases and not 
have any potential for weird results if forged email used a large number of 
sub-domain levels to try to avoid DMARC.

I had thought we were in agreement on that point.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2022 13:07:15 -0500

>problems like this entirely.

In general I agree, but in the world of standards we have a very long tail of
software that is updated very slowly.  So I think our goal has to be that the
results we get from the tree walk should be close to and no worse than what
came before.  That has to apply to poorly configured systems, too, much though
we'd prefer otherwise.  (I would really like to require that every domain that
receives mail has an MX, now that we've had a 40 year transition period, but
it's not happening.)

>record for policy domain and the last non-PSD record for org domain.  

Now I'm confused.  The policy and org domain used to be the same, but now they
seem to be different.  That's not necessarily wrong, but if we're going to
separate them, then we need to be crystal clear what the function of each is.

>very surprising property of the system and not really what we are after.

Conversely, as it stands now, us.com does not have a PSD flag so if we take
your approach, foo.us.com and bar.us.com are aligned and there is nothing
either can do about it other than ask Centralnic to change their DMARC record.

Either way some people will be surprised.  We need to consider both how many
will be surprised, and the consequences of the surprise.  Which is worse, having
some currently aligned mail fail, or allowing a new class of phishes?  Neither
is great but the latter seems worse.

>alignment of their customer's mail.

Yes, that seems right, although there is a surprisingly long set of 2LDs
that are PSDs and also have regular DMARC records now.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Feb 2022 13:24:30 -0500

On Monday, February 21, 2022 1:07:15 PM EST John Levine wrote:
...
> >If us.com had published a DMARC record with psd=y, then we would know for
> >sure that cust.us.com is the org domain.  I think when walking up you want
> >the first record for policy domain and the last non-PSD record for org
> >domain.
> Now I'm confused.  The policy and org domain used to be the same, but now
> they seem to be different.  That's not necessarily wrong, but if we're
> going to separate them, then we need to be crystal clear what the function
> of each is.
...

I don't think that's right.

Today, if I send mail from 5322.From example.kitterman.com that is signed by 
dkim.kitterman.com, if example.kitterman.com has a DMARC record, then that 
would be the policy domain, but the message would meet the requirement for 
relaxed alignment because both example.kitterman.com and dkim.kitterman.com 
have the same org domain (kitterman.com).  I don't think what I'm proposing is 
any different.

Scott K

---

From: Douglas Foster <[email-masked]>
Date: Mon, 21 Feb 2022 17:55:56 -0500

Under RFC 7489, the organizational domain provides the default policy for
subdomains and the upper bound for relaxed alignment.   The organizational
domain is needed when (a) the From domain does not have a DMARC policy, or
(b) the From domain policy allows relaxed alignment.

Scott's proposal seems to involve a walk up to determine the policy when an
exact-match does not exist, and a second walk to determine the
alignment boundary.   Only one walk is needed, because they need to
converge on the same point.   I have argued that the one walk needs to be a
walk up because we need to be concerned about both PSO registration
boundaries and Private registration boundaries.

John's proposal seems to ignore the problem of getting the organizational
domain correct, and simply treat the first policy found as if it was
reliably known to be the correct one.   I can see many situations where
this is unlikely to be the correct result, so I see no reason to
believe that the proposal can or should survive the review process.

To accurately identify PSD policies, we have two choices:
- assume that PSDs will add the "psd=y" flag to their policies prior to
publication, or
- declare that the "NP" clause is the PSD indicator, meaning
(a) it indicates that the first child domain without an NP term is an
organizational domain, and that organization must pass an existence test to
verify registration.
(b) that the organizational domain is an upper bound for alignment.
(c) that the SP clause of the PSD's DMARC record applies to the
organization.

We can create a different term, such as "NX=disposition", to be used on
organizational DMARC records, with the interpretation that the FROM domain
must pass an existence test.

I think that separating the organizational existence test from the From
domain existence test is desirable.   The PSD non-existence test should not
be used to impose a From domain existence test on registered organizations.

Given John's concerns about getting PSDs to accurately publish the PSD
flag, using NP as our PSD indicator seems preferable, because it is already
deployed.

The existence of private registries means that we also need to be concerned
about a lower bound for relaxed alignment.   This must also be addressed as
part of the tree walks.

Doug

On Mon, Feb 21, 2022 at 1:07 PM John Levine <[email-masked]> wrote:

> they
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2022 18:45:09 -0500

>have the same org domain (kitterman.com).  I don't think what I'm proposing is 

It looked like the tree walk to find the policy domain was different from the
one to find the org domain.  If they're the same, that makes things simpler
and we now have to nail down exactly what that tree walk is: first record,
last record before a PSD?

This would be easier if we could count on PSDs to put psd=y in their records but
I fear it will be a long time until that happens reliably.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Feb 2022 09:57:22 +0100

On Mon 21/Feb/2022 23:55:56 +0100 Douglas Foster wrote:
> - assume that PSDs will add the "psd=y" flag to their policies prior to publication, or

I don't see why an org domain, or any domain, cannot specify NP.  To me, a non 
existing From: domain is such an obvious abuse indicator that could have been 
the default (as it actually has been, IIRC.)  Also, I see no meaningful NP but 
np=reject.

> (b) that the organizational domain is an upper bound for alignment.

Yes.

> (c) that the SP clause of the PSD's DMARC record applies to the organization.

To complicate, or perhaps to incentivize, the tree walk, we could consider 
inheritance rules.  For example, a From: subdomain could have a backward 
incompatible record like so:

_dmarc.sub.example.com IN TXT "v=DMARC1; rua+=mailto:[email-masked];"

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 22 Feb 2022 07:09:12 -0500

Thanks for responding.

on (c)
The idea of multiple inheritance points had some appeal for me, but I have
given up on the idea because of the compatibility problems it would
create.   We MUST find the correct organizational domain to correctly apply
relaxed alignment.   Having done that, we can also replicate the existing
inheritance rules.

on (a)
Non-existent organizations and non-existent FROM domains are very different
tests.    Relaxed alignment allows for the FROM domain to be non-existent
on legitimate messages, and mailers take advantage of that feature.    This
distinction was part of my long-running fixation on changing the NP clause
of the PSD experiment.    I think if you check your message logs, you will
be able to confirm this situation.

Since the PSD experiment was rolled out without the "psd=y" term, making a
clear distinction between NP and NX solves two problems.

Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Feb 2022 14:06:09 +0100

On Tue 22/Feb/2022 13:09:12 +0100 Douglas Foster wrote:
>> the default (as it actually has been, IIRC.)
>
> Non-existent organizations and non-existent FROM domains are very different tests.

It is the From: domain.  It can be nosub.havenbank.bank (whose parent domain 
exists) or credit-suisse.bank (which doesn't exist).  In either case, np= applies.

> Relaxed alignment allows for the FROM domain to be non-existent

That creates a new problem.  You'd need to restrict use of NP.  Domains that 
wish to use it, according to rfc9091, could no longer do so.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 22 Feb 2022 23:09:19 -0500

On Monday, February 21, 2022 6:45:09 PM EST John Levine wrote:
> >Today, if I send mail from 5322.From example.kitterman.com that is signed
> >by dkim.kitterman.com, if example.kitterman.com has a DMARC record, then
> >that would be the policy domain, but the message would meet the
> >requirement for relaxed alignment because both example.kitterman.com and
> >dkim.kitterman.com have the same org domain (kitterman.com).  I don't
> >think what I'm proposing is any different.
> 
> It looked like the tree walk to find the policy domain was different from
> the one to find the org domain.  If they're the same, that makes things
> simpler and we now have to nail down exactly what that tree walk is: first
> record, last record before a PSD?
> 
> This would be easier if we could count on PSDs to put psd=y in their records
> but I fear it will be a long time until that happens reliably.

The problem with last record before a psd=y record is you never know when you 
are done.

Currently you could have:

a.b.c.org.psd.com

'org' is the org domain.  In RFC 7489 terms it's PSL + 1, so org domain is 
org.psd.com.  If you tree walk up you'd check (skipping b.c.d.org.psd.com 
because you skip up to the one that's five long):

_dmarc.a.b.c.d.org.psd.com
_dmarc.c.d.org.psd.com
_dmarc.d.org.psd.com
_dmarc.org.psd.com
_dmarc.psd.com
_dmarc.com

Except in the rare case that _dmarc.psd.com has a psd=y record you have to go 
all the way to the top to know which is the last non-psd=y record.  If someone 
publishes records based on the RFC 7489 approach, only a.b.c.d.org.psd and 
org.psd's records are consulted, so there's no reason to publish for the 
intermediate domains unless they send mail too.  Going from found a DMARC 
record to didn't find a DMARC record doesn't tell you anything.  If you tree-
walk down the tree then you look up:

_dmarc.com
_dmarc.psd.com
_dmarc.org.psd.com

and you are done.  Admittedly this is just mostly an efficiency hack.  You can 
get the same result either way.  It does seem awkward to me to do all the 
lookups in order to find out when to stop.  I like walk up for policy and walk 
down for org domain determination, but it's not essential.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 23 Feb 2022 12:33:22 +0100

> _dmarc.a.b.c.d.org.psd.com

If you found psd=y at _dmarc.psd.com, then you don't need to lookup _dmarc.com.

Similarly, if you found org=y at _dmarc.org.psd.com, then you don't need to 
lookup _dmarc.psd.com.

> intermediate domains unless they send mail too.

Unless they have special needs, there's no reason to publish a record at 
a.b.c.d.org.psd.com either.  However, if they do publish a DMARC record, then 
determining the org domain is only needed for alignment.  If no identifiers end 
in .com, for example, there is no need to determine the org domain.

> Going from found a DMARC record to didn't find a DMARC record doesn't tell 
> you anything.  If you tree- walk down the tree then you look up: >
> _dmarc.com
> _dmarc.psd.com
> _dmarc.org.psd.com
> 

I don't follow this.  If _dmarc.psd.com has no psd=y, you cannot determine the 
org domain correctly.  Most often, walking downward you find the same records 
you found when walking upward.  If you cared to memorize them, the downward 
walk is pure thought.  You find no further info that way.

If you find no flags, you need to still consult the PSL.  It is good enough to 
avoid cross domain (mis)alignments.  I understand that this way one of the 
advantages of the tree walk —to get rid of the PSL— is lost.  However, the 
other advantage, to get something more accurate than the PSL, can still be met 
if we work out the flags well.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Wed, 23 Feb 2022 07:09:23 -0500

Ale, this response frustrates me.    We should be discussing non-existence
based on shared data, which is why I asked you to test it with your own
data.

I get legitimate non-existent From addresses every day.   They are ESP
mailings where the SMTP address is the ESP domain and the From address is
the client domain.    Obviously, legitimate but non-existent means that the
FROM address is a subdomain of the organizational domain.

The rules for relaxed alignment only require that messages have a DKIM
signature from somewhere in the organization.   ESP practice seems to only
require that the FROM address match the client organization, not that it
exactly matches the email account used to establish the account.  The
theory and the data converge on the same result - the FROM domain does not
need to exist.

Organization existence is a different matter.    Organizations MUST be
registered with a registrar, whether that is a PSO or  private registrar.
 We should not have needed a DMARC policy to enforce this rule, but
implementations do need a DMARC infrastructure before they can correctly
determine an organizational domain to be tested.   So it makes sense for us
to document this defense in our group, and it provides a feedback
mechanism for registrars.

A third type of non-existence is a non-existent public suffix, which can be
detected by a non-existent TLD.   A TLD can be tested for existence if it
participates in DNS SEC, because the RRSIG records prevent NXDOMAIN.    I
have asked whether all TLDs currently participate in DNS SEC, but no one
has answered and I certainly do not know for sure.  Without DNS SEC, we are
back to asking whether the TLD is absent from the PSL.

Doug Foster

---

From: Douglas Foster <[email-masked]>
Date: Wed, 23 Feb 2022 07:10:37 -0500

Do you propose that we ignore private registrars completely?

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Feb 2022 11:44:56 -0500

On Wednesday, February 23, 2022 6:33:22 AM EST Alessandro Vesely wrote:
> >> This would be easier if we could count on PSDs to put psd=y in their
> >> records but I fear it will be a long time until that happens reliably.
> > 
> > The problem with last record before a psd=y record is you never know when
> > you are done.
> > 

That's true, but I expect that to be the exception, not the typical case 
(discussed below).

> Similarly, if you found org=y at _dmarc.org.psd.com, then you don't need to

Since that's undefined, no.

> > Except in the rare case that _dmarc.psd.com has a psd=y record you have to
> > go all the way to the top to know which is the last non-psd=y record.  If
> > someone publishes records based on the RFC 7489 approach, only
> > a.b.c.d.org.psd and org.psd's records are consulted, so there's no reason
> > to publish for the intermediate domains unless they send mail too.
> 
> a.b.c.d.org.psd.com either.  However, if they do publish a DMARC record,
> then determining the org domain is only needed for alignment.  If no
> identifiers end in .com, for example, there is no need to determine the org
> domain.

I agree that records won't typically be needed at low levels within a single 
org, but the design needs to account for the possibility.  It's supported by 
RFC 7489, so I don't think we should introduce a gratuitous incompatibility.

I think for the specific cause of not even being in the same PSD, one might 
skip determining the ORG domain, but that would only be for efficiency.  The 
protocol shouldn't specify it.

> > and you are done.  Admittedly this is just mostly an efficiency hack.  You
> > can get the same result either way.  It does seem awkward to me to do all
> > the lookups in order to find out when to stop.  I like walk up for policy
> > and walk down for org domain determination, but it's not essential.
> 
> I don't follow this.  If _dmarc.psd.com has no psd=y, you cannot determine
> the org domain correctly.  Most often, walking downward you find the same
> records you found when walking upward.  If you cared to memorize them, the
> downward walk is pure thought.  You find no further info that way.

Yes.  You can.  As we have been discussing for nearly half a year.

If you did all the lookups on the walk up, that is correct.  The thing is, 
once you find a DMARC record (in this example at _dmarc.a.b.c.d.org.psd.com, 
there is no need for further lookups to determine policy.

As I said, walking down is only for efficiency.  You get to the same answer 
eventually either way, which is why I said I don't think it's essential.  In 
this example it saves you looking up dmarc.c.d.org.psd.com and 
_dmarc.d.org.psd.com.

> If you find no flags, you need to still consult the PSL.  It is good enough
> to avoid cross domain (mis)alignments.  I understand that this way one of
> the advantages of the tree walk —to get rid of the PSL— is lost.  However,
> the other advantage, to get something more accurate than the PSL, can still
> be met if we work out the flags well.

No.  I think that is entirely incorrect.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Feb 2022 11:46:31 -0500

No.  Please explain why you think I'm proposing that?  I'm reasonably confident 
I haven't.

Scott k

On Wednesday, February 23, 2022 7:10:37 AM EST Douglas Foster wrote:
> > > >Today, if I send mail from 5322.From example.kitterman.com that is
> > 
> > signed
> > 
> > > >by dkim.kitterman.com, if example.kitterman.com has a DMARC record,
> > 
> > then
> > 
> > > >requirement for relaxed alignment because both example.kitterman.com
> > 
> > and
> > 
> > records
> > you
> > can

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2022 12:05:43 -0500

It appears that Scott Kitterman  <[email-masked]> said:
>> record, last record before a PSD? ...

>down for org domain determination, but it's not essential.

Hold it, this is a very incompatible change from 7489.

As it stands now, the policy domain is either the domain itself or the org domain.

You appear to be proposing that the policy domain might be the domain itself, or
the org domain, or some other domain in between if it has a DMARC record.  If that's
not the proposal, can you clarify?

I also realize that walking down doesn't save any work since there may be more than
one PSD.  For example [email-masked]

 uk psd
 ac psd
 camb DMARC and org
 cst DMARC

If you walk down, and you stop at "uk" you'll get the wrong answer.
You have to keep going because you don't know whether there might be
another PSD. If you walk up you can always stop at the first PSD and
get the right answer.

If we agree to jump up to the 5th label for longer names, neither
direction will do more than five lookups, but walking up is a lot
easier to explain.

If there is more than one DMARC record between the original name and
the top or a PSD, there is still the question of when to use the first
(lowest) and when to use the last. My proposal is that we always use
the first, for policy, for relaxed alignment, for what we call an org
domain, for everything else. It's easy to explain, and it makes the
foo.us.com hack less likely.

R's,
JOhn

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Feb 2022 12:13:51 -0500

On Wednesday, February 23, 2022 12:05:43 PM EST John Levine wrote:
> >lookups in order to find out when to stop.  I like walk up for policy and
> >walk down for org domain determination, but it's not essential.
> 
> You appear to be proposing that the policy domain might be the domain
> itself, or the org domain, or some other domain in between if it has a
> DMARC record.  If that's not the proposal, can you clarify?
> 
> I also realize that walking down doesn't save any work since there may be
> more than one PSD.  For example [email-masked]
> 
>  uk psd
>  ac psd
>  camb DMARC and org
>  cst DMARC
> 

More than one PSD is a good point.  Never mind about walking down.

Leaving that aside, then I think it's:

1.  Lookup DMARC record for the 5322.From domain.  If found, that's the 
policy.

2.  Walk up from up to 5 levels in the DNS hierarchy and the last (shortest) 
non-PSD DMARC record you find is the org.

I think that matches the RFC 7489 discovery approach, just not using PSL.  Is 
that right?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2022 13:25:50 -0500

>I think that matches the RFC 7489 discovery approach, just not using PSL.  Is 

I prefer the first (longest) but could live with the last if people think that
will in practice be less surprising.  I do worry about foo.us.com vs bar.us.com.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Feb 2022 13:55:35 -0500

On Wednesday, February 23, 2022 1:25:50 PM EST John Levine wrote:
> >2.  Walk up from up to 5 levels in the DNS hierarchy and the last
> >(shortest) non-PSD DMARC record you find is the org.
> >
> >I think that matches the RFC 7489 discovery approach, just not using PSL. 
> >Is that right?
> 
> I prefer the first (longest) but could live with the last if people think
> that will in practice be less surprising.  I do worry about foo.us.com vs
> bar.us.com.

I think it will (less surprising).  Currently if you have a.b.bar.us.com and 
"a" and "b" need different policies you can just publish them.  If you stop at 
the first one, then b.bar.us.com would be identified as the org domain for 
a.b.bar.us.com vice bar.us.com.

This could be problematic.  The RFC 7489 definition of relaxed alignment says 
that the From org domain and the DKIM/SPF org domain have to be the same to be 
aligned.

DKIM (7489 3.1.1):

>    In relaxed mode, the Organizational Domains of both the [DKIM]-
>    authenticated signing domain (taken from the value of the "d=" tag in
>    the signature) and that of the RFC5322.From domain must be equal if
>    the identifiers are to be considered aligned.

SPF (7489 3.1.2):

>    In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
>    domain must have the same Organizational Domain.

A specific example:

A business (example.com) uses subdomains for particular business units and 
allows them to run their own email infrastructure if needed.  One particular 
business unit (bu.example.com) uses a large number of third party providers 
with a dedicated mail from for each to avoid restrictions associated with SPF 
DNS lookup limits.  It sends mail from (among others) ext1.bu.example.com and 
ext2.bu.example.com with from and signing domain of bu.example.com.  Because 
this business unit has decided to accept the risks associated with a DMARC 
reject policy and the company as a whole has not, it publishes its own DMARC 
record at _dmarc.bu.example.com.  Of course, .com is in the PSL, so the org 
domain is example.com under RFC 7489 rules.

In this example, under RFC 7489 rules, ext1.bu.example.com, 
ext2.bu.example.com, and bu.example.com all meet the requirements for relaxed 
alignment because the org domain for all three is example.com.

Using the proposed tree walk approach, it matters if you take the first DMARC 
record or the last one.

ext1: no dmarc
bu: dmarc, p=reject, sp=reject
example: dmarc, p=none, sp=none
com: no dmarc

If you walk up the tree and take the first DMARC record you hit, then the org 
domain for ext1.bu.example.com is bu.example.com and the org domain for 
bu.example.com is example.com.  They don't match, so there is no alignment.

If you take the last non-PSD DMARC record then the org domain for 
ext1.bu.example.com is example.com and the org domain for bu.example.com is 
example.com and they meet the requirements for relaxed alignment.

This may seem convoluted, but I have seen pretty much this exact setup in use 
by large organizations.

We could fix this by changing the definition of relaxed alignment to be is the 
same or one is a subdomain of the other, but I think it's better to take the 
last DMARC record and leave the definition as is.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2022 16:45:35 -0500

>a.b.bar.us.com vice bar.us.com.

I understand, but the question is whether anyone actually does that.  It is my
impression that our argument is largely hypothetical because it is rare to have
stacked DMARC records like that.

>last DMARC record and leave the definition as is.

Laura says she's seen sibling or maybe great aunt alignment.  I really wish we
could get some stats about what kinds of relaxed alignment people actually use,
because I would prefer to avoid evil sibling alignment if we can do that without
breaking significant existing use.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Feb 2022 16:58:08 -0500

On Wednesday, February 23, 2022 4:45:35 PM EST John Levine wrote:
> >I think it will (less surprising).  Currently if you have a.b.bar.us.com
> >and "a" and "b" need different policies you can just publish them.  If you
> >stop at the first one, then b.bar.us.com would be identified as the org
> >domain for a.b.bar.us.com vice bar.us.com.
> 
> I understand, but the question is whether anyone actually does that.  It is
> my impression that our argument is largely hypothetical because it is rare
> to have stacked DMARC records like that.

I've seen it done.  Unfortunately I can't go into specifics.  I suspect it is 
rare, but when it happens it's pretty essential.

> >We could fix this by changing the definition of relaxed alignment to be is
> >the same or one is a subdomain of the other, but I think it's better to
> >take the last DMARC record and leave the definition as is.
> 
> Laura says she's seen sibling or maybe great aunt alignment.  I really wish
> we could get some stats about what kinds of relaxed alignment people
> actually use, because I would prefer to avoid evil sibling alignment if we
> can do that without breaking significant existing use.

The problem with statistics is that leads you not to care about the rare 
entities for which the functionality is absolutely essential.

If we did first match, but allowed for relaxed alignment for org domains also 
when one is a subdomain of the other, I don't think that helps with the evil 
sibling problem.

I think this is significant enough that we don't want to break it.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2022 19:20:39 -0500

>when one is a subdomain of the other, I don't think that helps with the evil 

I think that would largely solve it.  I am worried about foo.us.com pretending
to be bar.us.com since they have no relation to each other.  I am much less
worried about foo.us.com pretending to be us.com or vice versa since they
have a direct business relationship and so have recourse against each other.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 23 Feb 2022 20:16:24 -0500

>have a direct business relationship and so have recourse against each other.

Hm, no, if us.com has a regular non-PSD DMARC record, bar.us.com is
aligned with foo.us.com. If we do first match, it's not aligned with
mail.foo.us.com if there's also a DMARC record at foo.us.com, but it
feels like we're getting into the weeds.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 24 Feb 2022 09:36:18 +0100

On Wed 23/Feb/2022 19:55:35 +0100 Scott Kitterman wrote:
>>>1.  Lookup DMARC record for the 5322.From domain.  If found, that's the policy.
>>>

It looks right, except for non-flagged PSDs.

However, what if you find no DMARC record at step 1?  For compatibility with 
RFC 7489, I guess you imply that the policy is taken from the org domain.

> example: dmarc, p=none, sp=none

I like this example.  Let's leave the alignment question for a moment, and 
consider policy.  Mail from [email-masked], according to the plan 
above, goes with p=none.  That agrees with the PSL.

Can we be more accurate than the PSL?  Yes, we can, since we read the record at 
bu.example.com.

> example.com and they meet the requirements for relaxed alignment.

Allowing bu.example.com to publish org=y would make both identifiers aligned to 
bu.example.com.  However, we could also devise flags so as to override the 
policy but keep the alignment.

I don't know why you dismiss possible enhancements as if psd=y were already 
standard.  Of course, users of legacy software won't deploy new enhancements. 
That is, org=y would initially not be honored by the majority of receiving 
servers.  That's normal.  OTOH, a change which implies issuing more DNS queries 
just to get a slightly worse quality than the PSL —due to missing psd=y flags— 
is not really so attractive.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Thu, 24 Feb 2022 06:40:00 -0500

We are proposing to replace an information-rich PSL resource, with DNS
lookups that currently have no explicit information about organization
boundaries.    The good news is that we can get pretty close to
PSL-equivalent results with the existing DNS and some heuristics.   But
certainty is always preferable to heuristics, which is why we need a flag
for registrar entities (organization boundary below) and a flag for
organization domains (organization boundary above).  DMARC has always been
about empowering domain owners and evaluators to work together to improve
trust.    Using the tree walk instead of the PSL puts those participants
back in control of their relationship.
In the near term, the PSL will have an information advantage, especially
for private registries.   Consequently, existing implementations will
continue to consult it.   But for the long term, registrars and their
registrants are the best source for information about organization
boundaries, and they will become the official source if we give them the
tools to do so.

On the other hand, to build a complete solution around the PSL, we would
have to document all of the information flows between the PSL entity and
the registrar entities, define the integrity assurance processes for that
communication, and eliminate the ambiguity caused by having more than one
list.   It seems clear that we do not want to undertake that effort.  We
also have the nagging fear that at some point the PSL will become
unreliable or unavailable for our purposes.

So we define a new algorithm that eliminates the PSL using the
best-available heuristics, treat the old algorithm as valid but deprecated,
and let the industry pick the long-term winner.

Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Feb 2022 09:04:45 -0500

On Wednesday, February 23, 2022 8:16:24 PM EST John Levine wrote:
> >>If we did first match, but allowed for relaxed alignment for org domains
> >>also when one is a subdomain of the other, I don't think that helps with
> >>the evil sibling problem.
> >
> >I think that would largely solve it.  I am worried about foo.us.com
> >pretending to be bar.us.com since they have no relation to each other.  I
> >am much less worried about foo.us.com pretending to be us.com or vice
> >versa since they have a direct business relationship and so have recourse
> >against each other.

We are, but I think it's needed.  I think we are in reasonably good shape for 
backward compatibility.  I still have a preference for org is last non-PSD and 
not changing the alignment definition over org is first and changing the 
alignment definition.

Here are the advantages I see of last non-PSD:

Does not requiring changing the alignment definition.  I think this is a big 
deal.  Alignment is something that affects code.  If we change from PSL to last 
non-PSD we are changing the method for determining an input to the DMARC 
evaluation process, not the actual process.  I think that's good.  Also, it's 
easier to assess the effects of the change.  It's isolated to org domain 
determination.  If we also change the alignment rules it's a more complicated 
assessment that we are less likely to get completely correct.

Modulo PSL errors and non-PSD DMARC records published by PSDs it produces the 
same results as the RFC 7489 design (more about this later).

DMARC records published based on RFC 7489 do not need to be changed.

I don't see any real disadvantages.  Neither solves the evil/incompetent PSD 
case where the PSD publishes a regular DMARC record and allows one customer to 
impersonate another.

In that regard, I think there is a point to the suggestions people have been 
making about org=y.  If we could give domain owners a method to specify 
there's nothing above for org we could give them a defense in this case other 
than switch to a new provider.  I don't think org=y is needed though.  We 
could use psd=n for this and not need yet another new tag.

If we did this, then we would specify that the upward tree walk terminates if 
a record has psd=n in it.  That would allow a defense against the evil/
incompetent PSD and their scheming other customer.

This is a general discussion of the concept, not a full definition.  If this 
seems reasonable to people, I can write it up more precisely.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Feb 2022 11:45:18 -0500

>not changing the alignment definition over org is first and changing the 

Having further pondered evil great aunts (not a recipe for a good night's
sleep) I am coming around to your point of view.

You're only subject to the evil sibling attack if your org domain does not
publish a DMARC record and your PSD does publish one without psd=y.  There
are some PSDs that do that but trying to get their attention to fix it seems
a whole lot easier than trying to add org=y to millions of ordinary domains,
particularly since we have contact with many PSDs via ICANN.

>incompetent PSD and their scheming other customer.

That seems reasonable.  It doesn't make things worse for existing users.

So I think this is the plan:

1.  Take your domain, chop it to the last five labels if it's longer than that.

2.  Walk up the tree starting at the original domain, and at each level look for a DMARC record.

3.  If you find one with a psd flag, stop.

4.  If you find one without a psd flag, remember it and keep going.

5.  If you reach the root, stop.

If you found a record with psd=n, that is the org domain.

If you found a record with psd=y, the label below it is the org domain.

Otherwise the org domain is the last DMARC record you found.

The rest doesn't change:

The policy domain is the original domain if it had a DMARC record,
otherwise the org domain. The org domain might not have a DMARC
record. Relaxed alignment still means that two names have the same org
domain.

If you found no records at all, there is no org domain and no policy but so what, there's nothing to do.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Feb 2022 12:13:42 -0500

On Thursday, February 24, 2022 11:45:18 AM EST John Levine wrote:
> >We are, but I think it's needed.  I think we are in reasonably good shape
> >for backward compatibility.  I still have a preference for org is last
> >non-PSD and not changing the alignment definition over org is first and
> >changing the alignment definition.
> 
> a whole lot easier than trying to add org=y to millions of ordinary
> domains, particularly since we have contact with many PSDs via ICANN.
> 
> >If we did this, then we would specify that the upward tree walk terminates
> >if a record has psd=n in it.  That would allow a defense against the evil/

Yes, with the minor proviso that is it's longer than 5, you would start with 
the exact match and then jump to 5, but that's a detail.

Unless someone objects, I'll start working on words so we can review the 
details.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Feb 2022 12:15:57 -0500

On Thursday, February 24, 2022 3:36:18 AM EST Alessandro Vesely wrote:
> > and "a" and "b" need different policies you can just publish them.  If
> > you stop at the first one, then b.bar.us.com would be identified as the
> > org domain for a.b.bar.us.com vice bar.us.com.
> > 
> > This could be problematic.  The RFC 7489 definition of relaxed alignment
> > says that the From org domain and the DKIM/SPF org domain have to be the
> > same to be aligned.
> > 
> > A specific example:
> > 
> > allows them to run their own email infrastructure if needed.  One
> > particular business unit (bu.example.com) uses a large number of third
> > party providers with a dedicated mail from for each to avoid restrictions
> > associated with SPF DNS lookup limits.  It sends mail from (among others)
> > ext1.bu.example.com and ext2.bu.example.com with from and signing domain
> > of bu.example.com.  Because this business unit has decided to accept the
> > risks associated with a DMARC reject policy and the company as a whole
> > has not, it publishes its own DMARC record at _dmarc.bu.example.com.  Of
> > course, .com is in the PSL, so the org domain is example.com under RFC
> > 7489 rules.
> > 
> > ext2.bu.example.com, and bu.example.com all meet the requirements for
> > relaxed alignment because the org domain for all three is example.com.
> > 
> > Using the proposed tree walk approach, it matters if you take the first
> > DMARC record or the last one.
> > 
> > ext1: no dmarc
> Can we be more accurate than the PSL?  Yes, we can, since we read the record
> at bu.example.com.
> 
> > If you walk up the tree and take the first DMARC record you hit, then the
> > org domain for ext1.bu.example.com is bu.example.com and the org domain
> > for bu.example.com is example.com.  They don't match, so there is no
> > alignment.
> > 
> Allowing bu.example.com to publish org=y would make both identifiers aligned
> to bu.example.com.  However, we could also devise flags so as to override
> the policy but keep the alignment.
> 
> standard.  Of course, users of legacy software won't deploy new
> enhancements. That is, org=y would initially not be honored by the majority
> of receiving servers.  That's normal.  OTOH, a change which implies issuing
> more DNS queries just to get a slightly worse quality than the PSL —due to
> missing psd=y flags— is not really so attractive.

I think using psd=n, so we don't need to define yet another new tag, as 
discussed in another branch of this thread, accomplishes what you are 
suggesting.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 24 Feb 2022 12:46:13 -0500

>the exact match and then jump to 5, but that's a detail.

Right, that's what I meant.

There may be a few other corner cases, e.g., if the original domain
had psd=y, I think you ignore the psd flag since there's no lower
domain that could be the org domain, or maybe perversely pretend it
was psd=n so it is its own org domain. That allows the PSDs that have
mail servers to continue to work no worse than now.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Feb 2022 12:47:23 -0500

On Thursday, February 24, 2022 12:46:13 PM EST John Levine wrote:
> >> If you found no records at all, there is no org domain and no policy but
> >> so
> >> what, there's nothing to do.
> >
> >Yes, with the minor proviso that is it's longer than 5, you would start
> >with the exact match and then jump to 5, but that's a detail.
> 

Yes.  That's another one.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 25 Feb 2022 11:41:51 +0100

> discussed in another branch of this thread, accomplishes what you are

I would prefer role=X, with enumerated values for X.  It is more explicit.  I 
don't think we'd make grand savings by scrimping on symbols.

Possible values for X:

psd:  the equivalent of psd=y,

org:  the equivalent of psd=n,

both:  for domains like us.com,

none:  for a domain that wants to just establish its policy and feedback 
reporting but explicitly denies to be the org domain.  (I previously suggested 
role=sub for this case, but role=none is more dandy as a pendant to role=both. 
  Perhaps native English speakers can come out with better terms...)

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Fri, 25 Feb 2022 06:45:55 -0500

+1
I thought "psd=n" was awkward, and at risk of being misapplied.
Ale's "role=(psd,org,both,none)" syntax is intuitive.

Doug Foster

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 25 Feb 2022 10:20:02 -0500

Once we have the process documented and agreed, I think changing the name if 
there's where the consensus is would be trivial to do.  I'd suggest we come 
back to this a bit later.

I would like to get it nailed down so we can pursue early assignment of 
whatever it ends up being to facilitate testing and experimentation.

Scott K

On Friday, February 25, 2022 6:45:55 AM EST Douglas Foster wrote:
> > >> I don't know why you dismiss possible enhancements as if psd=y were
> > 
> > already
> > 
> > >> enhancements. That is, org=y would initially not be honored by the
> > 
> > majority
> > 
> > >> of receiving servers.  That's normal.  OTOH, a change which implies
> > 
> > issuing
> > 
> > >> more DNS queries just to get a slightly worse quality than the PSL —due
> > 
> > to
> >

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2022 15:51:21 -0500

>don't think we'd make grand savings by scrimping on symbols.

No.  This just adds more useless complexity that is unlikely to get implemented.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Feb 2022 11:00:53 +0100

> No.  This just adds more useless complexity that is unlikely to get implemented.

While composing a DMARC record, setting role=org seems more likely than psd=n.

Moreover, documenting that PSDs MUST set psd=y while psd=n has to be used with 
care because its meaning is not quite just the opposite of psd=y as it would 
seem is going to sound a bit convoluted.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 26 Feb 2022 12:14:30 -0500

> While composing a DMARC record, setting role=org seems more likely than psd=n.

For the umpteenth time, the goal here is to be as compatible as possible 
with the way that DMARC works now.  An important part of that is not to 
ask people to change their existing DMARC records because we know that 
most of them won't.

The normal case, like 99.99% of the time, is that the PSD does not publish 
a DMARC record at all.  The org domain has a DMARC record if it sends mail 
or its subdomains use relaxed alignment.  The way Scott and I propose to 
do a tree walk, that will get the same alignment as now with no changes to 
the DMARC record.  That includes millions, maybe tens of millions of 
domains.

A few PSDs publish DMARC records, either because they have a policy about 
their registrants' mail, or because the PSD itself has an MX.  We want 
them to add psd=y.  That includes 52 domains.  (I counted them.)

As an extreme corner case, if you are registered under a PSD that 
publishes a DMARC record  but erroneously doesn't include psd=y, you can 
use psd=n as a kludge to prevent evil sibling alignment.  That currently 
includes about 45 of those 52 domains, but I think we can get it close to 
zero because we have contacts at many of them.

I'm finding it hard to understand the advantage of a scheme that requires 
millions of DMARC records to change rather than one that changes 52.

Regards,

---

From: Douglas Foster <[email-masked]>
Date: Sat, 26 Feb 2022 18:19:25 -0500

It helps to know the assumptions that have led John to such incorrect
conclusions.

When moving from a PSL to the DNS, the primary obstacle has always been
missing information.    Therefore, one goal of this project is exactly to
induce people to update their DMARC records, to supply information that is
currently missing.   We are attempting to do what DBOUND tried and failed
to do - insert boundary information into DNS using information published by
registrars and the registered organizations.

Ale has correctly assessed that in the new design, a DMARC record can play
one of four roles.   Evaluators must code for all four of these
possibilities, regardless of how many token values we define.   With four
roles, we have five information states:  explicit indicators for Registrar,
Org, Both, None, and the fallback result of NULL.  Anyone who has ever
tried to interpret incomplete data knows that a null result is different
from a default value, and that explicit data is always preferable to
guessing a default value to use when confronted with null.

Evaluators will be required to cope with a NULL result by assigning those
policy records to one of the four roles.   The assigned role will be
context-sensitive, which is one of the reasons that NULL and NONE are not
equivalent.    Fortunately, we expect that the correct default can be
applied most of the time.   However, the proposal to project five states
into three, using "psd=(y,n,null)", is an unforced error that cannot be
justified.

There is also a huge communication error introduced by assuming that
"psd=n" will be reliably configured to mean "org=y".    There are a
relatively small number of registrars who will be publishing DMARC
information, against millions of organizations that are publishing, or will
publish, DMARC policies.   We need the language optimized to ensure that
organizations publish their flag data correctly.

We also have a nomenclature problem connected to the choice of "psd=value"
as a token.   We have recognized that there are public registrars and
private registrars, and that DMARC must cope with both types.   Private
registrars are not PSOs and we should not bless them with a title that they
do not deserve.   Our document needs to be updated to reflect this
reality.   Throughout the text, we should have "Registrars", and
"Registration Domains", not PSOs and PSDs, except for introductory material
where we explain the difference between the two and its implications for
tree walk.   The registrar role should be indicated with "REG", not with
"PSD".

Doug Foster

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 26 Feb 2022 19:41:03 -0500

Which has nothing to do with what is a policy domain, an org domain, or how 
not to break existing DMARC.  As I suggested earlier, we can decide what to 
call the tags independent of the policy lookup and org domain determination.  
I think we have those things resolved, modulo me having time to write it up in 
detail.  Perhaps you could start a new thread on this topic.

Scott K

On Saturday, February 26, 2022 6:19:25 PM EST Douglas Foster wrote:
> > >> No.  This just adds more useless complexity that is unlikely to get
> > 
> > implemented.
> > 
> > > While composing a DMARC record, setting role=org seems more likely than
> > 
> > psd=n.
> >

---

From: "John Levine" <[email-masked]>
Date: 26 Feb 2022 20:28:30 -0500

>> missing information.

Sorry, but no, that had nothing to do with it.  You can review the mailing
list archives to see what the advantages of a tree walk over the PSL are.

>> Therefore, one goal of this project is exactly to
>> induce people to update their DMARC records, ...

That is completely backwards. The goal was to get more reliable
results keeping in mind that in practice, hardly anyone will change
their DMARC records.

The rest of the message was no more accurate but I'll stop here.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 27 Feb 2022 11:25:21 +0100

On Sat 26/Feb/2022 18:14:30 +0100 John R Levine wrote:
> For the umpteenth time, the goal here is to be as compatible as possible with 
> the way that DMARC works now.  An important part of that is not to ask people 
> to change their existing DMARC records because we know that most of them won't.

100% agreed.

> The normal case, like 99.99% of the time, is that the PSD does not publish a 
> DMARC record at all.  The org domain has a DMARC record if it sends mail or its 
> subdomains use relaxed alignment.  The way Scott and I propose to do a tree 
> walk, that will get the same alignment as now with no changes to the DMARC 
> record.  That includes millions, maybe tens of millions of domains.
> 
> A few PSDs publish DMARC records, either because they have a policy about their 
> registrants' mail, or because the PSD itself has an MX.  We want them to add 
> psd=y.  That includes 52 domains.  (I counted them.)
> 
> As an extreme corner case, if you are registered under a PSD that publishes a 
> DMARC record  but erroneously doesn't include psd=y, you can use psd=n as a 
> kludge to prevent evil sibling alignment.  That currently includes about 45 of 
> those 52 domains, but I think we can get it close to zero because we have 
> contacts at many of them.

That's a Good Thing.

> millions of DMARC records to change rather than one that changes 52.

I never proposed such a massive operation.

OTOH, those ~8 million DMARC domains are a small fraction of the 70+ million 
domains having SPF records.  I think we can expect DMARC domains to grow.

In some cases, a domain can induce correct alignment assessments by asking for 
inclusion in the private domains section of the PSL, like us.com.  I'd figure 
most of those PSL additions were driven by cookie alignment issues.  However, 
some of them could also have been motivated by DMARC considerations, who knows?

Setting a role=org flag would be akin to updating the PSL.  Not something that 
every domain does every day.  Perhaps nobody will ever do it.  (I found no 
DMARC record in the few subdomains of us.com I checked.)  Yet, the possibility 
to have role=org looks to me better than using a false boolean for the same task.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2022 12:43:10 -0500

It appears that Alessandro Vesely  <[email-masked]> said:
>every domain does every day.  Perhaps nobody will ever do it. ...

Assuming you expect role=org to mean the same as what Scott and I mean by psd=n,
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 and I know what it
means, but it'd be just a matter of time before someone decided it was mandatory
because it's "more secure".

It is a good thing that psd=y and psd=n look obscure because they *are* obscure
with psd=n being doubly obscure.  It is such an extreme corner case that it's
probably not worth the effort to add it to the spec, with our efforts better spent
getting the 52 DMARC records at PSLs updated.

R's,
John

---

From: Douglas Foster <[email-masked]>
Date: Sun, 27 Feb 2022 16:17:04 -0500

If you are determined to submit your own text, perhaps you could read and
acknowledge the draft that has already been posted.

---

From: Douglas Foster <[email-masked]>
Date: Sun, 27 Feb 2022 16:18:58 -0500

Role=orgtop is probably a better term for hindering incorrect entries.
 Psd=n is not.   A boolean token is not.

---

From: Douglas Foster <[email-masked]>
Date: Sun, 27 Feb 2022 16:41:02 -0500

It is curious that only a few days ago, John was arguing that there would
be no intermediate policy records, so the first one encountered would have
to be the organizational domain.   Today, he is worried that all of those
intermediate policy records will be mis-labeled.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 27 Feb 2022 16:49:15 -0500

On what basis do you assert I haven't read things?  It's interesting that you 
know better than I what I'm going to do.  It's particularly amazing since I 
haven't had the time to do it yet.

Scott K

On Sunday, February 27, 2022 4:17:04 PM EST Douglas Foster wrote:
> > > induce people to update their DMARC records, to supply information that
> > 
> > is
> > 
> > > to do - insert boundary information into DNS using information published
> > 
> > by
> > 
> > > Ale has correctly assessed that in the new design, a DMARC record can
> > 
> > play
> > 
> > > roles, we have five information states:  explicit indicators for
> > 
> > Registrar,
> > 
> > > information, against millions of organizations that are publishing, or
> > 
> > will
> > 
> > > We also have a nomenclature problem connected to the choice of
> > 
> > "psd=value"
> > 
> > > registrars are not PSOs and we should not bless them with a title that
> > 
> > they
> > 
> > > "Registration Domains", not PSOs and PSDs, except for introductory
> > 
> > material
> > 
> > > > > While composing a DMARC record, setting role=org seems more likely
> > 
> > than
> > 
> > > > psd=n.
> > > > 
> > > > For the umpteenth time, the goal here is to be as compatible as
> > 
> > possible
> > 
> > > > The normal case, like 99.99% of the time, is that the PSD does not
> > 
> > publish
> > 
> > > > a DMARC record at all.  The org domain has a DMARC record if it sends
> > 
> > mail
> > 
> > > > or its subdomains use relaxed alignment.  The way Scott and I propose
> > 
> > to
> > 
> > > > do a tree walk, that will get the same alignment as now with no
> > 
> > changes to
> > 
> > > > A few PSDs publish DMARC records, either because they have a policy
> > 
> > about
> > 
> > > > publishes a DMARC record  but erroneously doesn't include psd=y, you
> > 
> > can
> > 
> > > > use psd=n as a kludge to prevent evil sibling alignment.  That
> > 
> > currently
> > 
> > > > includes about 45 of those 52 domains, but I think we can get it close
> > 
> > to
> > 
> > > > I'm finding it hard to understand the advantage of a scheme that
> > 
> > requires
> > 
> > > > Please consider the environment before reading this e-mail.
> > 
> > https://jl.ly
> >

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 28 Feb 2022 20:19:36 +0100

> Assuming you expect role=org to mean the same as what Scott and I mean by psd=n,

Correct.

> something that has to be in every org domain's record.

You're welcome to suggest better names.

> You and I know what it means, but it'd be just a matter of time before
> someone decided it was mandatory because it's "more secure". >
> with psd=n being doubly obscure.

I see, a case of security through obscurity?

> It is such an extreme corner case that it's probably not worth the effort to 
> add it to the spec, with our efforts better spent getting the 52 DMARC 
> records at PSLs updated.

Hm...  However small, it's the only quality gain we can expect by switching to 
tree walk.  Roughly, I think it could grow to the size of the PSL private 
domains section, no?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 28 Feb 2022 15:03:37 -0500

>> 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.
>

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,