Re: [dmarc-ietf] Thoughts on choosing N
> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely wrote: > > On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: >>> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman >>> wrote: >>> 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. > >> I don't share your understanding here. I interpret some of the text of >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do >> away with the PSL and Org Domain entirely; just walk the tree" to at least >> imply that the tree walk was designed to provide this flexibility [...] > > > If we wanted to provide high flexibility, then we'd have designed an > inheritance system whereby, for example, policy or rua address can be > inherited from parent domains. John would 've called it mission gallop. > > >>> 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 > >> Fair enough. You're correct that a DMARC policy can be published for any >> specific domain used as the RFC5322.From domain, so perhaps a bit of text >> in the Tree Walk section describing the really deep use case and >> the solution for it might be a compromise. > > > We may say the system is harsh by design. You can rely on the org domain > settings or define your own in the From: domain. Flexibility to fetch values > from intermediate domains is not provided. I’m imagining a little chaos if such flexibility were shoe horned in. Rare, sure, but frantic, baffled stress for a few unlucky souls. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
On Apr 17, 2024, at 6:33 AM, Todd Herr wrote:On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> 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 domainThe Organizational Domain of the RFC5322.From domainThe Public Suffix Domain of the RFC5322.From domainMeanwhile, section 4.8, Organizational Domain Discovery, gives the following three options for where the Organizational Domain is:DMARC record with psd=nThe domain one level below the domain with a DMARC record with the tag psd=yThe 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?The default for the psd tag is 'u', not 'n'.See https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-formatThank you and I’m not sure why I was thinking n. I guess I figured if it’s not a PSD which should publish an explicit y. My logic just looking at the tree walk makes no sense.___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
It appears that Todd Herr said: >When DMARC was first developed, there was concern about DNS load and >needing to minimize DNS lookups. Operational expertise now shows that this >is no longer cause for concern. > >Short circuiting a tree walk has led to many issues, like a reliance on the >PSL, complicated algorithms for Org Domain discovery, ... I have to say I have some sympathy for just taking out the limit and if you sometimes need to walk umpteen levels on stupid domains, so be it. Or I suppose say if there's more than 8 components in the name, just stop because no domain actually used for mail is that deep. Take out the skip stuff. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
On Tue 16/Apr/2024 23:17:44 +0200 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 correct text would be something like so:
The DMARC policy record is published for a domain which is the
Organizational Domain for itself and its subdomains (up to one which
in turn publishes a psd= tag with value not u.) 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.
(A parent PSD not publishing any DMARC record is fine.)
Note that intermediate records are discarded.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: 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. > I don't share your understanding here. I interpret some of the text of https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do away with the PSL and Org Domain entirely; just walk the tree" to at least imply that the tree walk was designed to provide this flexibility [...] If we wanted to provide high flexibility, then we'd have designed an inheritance system whereby, for example, policy or rua address can be inherited from parent domains. John would 've called it mission gallop. 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 > Fair enough. You're correct that a DMARC policy can be published for any specific domain used as the RFC5322.From domain, so perhaps a bit of text in the Tree Walk section describing the really deep use case and the solution for it might be a compromise. We may say the system is harsh by design. You can rely on the org domain settings or define your own in the From: domain. Flexibility to fetch values from intermediate domains is not provided. Indeed, even if we had N=8, DMARC records at b.c.d.e.f.g and c.d.e.f.g would be discarded unless they contained psd=y or psd=n. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Thoughts on choosing N
On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman wrote: > > 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. > I don't share your understanding here. I interpret some of the text of https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/79, "Do away with the PSL and Org Domain entirely; just walk the tree" to at least imply that the tree walk was designed to provide this flexibility, to wit: When DMARC was first developed, there was concern about DNS load and needing to minimize DNS lookups. Operational expertise now shows that this is no longer cause for concern. Short circuiting a tree walk has led to many issues, like a reliance on the PSL, complicated algorithms for Org Domain discovery, many types of domains (PSDs, per https://tools.ietf.org/wg/dmarc/draft-ietf-dmarc-psd/) being unable to utilize DMARC even though they wish to, and larger organizations (such as universities and governments) that are comprised of sub-organizations that use subdomains having material problems getting everything authenticated. All these issues disappear, and DMARC becomes a lot simpler conceptually, if DMARC simply walks the DNS hierarchy for the exact sending domain down to the TLD until it finds a DMARC record, and stops. It's the second paragraph, specifically the "and larger organizations..." bits to which I'm referring here. > 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. > > Fair enough. You're correct that a DMARC policy can be published for any specific domain used as the RFC5322.From domain, so perhaps a bit of text in the Tree Walk section describing the really deep use case and the solution for it might be a compromise. -- 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] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk
On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz wrote:
>
>
> On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> 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.
>
>
> 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?
>
>
The default for the psd tag is 'u', not 'n'.
See
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-30.html#name-general-record-format
--
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
