Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-06.txt

From: Scott Kitterman <[email-masked]>
Date: Sat, 02 Apr 2022 19:29:50 -0400

Before we picked 5, we looked and that's sufficient to capture all the 
boundaries.  It's not a problem.  This was discussed on the list, I don't 
recall when.

Scott K

On Tuesday, March 22, 2022 9:55:56 PM EDT Douglas Foster wrote:
> Suppose a FROM address domain has the lower-bound of 5 segments, and that a
> verified DKIM signature exists using a child domain somewhere below that,
> perhaps with 7 segments.
> 
> Are the names automatically considered to be aligned, without a tree walk,
> because a private registry boundary will not occur below level 5?  Or
> should a scope-limited tree walk be performed between the child domain and
> the FROM domain to be sure that no boundary exists?
> 
> Doug
> 
> On Mon, Mar 21, 2022 at 4:50 PM <[email-masked]> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Domain-based Message Authentication,
> > Reporting & Conformance WG of the IETF.
> > 
> >         Title           : Domain-based Message Authentication, Reporting,
> > 
> > and Conformance (DMARC)
> > 
> >         Authors         : Todd M. Herr
> >         
> >                           John Levine
> >         
> >         Filename        : draft-ietf-dmarc-dmarcbis-06.txt
> >         Pages           : 62
> >         Date            : 2022-03-21
> > 
> > Abstract:
> >    This document describes the Domain-based Message Authentication,
> >    Reporting, and Conformance (DMARC) protocol.
> >    
> >    DMARC permits the owner of an email author's domain name to enable
> >    verification of the domain's use, to indicate the Domain Owner's or
> >    Public Suffix Operator's message handling preference regarding failed
> >    verification, and to request reports about use of the domain name.
> >    Mail receiving organizations can use this information when evaluating
> >    handling choices for incoming mail.
> >    
> >    This document obsoletes RFC 7489.
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
> > 
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-06.html
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-06
> > 
> > Internet-Drafts are also available by rsync at rsync.ietf.org:
> > :internet-drafts
> > 
> > _______________________________________________
> > dmarc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dmarc

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 02 Apr 2022 19:31:57 -0400

I think you are making far too much of this.  I've been implementing this as 
we go and it's pretty trivial.

Scott K

