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 <[email protected]> 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. For example: > > OLD > 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 to be aligned. In strict mode, > only an exact match between both Fully Qualified Domain Names (FQDNs) > is considered to produce Identifier Alignment. > > NEW > In strict mode, an exact match between both Fully Qualified Domain Names > (FQDNs) is required to produce Identifier Alignment. In relaxed mode, an > exact match of either both identifiers or of their respective > Organizational Domains, if both exist, is considered to produce Identifier > Alignment.
So far, I don't think we've messed with those definitions. I'd prefer not to change them. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
