Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-20 Thread Scott Kitterman
On Tuesday, April 16, 2024 5:17:44 PM EDT 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:
> 
>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.

Since this is a protocol specification and not a programming specification, I 
don't think we need to be so proscriptive about storing results.  My answer to 
question 2 is no, I don't think we should change it.

I am ambivalent about question 1.  Personally, I think it's fine as is, but if 
people think it's unclear, we should probably come up with something better.

Scott K



___
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

2024-04-20 Thread Scott Kitterman
On Wednesday, April 17, 2024 11:41:34 AM EDT Alessandro Vesely wrote:
> 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.

I think something like this is fine.


___
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

2024-04-17 Thread Neil Anuskiewicz
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] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-17 Thread Alessandro Vesely

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] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-17 Thread Todd Herr
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


Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-16 Thread Neil Anuskiewicz


> 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


[dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

2024-04-16 Thread Todd Herr
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