Todd, your confusion makes me think we do need a four-valued identifier. Any domain might be used to send mail, legitimately or fraudulently, and may have a DMARC record. Therefore, an initial PSD=Y is always a possibility.
Initial PSD=Y means that an organizational boundary exists below the current domain, but we are not moving downward, so the boundary does not matter. Based on this, we have to conclude that initial PSD=Y is ignored. However, PSD=Y often also occurs on domains that have a boundary above, meaning that we also need PSD=N, but we have not provided a way to specify PSD=Y and PSD=N at the same time. This problem is intertwined with the issue of whether we want to allow a private registry domains to send authenticated mail using relaxed alignment. I am assuming consensus that PSO domains are all self-contained and relaxed alignment is not possible for them. We also know from the PSL that most private registries are self-contained, while a few (about 200) have parents that are not PSOs and therefore the private registry could potentially participate in relaxed alignment, if the domain actually sent mail and wanted to use relaxed alignment. That group is presumably a tiny fraction of the 200. I had argued awhile back that when a registrar policy is applied to a client organization, the alignment rule should always be strict. This is because the PSD does not know if the client is a private registry and the PSD does not know if non-registry clients have sufficient internal control for relaxed authentication to be appropriate. If we require PSD=Y to mean strict alignment, it will simplify a lot of this complexity. It will allow us to say that because PSD=Y always means strict alignment, we don't need to distinguish between PSD=Y ONLY and PSD=Y+N. PSD=Y would always terminate the Tree Walk, even on an initial policy. df On Mon, Aug 29, 2022 at 1:55 PM Todd Herr <todd.herr= 40valimail....@dmarc.ietf.org> 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#organizational-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"? > > -- > > *Todd Herr * | Technical Director, Standards and Ecosystem > *e:* todd.h...@valimail.com > *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. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
