Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Douglas Foster]

When SPF/DKIM domain is a parent of the From domain, result may be aligned
or unaligned, but Tree Walk is not needed.

"Not a child" was correct as stated.  If the first Tree Walk determines
that sub1.example.com is the organization, then we are only interested in
SPF)DKIM domains that are in the sub1.example.com subtree (including exact
match or child)

DF

On Wed, Mar 13, 2024, 7:18 AM Alessandro Vesely  wrote:

> On Wed 13/Mar/2024 11:23:43 +0100 Douglas Foster wrote:
> >
> > The reality is that the Tree Walk is an inefficient and unreliable way of
> > obtaining an answer, particularly because of the risk of DNS timeouts.
>  As
> > a result, the Tree Walk should be avoided whenever possible.   In fact,
> the
> > secondary tree walks for SPF and DKIM can frequently be avoided:
> >
> > - When strict alignment is required.
> > - When the SPF/DKIM domain is not verified.
> > - When the SPF/DKIM domain matches the From domain.
> > - When the SPF/DKIM domain is a parent of the From domain.
>
>
> However, if the parent domain has psd=y it's not aligned.
>
>
> > - When a string comparison shows that the SPF/DKIM domain is not a
> child
> > of the organizational domain
>
> You mean if they have different TLDs?
>
>
> Best
> Ale
> --
>
>
>
>
>
>
> ___
> 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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Todd Herr]

On Wed, Mar 13, 2024 at 6:24 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> My unsuccessful attempt to implement to the specification has reminded me
> of my past concerns.
>
> Our document gives primacy to the Tree Walk, as if it will be used on
> every From domain, SPF domain, and DKIM domain.   The Tree Walk algorithm
> is explained in detail before any discussion of how it is used, and the
> differences between the From walk and the SPF/DKIM walks have been
> ignored.  I find that this makes the document harder to follow and less
> usable.
>
> The reality is that the Tree Walk is an inefficient and unreliable way of
> obtaining an answer, particularly because of the risk of DNS timeouts.   As
> a result, the Tree Walk should be avoided whenever possible.   In fact, the
> secondary tree walks for SPF and DKIM can frequently be avoided:
>
>- When strict alignment is required.
>- When the SPF/DKIM domain is not verified.
>- When the SPF/DKIM domain matches the From domain.
>- When the SPF/DKIM domain is a parent of the From domain.
>- When a string comparison shows that the SPF/DKIM domain is not a
>child of the organizational domain
>
> For many messages, these optimizations will mean that no secondary tree
> walk will be needed at all.   In the event that multiple secondary tree
> walks are required, additional efficiencies can be gained by prioritizing
> which signature domain is walked first.
>
> The Tree Walk is an important tool for deprecating the PSL.   But the
> oversimplification of its discussion has prevented any substantive
> consideration of either the differences between the two types of Tree Walk
> or the available optimizations to avoid performance problems.
>

Section 4.8 in DMARCbis includes this text:

==

Note: There is no need to perform Tree Walk searches for Organizational
Domains under any of the following conditions:¶ <#section-4.8-3>


   - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
  authenticated), and/or the DKIM d= domain (if present and authenticated)
  are all the same, and that domain has a DMARC record. In this case, this
  common domain is treated as the Organizational Domain.
  - No applicable DMARC policy is discovered for the RFC5322.From
  domain during the Tree Walk for that domain. In this case, the DMARC
  mechanism does not apply to the message in question.
  - The record for the RFC5322.From domain indicates strict alignment.
  In this case, a simple string comparison of the RFC5322.From
domain and the
  RFC5321.MailFrom domain (if SPF authenticated), and/or the DKIM d= domain
  (if present and authenticated) is all that is required.

==


Does that text not at least address the first three bullets you've included
here?

As for your other bullets..

   - "When the SPF/DKIM domain is a parent of the From domain." - I'm not
   sure this is a valid exception in all cases. Consider the domain
   dept.school.college.edu, which publishes a DMARC policy and has an
   organizational domain of school.college.edu. The domain college.edu is a
   parent of that domain, but school.college.edu (an organizational domain)
   and college.edu do not have the same organizational domain. On the other
   hand, if college.edu is the organizational domain, then the SPF/DKIM
   domain will align with the From domain.
   - "When a string comparison shows that the SPF/DKIM domain is not a
   child of the organizational domain" - An SPF/DKIM domain does not have to
   be the child of an organizational domain in order to have the same
   organizational domain as the From domain; it can be the organizational
   domain, as I mentioned above. Perhaps this could be written as "When a
   string comparison shows that the rightmost labels of the SPF/DKIM domain
   are not identical to the organizational domain, in which case alignment
   between the two domains is not possible."?


-- 

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] Problem with multiple policies, different alignment

[Alessandro Vesely]

On Wed 13/Mar/2024 11:23:43 +0100 Douglas Foster wrote:


The reality is that the Tree Walk is an inefficient and unreliable way of
obtaining an answer, particularly because of the risk of DNS timeouts.   As
a result, the Tree Walk should be avoided whenever possible.   In fact, the
secondary tree walks for SPF and DKIM can frequently be avoided:

