Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
> On Apr 16, 2024, at 2:18 PM, 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:
> DMARC record with psd=n
> The domain one level below the domain with a DMARC record with the tag psd=y
> 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.
One of your concerns is that without a PSD tag, but I think the default is
PSD=n. Does,that address that concern or did I misunderstand the concern?
N___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote: > On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > Todd, can you clarify this? > > > > N is not concerned with maximum labels on a subdomain. We are interested > > in the maximum length of an org domain used for relaxed alignment. > > > > If this client wants to use level 7 as an org domain and apply relaxed > > alignment for 8-label domains, then N needs to be 7. If the client's > > lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. > > Similarly, if the7-label domain only needs strict authentication, then N=7 > > is not needed. > > > > Has this or another client genuinely chafed at the insufficient > > granularity of the old PSL? > > My understanding of the Tree Walk is that in DMARCbis it is the defined > method for performing two separate jobs: > >- Discover the controlling DMARC policy record for the RFC5322.From >domain in a given email message; this controlling DMARC policy will be >found at either the RFC5322.From domain, the organizational domain for > the RFC5322.From domain, or the PSD of the RFC5322.From domain. >- Determine the organizational domains for the SPF domain,and the DKIM >domain in a given email message, in order to determine whether the > domains are in relaxed alignment with the RFC5322.From domain > > As I wrote in an earlier message, we have data showing use of seven label > domains in the RFC5322.From domains; it's not a lot of data, but it's there. > > So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld, > DMARC Policy Discovery would be done by querying for these five (5) records: > >- _dmarc.a.b.c.d.e.f.tld >- _dmarc.d.e.f.tld >- _dmarc.e.f.tld >- _dmarc.f.tld >- _dmarc.tld > > Let's imagine that the Domain Owner for f.tld publishes this DMARC record: > >- v=DMARC1; p=none; psd=n; rua=mailto:f...@f.tld; > > but they allow for distributed, rather than central, administrative > control, and therefore those who manage c.d.e.f.tld publish a DMARC record > like this: > >- v=DMARC1; p=reject; psd=n; rua=mailto:f...@c.d.e.f.tld; > > Perfectly valid configurations as DMARCbis is currently written. The > plausibility of same is unknown, but because RFC 7489 didn't contemplate > organizational domains as anything other than domains one level below the > domains on the PSL, it's not likely anyone ever tried to publish a DMARC > record at c.d.e.f.tld. > > If we leave N at 5, the organizational domain and thus the intended DMARC > policy for a.b.c.d.e.f.tld won't be discovered, as it's published at > and that query will be skipped by the Tree Walk. > > My argument therefore for N=8 is to support distributed policy settings for > RFC5322.From domains with eight or more labels and therefore organizational > domains with seven or fewer labels, with 8 chosen to allow for one more > label than has been currently observed. > > I will post a separate thread about the meaning and usage of the 'n' value > for the 'psd' tag, because regardless of where we land on N for the tree > walk, I think the description of the value of 'n' for the 'psd' tag is > inadequate, a conclusion I've arrived at during the writing of this reply. I am confused. Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be found either in this case. Why do we need to support something that is currently unsupported? We picked n=5 to allow the current org level record to be detected by the tree walk. It's true that the tree walk provides some additional flexibility for subordinate organizations within what we would call a DMARC org domain based on RFC 7489, but that was by no means anything we ever described as a feature or a goal. Even if some organizations have very deep DNS trees, the fact that some entity uses a.b.c.d.e.f.tld doesn't affect DMARC. The record for the top level of their organization will still be found. In any case, any domain, at any depth in the tree can publish their own DMARC record if they need some special thing. The value of N does not affect that at all. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
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.
--
Todd Herr | Technical Director, Standards & Ecosystem
Email: todd.h...@valimail.com
Phone: 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
Re: [dmarc-ietf] Thoughts on choosing N
On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Todd, can you clarify this? > > N is not concerned with maximum labels on a subdomain. We are interested > in the maximum length of an org domain used for relaxed alignment. > > If this client wants to use level 7 as an org domain and apply relaxed > alignment for 8-label domains, then N needs to be 7. If the client's > lowest-desired org domain is at or above 4-labels, then N=4 is sufficient. > Similarly, if the7-label domain only needs strict authentication, then N=7 > is not needed. > > Has this or another client genuinely chafed at the insufficient > granularity of the old PSL? > My understanding of the Tree Walk is that in DMARCbis it is the defined method for performing two separate jobs: - Discover the controlling DMARC policy record for the RFC5322.From domain in a given email message; this controlling DMARC policy will be found at either the RFC5322.From domain, the organizational domain for the RFC5322.From domain, or the PSD of the RFC5322.From domain. - Determine the organizational domains for the SPF domain,and the DKIM domain in a given email message, in order to determine whether the domains are in relaxed alignment with the RFC5322.From domain As I wrote in an earlier message, we have data showing use of seven label domains in the RFC5322.From domains; it's not a lot of data, but it's there. So, in my current scenario with an RFC5322.From domain of a.b.c.d.e.f.tld, DMARC Policy Discovery would be done by querying for these five (5) records: - _dmarc.a.b.c.d.e.f.tld - _dmarc.d.e.f.tld - _dmarc.e.f.tld - _dmarc.f.tld - _dmarc.tld Let's imagine that the Domain Owner for f.tld publishes this DMARC record: - v=DMARC1; p=none; psd=n; rua=mailto:f...@f.tld; but they allow for distributed, rather than central, administrative control, and therefore those who manage c.d.e.f.tld publish a DMARC record like this: - v=DMARC1; p=reject; psd=n; rua=mailto:f...@c.d.e.f.tld; Perfectly valid configurations as DMARCbis is currently written. The plausibility of same is unknown, but because RFC 7489 didn't contemplate organizational domains as anything other than domains one level below the domains on the PSL, it's not likely anyone ever tried to publish a DMARC record at c.d.e.f.tld. If we leave N at 5, the organizational domain and thus the intended DMARC policy for a.b.c.d.e.f.tld won't be discovered, as it's published at _dmarc.c.d.e.f.tld and that query will be skipped by the Tree Walk. My argument therefore for N=8 is to support distributed policy settings for RFC5322.From domains with eight or more labels and therefore organizational domains with seven or fewer labels, with 8 chosen to allow for one more label than has been currently observed. I will post a separate thread about the meaning and usage of the 'n' value for the 'psd' tag, because regardless of where we land on N for the tree walk, I think the description of the value of 'n' for the 'psd' tag is inadequate, a conclusion I've arrived at during the writing of this reply. -- Todd Herr | Technical Director, Standards & Ecosystem Email: todd.h...@valimail.com Phone: 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
Re: [dmarc-ietf] Thoughts on choosing N
On Tuesday, April 16, 2024 2:24:07 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >In the case of a.b.c.example.com and example.com is in the PSL, the DMARC > >records in a.b.c.example.com (if present) and example.com (otherwise) are > >consulted. The only way to get to b.c.example.com or c.example.com would > >be to add them to the PSL. These are what I meant by intermediate > >records. > > I get that but in fact there are lots of PSL records underneath .com, more > than 900 of them. > >I don't find cases where it looks like such things have been added to the > >PSL, ... > We know there aren't any in the PSL more than 5 levels deep but there > are plenty shallower than that. I have no idea how many of them are > used for mail but a lot of them look plausible. ... Yes. I think there's a clear argument for n=5. The claim is we need a bigger number. If that were true, I would expect to see longer PSL entries that are plausibly related to email. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N (choose 6)
A look at my data was helpful. Organizational alignment means that N labels match exactly. Relaxed alignment means that at least one of the names is longer than N. Those rules are easy to check on my historical data. I have examples of mismatched domains with 4 matching labels. I also have examples of exact-match domains with 5 matching labels. Strict alignment does not matter for N, because it will produce PASS on any detected policy. So my data suggests a maximum possible N of 4. My message volume is almost exclusively 2LD domains, so a 4-label match represents a partitioned organization at Org+2. This has parallels in the known private registry structure, where Private Registry clients are mostly at Registered Org +1 and sometimes at Registered Org + 2. If we choose N=6, we provide Org+2 partitioning to organizations with 4-label domains. Based on this, I don't see any reason to go higher, and limiting partitions to Org+2 seems easy to defend conceptually. (As an aside, my longest From address was 10 labels, from a spammer, and it aligned with a 3-label Mail From address.My longest Mail From addresses were from *.bnc.salesforce.com, but I stopped counting at 9 because the salesforce Mail From addresses do not align with the From address at all.) Doug Foster On Tue, Apr 16, 2024 at 12:03 AM Scott Kitterman wrote: > > > On April 16, 2024 2:36:53 AM UTC, John Levine wrote: > >It appears that Scott Kitterman said: > >>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. > >>> > >>Modulo we do need to explain why 8. Related, I think we also need to > explain why the reporting address thing is important for DMARCbis since > having an intermediate level record isn't > >>currently supported by DMARC. > > > >What do you mean by intermediate level record? Whatever the tree walk > finds is > >by definition the org domain. > > > >There are some PSL entries with one below another so it's not > unprecedented. > > That's true, although that pattern in the PSL doesn't seem very relevant > to email. > > In the case of a.b.c.example.com and example.com is in the PSL, the DMARC > records in a.b.c.example.com (if present) and example.com (otherwise) are > consulted. The only way to get to b.c.example.com or c.example.com would > be to add them to the PSL. These are what I meant by intermediate records. > > It's, of course, different for DMARCbis. There we walk up the tree, so > those get checked and as you say, the first one we find is the org domain. > > The claim, as I understand it, is that for big orgs that go deeper than 5 > levels (in fact up to 8), it is somehow critical to have different > reporting addresses (which leads to a need for org domains 6, 7, and 8 > levels deep). > > I don't find cases where it looks like such things have been added to the > PSL, so I'm skeptical that this is really critical. It might be helpful > and it might even be a good idea, but I fail to find the evidence I'd > expect to find if it were actually critical for a domain operator to be > able to do this. > > I agree that we ought to just get this done, but without a rationale for 8 > that holds water, I think we're better off deciding to stick to the number > (5) that we have an articulable rationale for. > > I'm sure it will take some time to get through the last call comments, so > I imagine that we can wait a bit for more information before deciding > without delaying the overall progress. > > Scott K > > ___ > 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