On Tuesday, March 22, 2022 10:27:37 PM EDT Douglas Foster wrote:
> The response below went out prematurely and incomplete, but I hope you can
> see where we I was going.   We have an ever-changing algorithm as we try to
> do a desk analysis of the problem.
> 
> One of my purposes for the outline was to see how many indicators we will
> need, by identifying what actions we would like to trigger based on those
> indicators, as well as clearly defining how we cope with the expected
> absence of indicators within each situation.
> 
> Trying to implement a specification is the best way to learn whether a
> specification provides a developer with sufficient guidance to produce the
> intended result.   In our case, we need a specification which provides
> sufficient information to many developers.   That is a tall order.
> 
> Doug
> 
> On Tue, Mar 22, 2022 at 9:40 PM Douglas Foster <
> 
> [email-masked]> wrote:
> > No, I think the RFC 7489 algorithm is much simpler than this one.
> > John was adamant that we only needed one indicator.  Then he conceded that
> > we need two.  Now he thinks we need three.  Ale and I said early on that
> > we
> > thought we needed four.
> > 
> > On Tue, Mar 22, 2022 at 7:47 AM Scott Kitterman <[email-masked]>
> > 
> > wrote:
> >> I gather then that your claim is that RFC 7489 isn't implementable.  Is
> >> that right?
> >> 
> >> Scott K
> >> 
> >> On March 22, 2022 11:11:40 AM UTC, Douglas Foster <
> >> 
> >> [email-masked]> wrote:
> >> >We need an algorithm with enough detail to ensure that it can be
> >> >implemented consistently, something closer to the RFC for SPF rather
> >> >than
> >> >RFC 7489.
> >> >
> >> >For example, it is only when you get into the weeds do you discover that
> >> >error handling for the primary walk needs to be different than error
> >> >handling for the secondary walk, and that this has security
> >> >implications.
> >> >
> >> > A policy error on the secondary walk MUST be ignored, rather than
> >> >
> >> >triggering PERMERROR.  Otherwise an attacker could create a domain with
> >> 
> >> an
> >> 
> >> >invalid DMARC policy, then sign an impersonating message with that
> >> 
> >> domain,
> >> 
> >> >causing the evaluator to conclude PERMERROR instead of REJECT, defeating
> >> >the domain owner policy.
> >> >
> >> >We need to have though through the implementation issues with as much
> >> 
> >> care
> >> 
> >> >as will be needed by developers.    This is no small feat.  I have
> >> 
> >> already
> >> 
> >> >thought of a few refinements since last night.  We probably cannot
> >> 
> >> succeed
> >> 
> >> >without a  reference configuration.
> >> >
> >> >I don't have any problem with the tree walks as a replacement for the
> >> 
> >> PSL.
> >> 
> >> > But I don't think we are close to a usable document because it is
> >> > simply
> >> >
> >> >too vague.
> >> >
> >> >Doug
> >> >
> >> >
> >> >On Tue, Mar 22, 2022 at 12:16 AM Scott Kitterman <[email-masked]>
> >> >
> >> >wrote:
> >> >> Doug,
> >> >> 
> >> >> I think you are mistaken.  The Organizational Domain is what is used
> >> >> to
> >> >> test alignment.  If you have suggested changes from what's in
> >> 
> >> DMARCbis06, I
> >> 
> >> >> think it would be easier if you made specific recommended changes.
> >> >> 
> >> >> Also, the level of detail in the current draft is very similar to what
> >> 
> >> is
> >> 
> >> >> in RFC 7489.  If you think we need a more detailed exposition than
> >> 
> >> there is
> >> 
> >> >> in the existing DMARC spec, please explain what current issues you are
> >> >> seeing that you are trying to solve.
> >> >> 
> >> >> I find it very difficult to relate what is in your email to the text
> >> >> in
> >> >> the draft.
> >> >> 
> >> >> Scott K
> >> >> 
> >> >> On March 22, 2022 3:03:59 AM UTC, Douglas Foster <
> >> >> 
> >> >> [email-masked]> wrote:
> >> >> >We have significant functional differences between the two tree
> >> >> >walks,
> >> >> >which are lost or ignored in the current prose.   This lack of
> >> 
> >> precision
> >> 
> >> >> >has also allowed us to overlook error handling, which is different
> >> 
> >> between
> >> 
> >> >> >the two types of tree walk.
> >> >> >
> >> >> >
> >> >> >I have provided a rough cut of the primary tree walk, using an
> >> >> >outline
> >> >> >approach rather than prose.   For the secondary tree walk, I only
> >> >> >have
> >> >> >summary comments about how it differs from the primary tree walk.  I
> >> 
> >> could
> >> 
> >> >> >beef up both sections after feedback
> >> >> >
> >> >> >Doug
> >> >> >
> >> >> >There are potentially two types of tree walks, both of which can be
> >> >> 
> >> >> avoided
> >> >> 
> >> >> >under specific circumstances.
> >> >> >
> >> >> >- The primary tree walk is used to find the RFC5322.From address
> >> >> >organizational domain and associated default policy, and is performed
> >> >> >once.
> >> >> >
> >> >> >- The secondary tree walk is used to test each verified domain for
> >> >> >alignment with the RFC5322.From domain.
> >> >> >
> >> >> >
> >> >> >
> >> >> >1)      RFC5322.From tree walk to Organizational Domain
> >> >> >
> >> >> >
> >> >> >
> >> >> >Exact-match check
> >> >> >
> >> >> >-------------------------
> >> >> >
> >> >> >- (optionally) verify that the lowest segment is a valid label
> >> 
> >> (doesn't
> >> 
> >> >> >start with an underscore, 64 or fewer characters long.  If format
> >> 
> >> rules
> >> 
> >> >> are
> >> >> 
> >> >> >violated, return an error.
> >> >> >
> >> >> >- check for TXT records at _dmarc.<domain name>
> >> >> >
> >> >> >- if no DMARCv1 records are found, report no-data-found and exit.
> >> >> >
> >> >>  Proceed
> >> >>  
> >> >> >to the organization domain and default policy search.
> >> >> >
> >> >> >- if two records are found, or if a single record does not parse
> >> >> 
> >> >> correctly,
> >> >> 
> >> >> >return an error.
> >> >> >
> >> >> >- if one usable record is found, check for a <role> indicator, and
> >> 
> >> proceed
> >> 
> >> >> >as follows:
> >> >> >      If a <not-for-mail> indicator is detected, return a DMARC Fail
> >> >> 
> >> >> result.
> >> >> 
> >> >> >      If both alignment policies are strict, the organization domain
> >> 
> >> and
> >> 
> >> >> >policy are not needed, so the primary tree walk is omitted.
> >> 
> >> Otherwise,
> >> 
> >> >> the
> >> >> 
> >> >> >tree walk is invoked to determine the organizational domain and
> >> 
> >> default
> >> 
> >> >> >policy
> >> >> >
> >> >> >
> >> >> >
> >> >> >If the tree walk is to be used, check to see if the From domain is
> >> 
> >> more
> >> 
> >> >> >than <Max=5> segments. If so, shorten the domain to <Max=5> segments.
> >> >> >Otherwise, remove one segment and check the resulting domain name for
> >> 
> >> a
> >> 
> >> >> >DMARC policy.   Then evaluate the shortened domain name:
> >> >> >
> >> >> >
> >> >> >
> >> >> >- (optionally) verify that the first segment of the domain name is a
> >> >> >valid label (doesn't start with an underscore, 64 or fewer characters
> >> >> >long.  If format rules are violated, return an error.
> >> >> >
> >> >> >- check for TXT records at _dmarc.<domain name>
> >> >> >
> >> >> >- if no DMARCv1 records are found, report no-data-found and exit the
> >> 
> >> step
> >> 
> >> >> >so the search can continue.
> >> >> >
> >> >> >- if two records are found, or if a single record does not parse
> >> >> 
> >> >> correctly,
> >> >> 
> >> >> >return an error.
> >> >> >
> >> >> >- if one usable record is found, check for a <role> indicator, and
> >> 
> >> proceed
> >> 
> >> >> >as follows:
> >> >> >       If a <non-boundary role> indicator is present, return
> >> 
> >> no-data-found
> >> 
> >> >> >and exit the step so the search can continue.
> >> >> >
> >> >> >       If a <psd role> indicator is present, return the cached domain
> >> 
> >> and
> >> 
> >> >> >policy, ending the search.
> >> >> >
> >> >> >       If a <top-of-organization role> indicator is present, return
> >> 
> >> the
> >> 
> >> >> >current domain and policy, ending the search.
> >> >> >
> >> >> >       If no indicator is found, cache the domain name and policy as
> >> >> >       a
> >> >> >
> >> >> >possible organizational domain.  Exit the step so the search can
> >> 
> >> continue.
> >> 
> >> >> >If a step exits with a confirmed organizational domain and default
> >> 
> >> policy,
> >> 
> >> >> >the search is complete.
> >> >> >
> >> >> >If a step exits with no-data-found, and the domain name has at least
> >> >> >2
> >> >> >segments, then remove the first segment and repeat the domain
> >> 
> >> evaluation.
> >> 
> >> >> >If a step exits with no-data-found, and the domain name is only 1
> >> 
> >> segment,
> >> 
> >> >> >then the search terminates.
> >> >> >
> >> >> >    If a cached organization domain and default policy are available,
> >> >> 
> >> >> these
> >> >> 
> >> >> >are the organizational domain and default policy.
> >> >> >
> >> >> >    If the cache is empty, no organizational domain is found.
> >> >> >    
> >> >> >          If an exact-match policy was previously detected, so that
> >> 
> >> the
> >> 
> >> >> >tree walk was only needed for relaxed alignment, then the match rule
> >> >> >reverts to strict.
> >> >> >
> >> >> >          If an exact-match policy was not detected, the domain does
> >> 
> >> not
> >> 
> >> >> >participate in DMARC.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >2)      Secondary Tree walk to test for alignment
> >> >> >
> >> >> >
> >> >> >
> >> >> >This has some notable differences from the Primary Tree Walk.
> >> >> >
> >> >> >-          The search only returns an “Aligned” or “Unaligned”.   The
> >> >> >values of the organization domain name and default policy will be
> >> 
> >> known if
> >> 
> >> >> >the names are aligned, and unimportant if the names are not aligned.
> >> >> >
> >> >> >-          Only one alignment result is needed, so domain evaluation
> >> >> 
> >> >> ceases
> >> >> 
> >> >> >as soon as an aligned result is obtained.
> >> >> >
> >> >> >-          If a DMARC policy error is detected during evaluation, the
> >> >> >domain being evaluated is discarded as not aligned, but the
> >> >> >evaluation
> >> >> >proceeds.
> >> >> >
> >> >> >-          The common substring should be determined.    If the
> >> >> >common
> >> >> >substring is shorter than the organizational domain, the domains are
> >> 
> >> not
> >> 
> >> >> >aligned, and the tree walk is not necessary.  Otherwise, the tree
> >> 
> >> walk is
> >> 
> >> >> >performed, but it terminates when the common substring is reached,
> >> 
> >> rather
> >> 
> >> >> >than when the domain string is exhausted.
> >> >> >
> >> >> >-          If an organization boundary is detected during the tree
> >> 
> >> walk,
> >> 
> >> >> >the domain being evaluated is discarded as not aligned.
> >> >> >
> >> >> >-          If no organization boundaries are identified during the
> >> 
> >> tree
> >> 
> >> >> >walk, the names are aligned.
> >> >> >
> >> >> >If the domain is discarded as not aligned, the alignment search
> >> 
> >> proceeds
> >> 
> >> >> to
> >> >> 
> >> >> >the next DKIM-verified or SPF-verified domain name.
> >> >> >
> >> >> >If the set of verified domain names contains any duplicates, only one
> >> >> >evaluation needs to be performed and the duplicates can be ignored.
> >> >> >
> >> >> >There are significant benefits expected from prioritizing the order
> >> >> >in
> >> >> >which verified domain names are tested.  Recommended sequence:
> >> >> >
> >> >> >-          Exact-match domains
> >> >> >
> >> >> >-          Parent domains.   Only the longest match needs to be
> >> 
> >> evaluated.
> >> 
> >> >> >-          Child domains.   Only the shortest match needs to be
> >> 
> >> evaluated.
> >> 
> >> >> >-          Sibling domains.   Process in order from longest common
> >> >> >substring to shortest common substring.
> >> >>

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 02 Apr 2022 19:35:16 -0400

On Wednesday, March 23, 2022 6:59:08 AM EDT Alessandro Vesely wrote:
> Hm...
> 
> On Wed 23/Mar/2022 03:08:35 +0100 Douglas Foster wrote:
> > During my ruminations last night, I gained some clarity around that
> > question and wanted to highlight those conclusions.  They simplify the
> > alignment search significantly:
> > 
> > - If the common substring is shorter than the Organizational Domain, then
> > the names are not aligned and the candidate domain can be ignored.
> > 
> > - Otherwise, if any candidate domain is a parent of (or equal to) the FROM
> > domain, then and we have alignment and DMARC PASS.  The secondary tree
> > walk is not needed and no further evaluation is required.
> > 
> > - If several candidate names are child domains of the FROM address, then
> > only the shortest string needs to be evaluated with a secondary tree
> > walk.  If it is aligned, further evaluation is not required.  If it is
> > not aligned because of an organizational boundary, all other child
> > domains are also excluded.
> That and the deeper-than-5 optimization Doug posted on a separate message.
> 
> 
> I know the document is already longish.  However, collecting these
> observations in an appendix may be helpful for developers, and maybe also
> for general understanding of the intricacies involved in the tree walk,
> including proper usage of the psd= flag.

I think we do need to add some additional clarity, which I plan to draft, but 
let's not go overboard.  We are trying to describe a protocol, not a 
implementation specification.  So far, in my experience, the extra code 
required to address short cuts like this is not justified by the improved 
'efficiency'.  I don't think these need to be in the document.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 02 Apr 2022 20:26:30 -0400

On Tuesday, March 22, 2022 11:16:13 AM EDT Scott Kitterman wrote:
> On Tuesday, March 22, 2022 5:54:33 AM EDT Alessandro Vesely wrote:
> > I think we need something like the following.
> > 
> > On Mon 21/Mar/2022 21:50:42 +0100 internet-drafts wrote:
> > OLD
> > 5.5.4.  Publish a DMARC Policy for the Author Domain
> > 
> >     Once SPF, DKIM, and the aggregate reports mailbox are all in place,
> >     it's time to publish a DMARC record.  For best results, Domain Owners
> >     SHOULD start with "p=none", with the rua tag containg a URI that
> >     references the mailbox created in the previous step.
> > 
> > NEW (add or replace)
> > 5.5.4.  Publish a DMARC record for the Author Domain
> > 
> >     A DMARC record MUST be defined at the Organizational Domain, that is
> >     the
> > 
> > shortest domain that belongs to the organization, see Section 3.2.7.  This
> > domain determines the alignment of the identifiers.  The domain part of
> > the
> > aggregate reports mailbox also needs to be aligned, otherwise an
> > additional
> > DMARC record for external destination verification has to be defined.  If
> > any subdomain of the organization is used as an Author Domain, a DMARC
> > record for that subdomain MAY be defined.  For example, the subdomain may
> > want a different policy or different reporting mailboxes.
> > 
> >     If a subdomain is independent from the organization, that is if the
> >     organization delegated control of the subdomain to another
> >     organization,
> > 
> > then the former organization is a PSO.  In that case, it is necessary to
> > use the psd flag to break alignment, so that an organization cannot
> > impersonate another one.
> > 
> > 
> > Is that obscure enough?
> 
> I think we need something here.  I agree with your core point that
> Organizational Domain has to have a DMARC record and we should say that.  I
> would spend the words on more PSO description here.  Almost no one is a PSO
> and we shouldn't over emphasize it.
> 
> I need to take another turn on the words I've been working on based on other
> comments.  I'll include something along these lines in that update and then
> you can see what you think.

Somewhat later than I had hoped, I've taken a shot at this.  Please see the 
attached proposed update from dmarcbis-06 and rfcdiff.

I suggest several changes here:

1.  In the tree walk description, update the step descriptions so that the 
entire tree walk is performed if needed.  Just because we find a DMARC record, 
we can't necessarily stop.

2.  In the policy discovery section I added a few sentences on which policy to 
use once the policy record is identified.  This doesn't change anything 
relative to what's currently defined, but it seems to me that if we are going 
to have a discussion of policy discovery we should take it all the way to 
determining the poilcy and not stop at the determination of the record to use 
to determine the policy.

3.  Added 'u' as the default for the psd= tag.  I believe I've captured the 
discussion from the working group on this.  If I didn't, I did not 
intentionally innovate.

4.  As discussed above, made it explicit that the Organizational Domain needs 
to have a DMARC record.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2022 22:49:03 -0400

>attached proposed update from dmarcbis-06 and rfcdiff.

Closer but of course, not quite right.

>determining the poilcy and not stop at the determination of the record to use 

It still gets the wrong answer for psd=n above psd=y.

I think it needs to say you walk up. At each step if you find psd=n,
that is the org domain and you stop. If you find psd=y, that is the
PSD, the org is the name beneath it, and you stop. (If the one beneath
it has no DMARC record, is it still the org domain? I think it is.)

If you get to the top and there was no record with psd=y or psd=n, the
org is the highest DMARC record you found.

This means if you find psd=n or psd=y you stop, if you find psd=u keep going.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Apr 2022 13:21:00 +0200

> It still gets the wrong answer for psd=n above psd=y.

Why?

> that is the org domain and you stop.

Right, that's step 1 of 4.8.

> If you find psd=y, that is the PSD, the org is the name beneath it, and you
> stop.

Yup, unless that's the From: domain (the sending PSO case).

> (If the one beneath it has no DMARC record, is it still the org domain? I
> think it is.)

This seems to be inconsistent with the sentence that follows.  Would the 
landscape change if .com suddenly publishes psd=y?

> org is the highest DMARC record you found.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 3 Apr 2022 13:22:08 +0200

> 'efficiency'.  I don't think these need to be in the document.

I agree that the efficiency is determined more by having a dedicated caching 
resolver than by the algorithm.  And the importance of setting up DNS will 
never be stressed enough.

I was thinking rather to a walk through the tree walk (no pun intended), to be 
read by domain owners and programmers alike, to help understanding what's good, 
what's bad, what's normal and what's exceptional.

Having such an appendix permits the actual algorithm to be stated in a concise, 
formal expression.  The last description, for example, uses two steps, 2 and 7, 
to advise to discard non-DMARC records.  Step 8 repeats the directive already 
given in step 3.  That language is neither formal nor friendly.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Sun, 3 Apr 2022 07:33:07 -0400

Scott said
" 3.  Added 'u' as the default for the psd= tag.  I believe I've captured
the
discussion from the working group on this.  If I didn't, I did not
intentionally innovate."

So to be completely clear: on date of publication, all of the existing
DMARC policy records become single-subdomain policy records, and the DNS
will be bereft of any organizational domain policies or PSD policies.

If this can be called design, it is a bad one.

df

---

From: Barry Leiba <[email-masked]>
Date: Sun, 3 Apr 2022 09:10:28 -0400

An alternative here is a pointer to one or two open-source implementations
that readers can refer to if they want to.  That keeps the document tight
while providing access to implementation examples.

Barry

---

From: "John R Levine" <[email-masked]>
Date: 3 Apr 2022 12:07:29 -0400

>> It still gets the wrong answer for psd=n above psd=y.

See the example I posted last week.

>> (If the one beneath it has no DMARC record, is it still the org domain? I think it is.)
>

Currently with the PSL lookup, foo.com is an org domain whether or not it 
publishes a DMARC record, and mail.foo.com and sales.foo.com are in 
relaxed alignment.  While I think it would be reasonable to say that an 
org domain has to publish a DMARC record if it's going to be used for 
relaxed alignment, that would be a change from the current rule.

Since there is no chance that .com .net .org or other large TLDs will ever 
publish a PSD record it makes little difference in practice, but if we 
agree the org domain needs a DMARC record, we should make clear that this 
is a deliberate change.  It's a good idea since if foo.com has no DMARC 
record and .com has no PSD record, it won't work as an org domain anyway.

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

---

From: Douglas Foster <[email-masked]>
Date: Sun, 3 Apr 2022 22:03:18 -0400

The problem remains that the tree walk only provides a reliable result if
it has complete information about private registries, and we have no way of
knowing if the tree walk provides that information.  Because these
processes are voluntary opt-in mechanisms, we cannot assume that all
private registries will publish the appropriate indicators.

To solve the problem, we need an indicator from the organization. that it
either (a) contains no private registries, (b) contains private registries
and the registration point is tagged with an indicator, or (c) contains
private registries but tagging is incomplete or not usable.   For (c), the
organization boundary cannot be determined reliably so only strict
alignment can be used  (or the PSL could be consulted.)  This
private-registry status indicator would need to be on the PSD-registered
organization domain policy.   The most efficient way to find a
PSD-registered organization policy is top down, as Scott originally
proposed.

Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Apr 2022 10:19:24 +0200

On Sun 03/Apr/2022 18:07:29 +0200 John R Levine wrote:
> publishes a DMARC record, and mail.foo.com and sales.foo.com are in relaxed 
> alignment.  While I think it would be reasonable to say that an org domain has 
> to publish a DMARC record if it's going to be used for relaxed alignment, that 
> would be a change from the current rule.

The current definition, Section 3.2.7, replicates the original semantic:

3.2.7.  Organizational Domain

    The Organizational Domain is typically a domain that was registered
    with a domain name registrar.  More formally, it is any Public Suffix
    Domain plus one label.  The Organizational Domain for the domain in
    the RFC5322.From domain is determined by applying the algorithm found
    in Section 4.8.

The last sentence is particular in that Section 4.8 aims at determining the 
Organizational Domain for /any/ identifier, not just the From: domain.  We are 
assuming that an org domain can be determined for any domain, always.

At the end of Section 4.8, in order to fulfill that assumption, in the absence 
of DMARC records, "the initial target domain" is promoted to the rank of 
Organizational Domain of itself.  That way, a PSD /is/ an org domain, which 
formally counters the second sentence in 3.2.7.

> publish a PSD record it makes little difference in practice, but if we agree 
> the org domain needs a DMARC record, we should make clear that this is a 
> deliberate change.  It's a good idea since if foo.com has no DMARC record and 
> .com has no PSD record, it won't work as an org domain anyway.

To make the change clearer, I suggest to use different terms to indicate 
"working" org domains and registered domains with no DMARC record.  Perhaps 
using the circumlocution DMARC Organizational Domain could suffice.  However, 
along with the ubiquitous use of other longish terms (such as the above domain 
in the RFC5322.From domain), it makes for a rather wordy spec.  Better names?

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Mon, 4 Apr 2022 07:01:42 -0400

Ale is correct on these points:

1. The exact-match test should be applied before any tree walk, not at the
end.

2. The design MUST distinguish between a public suffix operator and a
private registrar.   When the exact-match domain is a public registrar, the
result is FAIL-FromInvalid, triggering a hard reject.   When the
exact-match domain is a private registrar, we SHOULD have an indicator to
know whether or not the domain is used for mail, but with that omitted, we
have to assume that the private registrar domain sends mail and may be
either an organizational domain or a subdomain of an organization.

Additionally, the specification would be much improved if it first defined
the interfaces to the two functions, and then explained the
implementations.  The actual processing logic has significant differences
between the two functions.

While the current text treats the organizational domain search and default
policy search as different tasks, they are easily handled as a single
function.   When either lookup is needed, we invoke:

Status = FindOrgData(  RFC5322.From IN,  OrganizationalDomainFQDN OUT,
DefaultPolicyRecord OUT)
Where Status =  ( SUCCESS | PERMERROR )

When the Relaxed Alignment test is needed, the interface definition is:

Status = CheckRelaxedAlignment( CandidateDomainFQDN IN,
OrganizationalDomainFQDN IN, RFC5322.From IN )
Where Status = ( ALIGNED | UNALIGNED )

Notes on FindOrgData
The exact-match policy is checked first.
1. If a policy is found and specifies Strict Alignment for both SPF and
DKIM, the organizational data is not needed, so the function is not called.
2. If a policy is found and it is tagged as an organizational domain
policy, then the organizational data is already known, so the function is
not called.
3. If a policy is found, and is not tagged as a PSD policy, and the
RFC5322.From domain is only two segments, then the organizational data is
already known, so the function is not called.

Notes on CheckRelaxedAlignment:
1. The CheckRelaxedAlignment is called for each verified SPF or DKIM
domain, until ALIGNED status is returned or the list of candidates has been
exhausted.
2. If the policy specifies strict alignment for the candidate domain type
(SPF or DKIM), then the function is not called for that candidate domain.
A string match is used instead
3. The CheckRelaxedAlignment function could be implemented without using
the RFC5322.From address as a parameter, but this data element permits a
number of optimizations, including an embedded exact-match test.

We have two proposed implementations of these functions, one based on the
PSD and one based on Tree Walk.  However, as an evaluator, the Tree Walk
does not yet earn my trust.

Doug

On Mon, Apr 4, 2022 at 4:19 AM Alessandro Vesely <[email-masked]> wrote:

> relaxed
> agree

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Apr 2022 09:07:38 -0400

> If this can be called design, it is a bad one.

Fortunately that's not what we have.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Apr 2022 09:15:02 -0400

It doesn't matter what order you do the queries in.  You still have to do them 
all.

Scott K

On Sunday, April 3, 2022 10:03:18 PM EDT Douglas Foster wrote:
> >> >>> - If the common substring is shorter than the Organizational Domain,
> >> 
> >> then
> >> 
> >> >>> - Otherwise, if any candidate domain is a parent of (or equal to) the
> >> 
> >> FROM
> >> 
> >> >>> - If several candidate names are child domains of the FROM address,
> >> 
> >> then
> >> 
> >> >> That and the deeper-than-5 optimization Doug posted on a separate
> >> 
> >> message.
> >> 
> >> >> observations in an appendix may be helpful for developers, and maybe
> >> 
> >> also
> >> 
> >> > I think we do need to add some additional clarity, which I plan to
> >> 
> >> draft, but
> >> 
> >> > required to address short cuts like this is not justified by the
> >> 
> >> improved
> >>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 04 Apr 2022 09:29:40 -0400

On Saturday, April 2, 2022 10:49:03 PM EDT John Levine wrote:
> >2.  In the policy discovery section I added a few sentences on which policy
> >to use once the policy record is identified.  This doesn't change anything
> >relative to what's currently defined, but it seems to me that if we are
> >going to have a discussion of policy discovery we should take it all the
> >way to determining the poilcy and not stop at the determination of the
> >record to use to determine the policy.
> 

I think the attached addresses this.  I also tried to make it clear that if 
there's only one domain (common 5322.From, 5321.MailFrom, and d=), then no 
tree walk is needed.

The diff is relative the last text I posted.

Scott K

---

From: Todd Herr <[email-masked]>
Date: Mon, 4 Apr 2022 10:01:13 -0400

> The diff is relative the last text I posted.
Thank you, Scott.

I will wait a day or two to allow further discussion to continue before
publishing a new rev.

-- 

*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 R Levine" <[email-masked]>
Date: 4 Apr 2022 11:24:34 -0400

On Mon, 4 Apr 2022, Alessandro Vesely wrote:
> Organizational Domain for /any/ identifier, not just the From: domain.  We 
> are assuming that an org domain can be determined for any domain, always.
>
> At the end of Section 4.8, in order to fulfill that assumption, in the 
> absence of DMARC records, "the initial target domain" is promoted to the rank 
> of Organizational Domain of itself.  That way, a PSD /is/ an org domain, 
> which formally counters the second sentence in 3.2.7.

If it's the original domain, yes.  If it's an ancestor found in the tree 
walk, no.

> To make the change clearer, I suggest to use different terms ...

No.  We can clarify the text but we already have too much jargon here.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 4 Apr 2022 19:19:13 +0200

On Mon 04/Apr/2022 17:24:34 +0200 John R Levine wrote:
> If it's the original domain, yes.

We know that co.uk is not an Organizational Domain.  Asking what is the 
Organizational Domain of co.uk is an ill-posed question.

> No.  We can clarify the text but we already have too much jargon here.

How about restricting the term to DMARC?

NEW

    The Organizational Domain is typically a domain that was registered
    with a domain name registrar and complies with DMARC.  More formally,
    it is any Public Suffix Domain plus one label which publishes a DMARC
    record (see Section 5.1).  The algorithm to determine The Organizational
    Domain, if any, is found in Section 4.8.

I think this change parallels the change from PSL to tree walk, and justifies it.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 4 Apr 2022 13:31:36 -0400

> Organizational Domain of co.uk is an ill-posed question.

These are all in the PSL.  What are their organizational domains?

_dmarc.wa.gov.au TXT "v=DMARC1; p=none; fo=1:d; rua=mailto:[email-masked],mailto:[email-masked];ruf=mailto:d
[email-masked],mailto:[email-masked]"
wa.gov.au mail is handled by 10 inbound-smtp.us-west-2.amazonaws.com.
wa.gov.au TXT "v=spf1 include:amazonses.com ~all"

_dmarc.gov.az TXT "v=DMARC1; p=reject; pct=100; fo=1; adkim=s; aspf=s; rua=mailto:[email-masked]"
gov.az mail is handled by 0 sea1.mail.gov.az.
gov.az mail is handled by 10 sea2.mail.gov.az.
gov.az TXT "v=spf1 redirect=_spfx.mail.gov.az"

_dmarc.gov.in TXT "v=DMARC1; p=quarantine; sp=none; fo=1;rua=mailto:[email-masked];ruf=mailto:[email-masked]"
gov.in mail is handled by 5 mailgwgov.nic.in.
gov.in TXT "v=spf1 mx ip4:164.100.14.0/24 ip4:164.100.2.0/24 ip4:164.100.10.0/24 ip4:164.100.15.0/24 ip4:164.100.13.0/24 -all"

_dmarc.edu.kz TXT "v=DMARC1; p=none; rua=mailto:[email-masked]"
edu.kz mail is handled by 10 post.mail.kz.
edu.kz TXT "v=spf1 a mx ip4:88.204.157.164 ~all"

_dmarc.ac.me TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; fo=0; pct=100; rua=mailto:[email-masked]"
ac.me mail is handled by 10 mail.ac.me.
ac.me TXT "v=spf1 mx ip4:89.188.43.10 ip6:2a02:4280:0:200:89:188:43:10 -all"

_dmarc.nhs.uk TXT "v=DMARC1; p=reject; sp=none;adkim=s;aspf=s;fo=1; rua=mailto:[email-masked],mailto:[email-masked]"
nhs.uk mail is handled by 50 mail.nhs.uk.
nhs.uk TXT "v=spf1 ip4:213.161.89.71 ip4:213.161.89.72 ip4:213.161.89.73 ip4:213.161.89.103 ip4:213.161.89.104 ip4:213.161.89.105 -all"

_dmarc.police.uk TXT "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:[email-masked];ruf=mailto:[email-masked]"
police.uk has no MX record
police.uk TXT "v=spf1 -all"

_dmarc.k12.dc.us TXT "v=DMARC1; p=none; rua=mailto:[email-masked];"
k12.dc.us mail is handled by 10 dck12.mail.protection.outlook.com.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2022 17:44:46 -0400

>there's only one domain (common 5322.From, 5321.MailFrom, and d=), then no 

Is that right? Let's say all three domains are sales.foo.com, there is
no DMARC record _dmarc.sales.foo.com, but there might be one at
_dmarc.foo.com.  I think you need to do the tree walk to find the policy.

This is less urgent, but between steps 7 and 8 8 in 4.6, I'd say that
if you find a record with psd=y or psd=n you stop the tree walk, since
nothing above that is relevant.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 5 Apr 2022 09:57:30 +0200

> These are all in the PSL.  What are their organizational domains?

Scott took the time to define PSDs and PSOs in RFC 9091, restated in Sections 
3.2.8 and 3.2.9 of the current draft.  Since the definitions of Organizational 
Domain (both the current 3.2.7 an my proposed change) require PSD + 1, a PSD 
has to be a proper subdomain of another PSD in order to admin an Organizational 
Domain itself.

> _dmarc.wa.gov.au TXT "v=DMARC1; p=none; fo=1:d; rua=mailto:[email-masked],mailto:[email-masked];ruf=mailto:[email-masked],mailto:[email-masked]"

All of the above admit no org domain.  I'd amend step 2 like so:

OLD
    2.  If a valid DMARC record contains the psd= tag set to 'y' (psd=y),
        the Organizational Domain is the domain one label below this one
        in the DNS hierarchy, and the selection process is complete.

NEW
    2.  If a valid DMARC record contains the psd= tag set to 'y' (psd=y),
        the Organizational Domain is the previous domain of those selected,
        if any.  In any case the selection process is complete.

I note that only police.uk is registered at psddmarc.org.  It is also the only 
"pure" PSD, in the sense that they don't send mail themselves.

Scott, is that the reason why the others are not registered?

All them should amend their DMARC records adding psd=y.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 5 Apr 2022 10:43:49 +0200

> The diff is relative the last text I posted.

Section 5 has to stay before Section 4.  It makes no sense to exemplify 
_dmarc.example.com if we haven't yet said that:

    Domain Owner and PSO DMARC preferences are stored as DNS TXT records
    in subdomains named "_dmarc".
                                                   [Current Section 5.1]

Then, let's make a statement like so:

    Retrieving the DMARC record of a domain implies the following steps:

    1.  Prepend the label "_dmarc" to the domain name and issue a DNS Query for
        a TXT record at the resulting domain.  For example, if the domain is
        example.com, query _dmarc.example.com.

    2.  Collate any string returned, in the order returned.

    3.  Records that do not start with a "v=" tag that identifies the
        current version of DMARC are discarded.  If multiple DMARC
        records are returned, they are all discarded.

At this point, the algorithm can be expressed in a shorter form like so:

    1.  Set the current target to the identifier at hand, which is one of the
        domain(s) described above.

    2.  Retrieve the DMARC record of the current target.

    3.  If the record exists and contains either psd=y or psd=n, stop.

    4.  Break the current target 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.

    5.  Count the number of labels in the current target.  Let that number
        be "x".  If x = 1, stop.  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.

    6.  Go to 2.

Better?

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2022 12:22:57 -0400

> 3.2.8 and 3.2.9 of the current draft.  Since the definitions of 
> Organizational Domain (both the current 3.2.7 an my proposed change) require 
> PSD + 1, a PSD has to be a proper subdomain of another PSD in order to admin 
> an Organizational Domain itself.

I don't agree, but whatever.

[ long list of PSDs that send and receive mail ]

> All of the above admit no org domain.

If I have a message from [email-masked] and it has valid SPF of mail.ac.me, is that aligned?  Why or why not?

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Apr 2022 18:52:29 -0400

> nothing above that is relevant.

I agree on the first point.

I'd suggest we change the first point in the note for 4.8.

Was:

   *  The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
      authenticated), and/or the DKIM d= domain (if present and
      authenticated) are all the same.  In this case, this common domain
      is treated as the Organizational Domain.

