Re: [dmarc-ietf] Issue opened: Use a four-valued token for the four roles of a DMARC policy

[Scott Kitterman <[e-mail]>]

On Monday, August 29, 2022 1:54:31 PM EDT Todd Herr wrote:
> On Mon, Aug 29, 2022 at 1:29 PM Alessandro Vesely <[e-mail]> 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: [e-mail]
> > 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