Re: [dmarc-ietf] Been Quiet Around Here - Org Domain? Tree Walk?

[Scott Kitterman <[e-mail]>]

On Wednesday, April 6, 2022 6:05:53 AM EDT Alessandro Vesely wrote:
> On Wed 06/Apr/2022 00:44:50 +0200 Scott Kitterman wrote:
> > On Monday, April 4, 2022 1:39:35 PM EDT Alessandro Vesely wrote:
> >> On Mon 04/Apr/2022 15:14:07 +0200 Scott Kitterman wrote:
> >>> On Sunday, April 3, 2022 12:15:23 PM EDT Alessandro Vesely wrote:
> >>>> On Mon 21/Mar/2022 23:02:03 +0100 Scott Kitterman wrote:
> >>>>> On March 21, 2022 5:42:42 PM UTC, Alessandro Vesely <[e-mail]> 
wrote:
> >>>>>> According to the definition, two identical domains having psd=y
> >>>>>> are in strict alignment but not in relaxed alignment, which is
> >>>>>> somewhat counterintuitive.
> >>>>> 
> >>>>> Actually, no:
> >>>>> 
> >>>>> "If this process does not determine the Organizational Domain, then
> >>>>> 
> >>>>>     the initial target domain is the Organizational Domain."
> >>>>> 
> >>>>> This text in DMARCbis06 addresses that case.
> >>>> 
> >>>> While that's true, it could be possible to revise the comparison
> >>>> process so as to account for identical domains.  In that case, we
> >>>> could avoid to call Organizational Domain one with no DMARC record.
> >>> 
> >>> I thought I had covered this already in Section 4.8.  I'll add it to the
> >>> list in the note.
> >> 
> >> Yeah, the text you wrote Sunday night looks better.  I'd say:
> >>     If this process does not determine the Organizational Domain, then
> >>     there is no Organizational Domain.
> >> 
> >> That requires rewording the definitions of relaxed alignment.
> 
> (Besides, we have too many definitions of alignment.)
> 
> > So far, I don't think we've messed with those definitions.  I'd prefer not
> > to change them.
> 
> The point is to not have conflicting definitions.  It can be acceptable that
> the algorithm to determine the org domain finds none, if there is no org
> domain.  Currently, the org domain found by the algorithm is not
> necessarily PSD + 1.  So, it is not what we defined to be the org domain. 
> Isn't this messed up?

There are some definitional issues we need to straighten out (but not, IMO, 
ones that need to be addressed before the next revision is published.

Food for thought:

> 3.2.4.  Identifier Alignment
> 
>    When the domain in the address in the RFC5322.From header field has
>    the same Organizational Domain as a domain verified by an
>    authenticated identifier, it has Identifier Alignment. (see
>    Section 3.2.7)

An implication of that definition is that if there is no organizational domain, 
there is no alignment.  Even if 5322.From, 5321.MailFrom, and d= are the same, 
if there is no organizational domain, they are not aligned.  I think this is 
fine.  This is the reason why I added the fallback that if you don't find an 
organizational domain, the original domain is the organizational domain.

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

I think the second and third sentences in the current Organizational Domain 
definition conflict.  I think the second sentence should be deleted (it's not 
essential, but I believe this could be done for the next revision).

> 3.2.8.  Public Suffix Domain (PSD)
> 
>    The global Internet Domain Name System (DNS) is documented in
>    numerous RFCs.  It defines a tree of names starting with root, ".",
>    immediately below which are Top-Level Domain names such as ".com" and
>    ".us".  The domain name structure consists of a tree of names, each
>    of which is made of a sequence of words ("labels") separated by
>    period characters.  The root of the tree is simply called ".".  The
>    Internet community at large, through processes and policies external
>    to this work, selects points in this tree at which to register domain
>    names "owned" by independent organizations.  Real-world examples of
>    these points are ".com", ".org", ".us", and ".gov.uk".  Names at
>    which such registrations occur are called "Public Suffix Domains
>    (PSDs)", and a registration consists of a label selected by the
>    registrant to which a desirable PSD is appended.  For example,
>    "ietf.org" is a registered domain name, and ".org" is its PSD.

This definition works for RFC 9091.  It's an indirect way of implying "things 
in the PSL", but I don't think we need it to be so broad anymore.

In RFC 9091 we talked about multi-organization and single organization PSDs.  
For RFC 7489 + RFC 9091, that was essential, but I don't think single 
organization PSDs need special treatment anymore.  Presumably entities like 
.google can keep their own house in order.  The key element from that 
definition is 'register domain names "owned" by independent organizations'.

I think we could (and should) rework the PSD definition around that concept.

On a related note, we still need to pull the new Privacy Considerations in 
from RFC 9091 and update them for the new design.

These two things should be done in concert.  I'll work on that and provide 
something after the next revision is out.

Scott K

Scott K