Is:

   *  The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
      authenticated), and/or the DKIM d= domain (if present and
      authenticated) are all the same  and that domain has a DMARC record.
      In this case, this common domain is treated as the Organizational
      Domain.

Adding "and that domain has a DMARC record" as a condition for not doing the 
tree walk should be sufficient.

For the second point, I think that's accurate, but I don't really think we 
need to standardize the optimization.  If I'm using an async DNS resolver, I 
would implement firing off all the necessary queries and then evaluating them 
once I have the answer.  I don't think we'd want to require (or appear to 
require) anyone to do a single query and evaluate the result before doing the 
next query.  That could be several times slower and at scale that typically 
will be more important than the extra DNS queries.

I'm not going to post another proposed revision for the above change, I think 
Todd can just incorporate that for the next revision.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Apr 2022 18:55:50 -0400

On Tuesday, April 5, 2022 3:57:30 AM EDT Alessandro Vesely wrote:
> Scott took the time to define PSDs and PSOs in RFC 9091, restated in
> Sections 3.2.8 and 3.2.9 of the current draft.  Since the definitions of
> Organizational Domain (both the current 3.2.7 an my proposed change)
> require PSD + 1, a PSD has to be a proper subdomain of another PSD in order
> to admin an Organizational Domain itself.
> 
> > _dmarc.wa.gov.au TXT "v=DMARC1; p=none; fo=1:d;
> > rua=mailto:[email-masked],mailto:dmarc_records@wa.
> > gov.au;ruf=mailto:[email-masked],mailto:dmarc_recor
> > [email-masked]" wa.gov.au mail is handled by 10
> > inbound-smtp.us-west-2.amazonaws.com. wa.gov.au TXT "v=spf1
> > include:amazonses.com ~all"
> > 
> > _dmarc.gov.az TXT "v=DMARC1; p=reject; pct=100; fo=1; adkim=s; aspf=s;
> > rua=mailto:[email-masked]" gov.az mail is handled by 0 sea1.mail.gov.az.
> > _dmarc.gov.in TXT "v=DMARC1; p=quarantine; sp=none;
> > fo=1;rua=mailto:[email-masked];ruf=mailto:[email-masked]"
> > gov.in TXT "v=spf1 mx ip4:164.100.14.0/24 ip4:164.100.2.0/24
> > ip4:164.100.10.0/24 ip4:164.100.15.0/24 ip4:164.100.13.0/24 -all"
> > 
> > _dmarc.ac.me TXT "v=DMARC1; p=quarantine; adkim=r; aspf=r; fo=0; pct=100;
> > rua=mailto:[email-masked]" ac.me mail is handled by 10 mail.ac.me.
> > _dmarc.nhs.uk TXT "v=DMARC1; p=reject; sp=none;adkim=s;aspf=s;fo=1;
> > rua=mailto:[email-masked],mailto:[email-masked]"
> > nhs.uk TXT "v=spf1 ip4:213.161.89.71 ip4:213.161.89.72 ip4:213.161.89.73
> > ip4:213.161.89.103 ip4:213.161.89.104 ip4:213.161.89.105 -all"
> > 
> > _dmarc.police.uk TXT
> > "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:[email-masked]
> > ervice.gov.uk;ruf=mailto:[email-masked]" police.uk has no
> > MX record
> > _dmarc.k12.dc.us TXT "v=DMARC1; p=none;
> > rua=mailto:[email-masked];" k12.dc.us mail is handled by 10
> > dck12.mail.protection.outlook.com.
> I note that only police.uk is registered at psddmarc.org.  It is also the
> only "pure" PSD, in the sense that they don't send mail themselves.
> 