- When strict alignment is required.
- When the SPF/DKIM domain is not verified.
- When the SPF/DKIM domain matches the From domain.
- When the SPF/DKIM domain is a parent of the From domain.



However, if the parent domain has psd=y it's not aligned.



- When a string comparison shows that the SPF/DKIM domain is not a child
of the organizational domain


You mean if they have different TLDs?


Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Douglas Foster]

My unsuccessful attempt to implement to the specification has reminded me
of my past concerns.

Our document gives primacy to the Tree Walk, as if it will be used on every
>From domain, SPF domain, and DKIM domain.   The Tree Walk algorithm is
explained in detail before any discussion of how it is used, and the
differences between the From walk and the SPF/DKIM walks have been
ignored.  I find that this makes the document harder to follow and less
usable.

The reality is that the Tree Walk is an inefficient and unreliable way of
obtaining an answer, particularly because of the risk of DNS timeouts.   As
a result, the Tree Walk should be avoided whenever possible.   In fact, the
secondary tree walks for SPF and DKIM can frequently be avoided:

   - When strict alignment is required.
   - When the SPF/DKIM domain is not verified.
   - When the SPF/DKIM domain matches the From domain.
   - When the SPF/DKIM domain is a parent of the From domain.
   - When a string comparison shows that the SPF/DKIM domain is not a child
   of the organizational domain

For many messages, these optimizations will mean that no secondary tree
walk will be needed at all.   In the event that multiple secondary tree
walks are required, additional efficiencies can be gained by prioritizing
which signature domain is walked first.

The Tree Walk is an important tool for deprecating the PSL.   But the
oversimplification of its discussion has prevented any substantive
consideration of either the differences between the two types of Tree Walk
or the available optimizations to avoid performance problems.

Doug Foster

On Tue, Mar 12, 2024 at 3:49 PM Murray S. Kucherawy 
wrote:

> On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula  401und1...@dmarc.ietf.org> wrote:
>
>> The DMARC Record on the DKIM signing domain is not relevant for DMARC
>> evaluation, so if the 5322.From header domain is “example.com” the
>> “adkim:r” is relevant for evaluation regarding your example setup and would
>> consider a DKIM signature domain of “sub1.example.com” as aligned. It’s
>> the same behavior as vice versa. As if the 5322.From header domain is “
>> sub1.example.com” the “adkim:s” would apply and a DKIM signature Domain
>> of “example.com” should not be considered aligned.
>>
>
> Well, Section 4.8 in -30 reads:
>
> == BEGIN ==
> For Organizational Domain discovery, it may be necessary to perform
> multiple DNS Tree Walks to determine if any two domains are in alignment.
> This means that a DNS Tree Walk to discover an Organizational Domain might
> start at any of the following locations:
>
>-
>* The domain found in the RFC5322.From header of the message being
>evaluated.
>- * The domain found in the RFC5321.MailFrom header if there is an SPF
>pass result for the message being evaluated.
>- * Any DKIM d= domain if there is a DKIM pass result for that domain
>for the message being evaluated.
>
> === END ===
>
> So it's not clear that the "d=" domain isn't relevant.  Perhaps this list
> should be ordered?
>
> -MSK
> ___
> 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

Re: [dmarc-ietf] Problem with multiple policies, different alignment

[Tobias Herkula]

But this is only for “org-domain” evaluation, the example from Doug was about 
“adkim:s vs adkim:r”, but 4.8 speaks about “psd”. If at all if “example.com” 
would have a “psd:y” entry than my first sentence would even be a necessity, as 
there should be no alignment possible between a “domain” and a 
“public-suffix-domain”. Reading through 4.8, I think a more important question 
pops up, my expectation is that PSDs cannot be aligned in sense of DMARCbis to 
the 5322.From header domain, but 4.8 does not really answer that. And I’m not 
sure anymore if that is only my opinion and what the groups intend is with 
DMARCbis in this case.

/ Tobias Herkula

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Tuesday, March 12, 2024 8:49 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Problem with multiple policies, different alignment

On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula 
mailto:401und1...@dmarc.ietf.org>> 
wrote:
The DMARC Record on the DKIM signing domain is not relevant for DMARC 
evaluation, so if the 5322.From header domain is 
“example.com” the “adkim:r” is relevant for evaluation 
regarding your example setup and would consider a DKIM signature domain of 
“sub1.example.com” as aligned. It’s the same behavior 
as vice versa. As if the 5322.From header domain is 
“sub1.example.com” the “adkim:s” would apply and a 
DKIM signature Domain of “example.com” should not be 
considered aligned.

Well, Section 4.8 in -30 reads:

== BEGIN ==
For Organizational Domain discovery, it may be necessary to perform multiple 
DNS Tree Walks to determine if any two domains are in alignment. This means 
that a DNS Tree Walk to discover an Organizational Domain might start at any of 
the following locations:
•
* The domain found in the RFC5322.From header of the message being evaluated.
•  * The domain found in the RFC5321.MailFrom header if there is an SPF pass 
result for the message being evaluated.
•  * Any DKIM d= domain if there is a DKIM pass result for that domain for the 
message being evaluated.=== END ===
So it's not clear that the "d=" domain isn't relevant.  Perhaps this list 
should be ordered?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc