Re: [dmarc-ietf] Tree walk nits

[Scott Kitterman <[e-mail]>]

On Tuesday, June 21, 2022 7:42:01 PM EDT John R Levine wrote:
> I've been staring at the tree walk description and see a few places where
> it could be clearer, and one place where I think it's wrong, left over
> text from the old downward walk.
> 
> If this discussion isn't clear enough I can do a pull request with the
> proposed changes.
> 
> In the description of the tree walk in sec 4.6, it appears that you always
> walk up to the root even if you've already found the record you're going
> to use. In steps 2 and 7 I would add "If one valid record remains, stop
> and use that record."
> 
> The part with the numbered list in sec 4.8 is confusing.  Step 3 says
> "select the record for the domain with the fewest number of labels" which
> I think is wrong, should be the most labels.  I would rewrite the whole
> section to say to use the record found by the tree walk, and the three
> numbered items say how to interpret it.

As written, I think it produces the correct result.

The trick is that there isn't just one tree walk.  There are up to three.  You 
need to know:

Org domain for 2822.From
Org domain for 2821.MailFrom
Org domain for d= domain

Let's take the following example (I know things will essentially always not be 
this complicated, but we need to assess the worst case):

2822.From domain = example.com
2821.Mailfrom = mail.example.com
d= domain = internal.dkim.example.com

Using RFC 7489, com is in the PSL, so they all have the org domain 
example.com.  They are aligned (same org domain) (see 3.2.4 in the draft).

Let's say each of example.com, mail.example.com, internal.dkim.example.com, 
and dkim.example.com have a DMARC record with no psd= tag and assess using 
DMARCbis:

Based on the description in 4.8 for organizational domain discovery you would 
do the following walks (in practice this would collapse to fewer steps, but 
showing the redundant bits for completeness/clarity):

2822.From
example.com = record
com = no record

2821.Mailfrom
mail.example.com = record
example.com = record
com = no record

DKIM d=
internal.dkim.example.com = record
dkim.example.com = record
example.com = record
com = no record

As written you take the domain with a (non-PSD) DMARC record with the fewest 
labels, which would be:

2822.From
example.com = record

2821.Mailfrom
example.com = record

DKIM d=
example.com = record

They all have a common organizational domain, so they are aligned and the 
result is identical to RFC 7489.  If you stopped after the first match they 
would all be different and nothing would align.  If don't stop, but you take 
the longest match, they are all different and they don't align.

I'm all for making it clearer, but I think what's there provides the correct 
result.

For policy discovery (4.7) it's different.  It says use the p= tag of the 
2822.From DMARC record (if any) or the p/sp/np tags of the org/psd domain it 
it doesn't.  If all we were doing was policy determination, then stopping at 
the first match would work.

At least this is my assessment, maybe I am missing something?

Scott K

_dmarc.a.b.c.d.e.mail.example.com_dmarc.e.mail.example.com_dmarc.mail.example.com_dmarc.example.com_dmarc.com