The entities listed on the psddmarc.org registry requested to be there.  I 
think that once we've settled the questions around the psd tag the WG should 
ask for an early registration for the new tag.  I think that's the point where 
these entities should update their records.

Generally speaking, I think that a PSD can send mail and it should be covered 
by DMARC, so I disagree with the idea that a PSD can never also be an Org.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Apr 2022 18:58:22 -0400

On Tuesday, April 5, 2022 4:43:49 AM EDT Alessandro Vesely wrote:
>     1.  Prepend the label "_dmarc" to the domain name and issue a DNS Query
> for a TXT record at the resulting domain.  For example, if the domain is
>     1.  Set the current target to the identifier at hand, which is one of
> the domain(s) described above.
> 

Maybe.  I'd say lets get a draft out that we agree gives the correct result 
before we start re-writing for taste.  I don't think the order matters that 
much.  An RFC is not a single pass compiler.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Apr 2022 19:01:46 -0400

On Tuesday, April 5, 2022 12:22:57 PM EDT John R Levine wrote:
> > require PSD + 1, a PSD has to be a proper subdomain of another PSD in
> > order to admin an Organizational Domain itself.
> 

I think for a PSD that sends mail, the current definitions would require Mail 
>From for SPF or d= for DKIM to be the same because they wouldn't end up having 
the same org domain.  It might be simple enough to say to ignore psd=y or a 
lower level psd=n if the 5322.From has a domain with psd=y (they can always 
set strict alignment if they don't want lower level stuff to match).

Scott K

---

From: "John Levine" <[email-masked]>
Date: 5 Apr 2022 21:33:58 -0400

>tree walk should be sufficient.

That should work.

>once I have the answer. 

Good point.  "Never mind."

R's,
John

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2022 22:21:52 -0400

> by DMARC, so I disagree with the idea that a PSD can never also be an Org.

How about if we say that if the initial domain has psd=y, that's the org 
domain and you don't look anywhere else.  That is easy to explain and I 
don't think we are likely to find anything that better matches the 
expectations of people who send mail from PSDs.

There are 44 domains in the "ICANN" part of the PSL that have MX records 
and at least 400 in the "PRIVATE" part so I think it would be a good idea 
to have a plan for how DMARC works for them.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Apr 2022 05:07:32 +0000

>to have a plan for how DMARC works for them.

Agreed as far as having a plan, but it would have to be more complicated or more restrictive than that, I think.

Let's take the example of:

5322.From: psd.example (which has psd=y)
5321.MailFrom: spf.psd.example
d= domain: dkim.psd.example.

If we just ignore psd=y for an exact match, then the org domain for psd.example is psd.example, spf.psd.example for SPF, and dkim.psd.example for DKIM.  Neither align since neither have the same org domain as the 5322.From.

I see two potential paths out of this:

1.  Slightly expand your proposal to say that if the 5322.From domain has psd=y, then the psd tag is ignored for all org domain determinations for the message.

2.  Just say explicitly, if you are a PSD, you have to make all three the exact domain (effectively like strict alignment only).

The current text says a domain is always its own org domain, so we have (without explaining it anywhere) defined #2 currently.  I think that's good.

PSDs, have already (mostly) told us that the name space below is administratively distinct.  The approach in #1 would give all their customers the ability to spoof them, which is suboptimal.  Additionally it would make the SPF and DKIM org domain determinations dependent on the org domain determination from the 5322.From.  That adds complexity and seems ugly.

A PSD that does control/trust the namespace below it (e.g. .mil) might not even need to bother with psd=y if they aren't worried about their registrants spoofing each other.

My suggestion is that we leave the process as is and add some explanation for PSDs on the implication of being a mail sending PSD that does DMARC.  It should be simple enough.

If the group agrees, I can write something up, but I don't think the next revision needs to wait for it.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 6 Apr 2022 12:07:08 +0200

>> I don't agree, but whatever.

PSD + 1 != PSD, since 1 != 0.  No need to agree or disagree...

> set strict alignment if they don't want lower level stuff to match).

+1

OTOH, if the From: domain is without psd=y, then any identifier having psd=y 
cannot be aligned.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 6 Apr 2022 12:08:20 +0200

>>> by DMARC, so I disagree with the idea that a PSD can never also be an Org.

They can send mail, but they're different from an org domain in that the latter 
can have aligned subdomains.

> If we just ignore psd=y for an exact match, then the org domain for psd.example is psd.example, spf.psd.example for SPF, and dkim.psd.example for DKIM.

It is not that we ignore psd=y.  I'd say that in this case psd.example /must be 
treated like/ an org domain —although it isn't— with the restriction that 
alignment must be strict.

> Neither align since neither have the same org domain as the 5322.From.

Correct, for whatever definition of org domain.

> The current text says a domain is always its own org domain, so we have (without explaining it anywhere) defined #2 currently.  I think that's good.

I agree that #2 is straightforward.  It follows also if we define alignment for 
either identical domains or both admitting identical org domains (as per my 
proposed amendment).

> PSDs, have already (mostly) told us that the name space below is administratively distinct.  The approach in #1 would give all their customers the ability to spoof them, which is suboptimal.  Addit…

+1,  #2 is the way to go.

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2022 12:03:53 -0400

It appears that Scott Kitterman  <[email-masked]> said:
>1.  Slightly expand your proposal to say that if the 5322.From domain has psd=y, then the psd tag is
>ignored for all org domain determinations for the message.
>
>The current text says a domain is always its own org domain, so we have (without explaining it anywhere)
>defined #2 currently.  I think that's good.

Looking at the DMARC records for PSD, most of them say strict
alignment, so I agree, it's easy to explain and unsurprising.

R's,
John