On Monday, August 29, 2022 1:54:31 PM EDT Todd Herr wrote: > On Mon, Aug 29, 2022 at 1:29 PM Alessandro Vesely <ves...@tana.it> wrote: > > Is it so? My understanding is that psd=y is ignored when it is the first > > step in a tree walk. That way you can have From: u...@psd.example.com > > authenticated by d=example.com, or helo=mailout.example.com on a bounce. > > I'm curious as to why this is your understanding, because this is how the > psd tag and its value of y are currently described in section 5.2, DMARC > URIs: > > psd: > > A flag indicating whether the domain is a PSD. (plain-text; OPTIONAL; > default is 'u'). Possible values are: > y: > PSOs include this tag with a value of 'y' to indicate that the domain is a > PSD. If a record containing this tag with a value of 'y' is found during > policy discovery, this information will be used to determine the > Organizational Domain and policy domain applicable to the message in > question. > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-5 > .3-4.12.1> Meanwhile, the tree walk is described in section 4.6 in this way: > > The generic steps for a DNS Tree Walk are as follows: > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-4 > .6-5> > > 1. > > Query the DNS for a DMARC TXT record at the DNS domain matching the one > found in the domain(s) described above. A possibly empty set of records > is returned.ΒΆ > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-> > 4.6-6.1.1> 2. > > 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. If a single record remains and it contains a > "psd=n" tag, stop. > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-> > 4.6-6.2.1> 3. > > Determine the target for additional queries (if needed; see the > note in Section > 4.8 > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#organiza > tional-domain-discovery>), using steps 4 through 8 below. > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-> > 4.6-6.3.1> 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" would be label > 3, and so forth. > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-> > 4.6-6.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-17.html#section-> > 4.6-6.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-17.html#section-> > 4.6-6.6.1> 7. > > Records that do not start with a "v=" tag that identifies the current > version of DMARC are discarded. If multiple DMARC records are returned > for a single target, they are all discarded. If a single record remains and > it contains a "psd=n" or "psd=y" tag, stop. > > <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-17.html#section-> > 4.6-6.7.1> 8. > > 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 the process stops or there are no more labels remaining. > > Step 2 seems to contain an implicit assumption that the first record > queried for will never contain "psd=y", but perhaps it should have as its > final sentence the same wording as step 7, i.e., "If a single record > remains and it contains a 'psd=n' or 'psd=y' tag, stop"?
No. There's no reason for it and we've discussed this before. The reason to stop on psd=n is that it's an explicit statement that it's the org domain and that whatever is above it on the tree shouldn't be considered. That's not true for psd=y. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
