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

[John R. Levine]

Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server 
used as AD, and resolvers)


They still do that?  Wow.  At least that won't screw up DMARC evaluators 
too much.


In any event, I don't think it's our job to redesign our specs for the 
benefit of people who've ignored other IETF standards.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

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

[OLIVIER HUREAU]

> I'm fairly sure they would say that behavior is extremely broken. It 
is so broken that I doubt it's actuallly happening other than in 
obscure corner cases involving ancient hardware with a thick layer of 
dust. 

Some universities' resolvers return NOERROR instead of NXDOMAIN (samba4 server 
used as AD, and resolvers) 

On others, you must wait for ~30s a SERVFAIL instead of NXDOMAIN. (I don't have 
the spec) 
And of course, all UDP packet port 53 with a different address destination than 
the official resolvers' IP are dropped 

Olivier 


De: "John R Levine"  
À: "dmarc"  
Cc: "Murray S. Kucherawy"  
Envoyé: Vendredi 15 Mars 2024 02:45:01 
Objet: Re: [dmarc-ietf] Problem with multiple policies, different alignment 

It appears that Murray S. Kucherawy  said: 
>It's alarming to hear that NXDOMAIN replies are never issued or (perhaps 
>more likely) are dropped by some software or firewalls. It completely 
>prevents any benefits of negative caching. I wonder what the DNS community 
>might have to say about this practice. 

I'm fairly sure they would say that behavior is extremely broken. It 
is so broken that I doubt it's actuallly happening other than in 
obscure corner cases involving ancient hardware with a thick layer of 
dust. 

I mean, if you don't get NXDOMAIN, every time you mistype a domain in 
a URL or an email address, your browser or mail server will just sit 
there indefinitely. Seems unlikely. 

R's, 
John 

___ 
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

[John Levine]

It appears that Murray S. Kucherawy   said:
>It's alarming to hear that NXDOMAIN replies are never issued or (perhaps
>more likely) are dropped by some software or firewalls.  It completely
>prevents any benefits of negative caching.  I wonder what the DNS community
>might have to say about this practice.  

I'm fairly sure they would say that behavior is extremely broken. It
is so broken that I doubt it's actuallly happening other than in
obscure corner cases involving ancient hardware with a thick layer of
dust.

I mean, if you don't get NXDOMAIN, every time you mistype a domain in
a URL or an email address, your browser or mail server will just sit
there indefinitely.  Seems unlikely.

R's,
John

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

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

[Murray S. Kucherawy]

On Thu, Mar 14, 2024 at 9:17 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> All of this is based on my slightly confrontational comment that "Tree
> Walk is inefficient and unreliable", which maybe needs elaboration.   My
> approach to the problem changed dramatically when I discovered, by
> accident, that a subset of DNS servers will refuse to answer queries that
> produce NXDOMAIN, and a non-response does not come with a TTL value.
> Additionally, the increase in DNS traffic of at least 100% will be
> mostly NXDomain queries, while the raw volume will also increase the
> frequency of random DNS timeouts.   All of this means that a successful
> implementation needs to have optimizations which ensure known answers are
> cached, especially if that result was obtained after experiencing timeout
> errors.I don't think the oblique reference to DNS timeouts comes close
> to documenting the severity of the problem.
>

It's alarming to hear that NXDOMAIN replies are never issued or (perhaps
more likely) are dropped by some software or firewalls.  It completely
prevents any benefits of negative caching.  I wonder what the DNS community
might have to say about this practice.  I can ask at 119 next week.  Has
anyone else observed this phenomenon?

I don't know that DMARC should talk about caching answers, since it's my
impression that applications typically rely on their resolvers to implement
caching according to DNS best practices.  DMARC caching would be largely
redundant to DNS caching, and might mess with domain owners' intentional
use of their TTL values.

-MSK, participating
___
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 Thu 14/Mar/2024 12:17:17 +0100 Douglas Foster wrote:

Your latter questions were similar to Ale's

- If the SPF/DKIM domain is a parent of the From domain, then we check its
relationship to the organizational domain.   If it is a parent of the
organizational domain, the result is unaligned.   If it is anywhere between
the organizational domain and the From domain, then it is aligned.   In
either case, the Tree Walk is no needed.



Well, you remove the leftmost label and lookup the DMARC record.  Much more 
than a string comparison.  You may call it not a Tree Walk, but it actually is. 
 The point is that you stop whether or not there's psd=y, or even no record at 
all.  An Interrupted Tree Walk.  That is:


If there is a DMARC record at the From: domain and it has no psd=y, then:
   * if DKIM domain equals From: domain, aligned, no walk (already documented),
   * if DKIM domain is a direct child of the From: domain, one must check its 
record has no psd= tag,
   * if DKIM domain is the parent of the From: domain, one must check its 
record doesn't have psd=y.



I agree an appendix could be useful, unless we think developers are so much 
smarter than domain owners that the latter deserve the pedantic thoughtfulness 
that characterizes record publishing explanations, while developers can work it 
out by themselves...



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]

Your latter questions were similar to Ale's

- If the SPF/DKIM domain is a parent of the From domain, then we check its
relationship to the organizational domain.   If it is a parent of the
organizational domain, the result is unaligned.   If it is anywhere between
the organizational domain and the From domain, then it is aligned.   In
either case, the Tree Walk is no needed.

- Exact match domains do not need the Tree Walk.   That is obvious and was
handled in one of my first bullets.Otherwise, the SPF/DKIM domain must
be a child of the organizational domain.   Determining whether a candidate
domain meets these criteria do not require a Tree Walk.

All of this is based on my slightly confrontational comment that "Tree Walk
is inefficient and unreliable", which maybe needs elaboration.   My
approach to the problem changed dramatically when I discovered, by
accident, that a subset of DNS servers will refuse to answer queries that
produce NXDOMAIN, and a non-response does not come with a TTL value.
Additionally, the increase in DNS traffic of at least 100% will be
mostly NXDomain queries, while the raw volume will also increase the
frequency of random DNS timeouts.   All of this means that a successful
implementation needs to have optimizations which ensure known answers are
cached, especially if that result was obtained after experiencing timeout
errors.I don't think the oblique reference to DNS timeouts comes close
to documenting the severity of the problem.

I have always felt that the Tree Walk should be referenced in the main body
as a concept, to focus on the decision process, and then described in
detail in an appendix, where the differences between first and second tree
walks can be presented succinctly, and some discussion of optimizations can
be included without losing train of thought.   You write really good prose
when you have room to do so.  In this case, the Tree Walk description  was
done early, because it was needed, but then it became frozen in place.

Doug

On Wed, Mar 13, 2024 at 10:04 AM Todd Herr  wrote:

> 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:¶
> <#m_5516805231390163404_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.
>
>
> 

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<http://example.com>” the “adkim:r” is relevant for evaluation 
regarding your example setup and would consider a DKIM signature domain of 
“sub1.example.com<http://sub1.example.com>” as aligned. It’s the same behavior 
as vice versa. As if the 5322.From header domain is 
“sub1.example.com<http://sub1.example.com>” the “adkim:s” would apply and a 
DKIM signature Domain of “example.com<http://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

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

[Murray S. Kucherawy]

On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula  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

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

[Tobias Herkula]

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.

/ Tobias Herkula

From: dmarc  On Behalf Of Douglas Foster
Sent: Tuesday, March 12, 2024 12:15 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Problem with multiple policies, different alignment

I have been building a DMARC implementation, starting with a simple function:
TreeWalk(domain) which returns:

  *   Policy found or not found indicator
  *   Policy Domain
  *   Organizational Domain
  *   Policy record
My thought was that the Tree Walk result was independent of the domain 
identifier being checked, but this is not true.

Assume these DMARC policies:

  *   example.com aspf:r adkim:r
  *   sub1.example.com aspf:s akim:s

When the message contains:

  *   From: u...@sub1.example.com
  *   DKIM: d=example.com
Strict alignment on the From domain makes the organizational domain 
unimportant, so the PSL lookup or Tree Walk are not necessary.   The 
organizational domain used for reporting purposes is 
sub1.example.com.The DKIM signature is not aligned.

But when the message contains the reverse, the logic gets complicated:

  *   From: u...@example.com
  *   DKIM: d=sub1.example.com
If we apply the same Tree Walk to this message, we have a problem.   The From 
domain Tree Walk returns "example.com" as the 
organizational domain, and the Tree Walk of the DKIM domain returns 
"sub1.example.com" as the organizational domain 
because of strict alignment.   So the result appears to be unaligned.

Consequently, the Tree Walk needs to be sensitive to the identifier being 
checked. If the identifier is not the From address, the Tree Walk is only 
interested in the existence of a policy and the PSL tags, and the special case 
related to strict alignment needs to be bypassed.

I don't think this case was covered in previous discussions.

Doug Foster

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