On Tuesday, April 16, 2024 5:17:44 PM EDT Todd Herr wrote:
> Colleagues,
>
> DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy
> record as follows:
>
> The DMARC policy record is published for a PSD, but it is not the
> Organizational Domain for itself and its subdomain. There is no need to put
> psd=n in a DMARC record, except in the very unusual case of a parent PSD
> publishing a DMARC record without the requisite psd=y tag.
> I don't think this is entirely accurate, especially the second sentence
> ("no need ... except in the very unusual case"), and here's why. Either
> that, or the description of the Tree Walk needs to be changed.
>
> The Tree Walk is intended for both DMARC Policy discovery and
> Organizational Domain discovery, and section 4.7 (DMARC Policy Discovery)
> says the policy to be applied will be the DMARC record found at one of
> these three locations:
>
> - The RFC5322.From domain
> - The Organizational Domain of the RFC5322.From domain
> - The Public Suffix Domain of the RFC5322.From domain
>
> Meanwhile, section 4.8, Organizational Domain Discovery, gives the
> following three options for where the Organizational Domain is:
>
> 1. DMARC record with psd=n
> 2. The domain one level below the domain with a DMARC record with the
> tag psd=y
> 3. The record for the domain with the fewest number of labels.
>
> The Tree Walk, as described in section 4.6, defines two explicit places to
> stop, both of which rely on discovery of a DMARC policy record with a psd
> tag defined:
>
> - Step 2, if the DMARC record has psd=n
> - Step 7, if the DMARC record has psd=n or psd=y
>
> There is no other stopping place described, and no instructions to collect
> DMARC policy records that don't have the psd tag defined during the walk,
> and while Organizational Domain Discovery speaks of records retrieved
> during the Tree Walk, there are no instructions in the Tree Walk steps
> themselves in section 4.6 to put all the DMARC records with no psd tag in a
> basket somewhere for later usage.
>
> So the questions I have are...
>
> 1. Should the description of the 'n' value for the 'psd' tag be updated
> to discuss its usage in a decentralized control model (e.g., seven label
> RFC5322.From with DMARC policy published at a five label name to allow
> for "local" control, with said policy being different from the policy
> published at the "traditional" org domain leve)?
> 2. Should the description of the Tree Walk in section 4.6 be updated, to
> mention that valid DMARC records with no explicit psd tag might be found
> during the walk, and these should be preserved for later comparison to
> determine the organizational domain?
>
> I look forward to the discussion.
Since this is a protocol specification and not a programming specification, I
don't think we need to be so proscriptive about storing results. My answer to
question 2 is no, I don't think we should change it.
I am ambivalent about question 1. Personally, I think it's fine as is, but if
people think it's unclear, we should probably come up with something better.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
