Re: [dmarc-ietf] "psd=" tag early assignment

[Alessandro Vesely <[e-mail]>]

On Sun 10/Jul/2022 03:05:47 +0200 John Levine wrote:
> It appears that Scott Kitterman  <[e-mail]> said:
>> On July 9, 2022 5:07:43 PM UTC, Alessandro Vesely <[e-mail]> wrote:
>>>>> Yeah, /should/!  The very fact that you yourself changed 
>>>>> your mind about how it works, without going into the hassle 
>>>>> of explaining your reasoning, ...>>>>
>>>> Um, what?  Scott and I went through some rounds of debugging 
>>>> to be sure the tree walk handled some obscure edge cases in a 
>>>> reasonable way.  It was all on this very mailing list with 
>>>> examples.  I think what we have now is OK but if you find 
>>>> something in the tree walk that is unclear or gets an 
>>>> unreasonable result, let us know, preferably with a concrete 
>>>> example.>>>
>>> I think I received all list messages (although I don't check 
>>> against your weekly count) and I read all of them.  Perhaps I've 
>>> been inattentive, but I don't recall the switch from stop on 
>>> psd=y to continue on psd=y if it's the first lookup.  Any 
>>> pointer?>>
>> I don't recall having changed this.  If you can check the 
>> previous draft revisions to see when it changed, maybe I could  
>> find it.  I'm confident that any changes to the way the tree walk 
>> works have been discussed on the list.> 
> I changed it in a pull request a few weeks ago.
> 
> If you don't stop on the first psd=y that is not the original domain,
> you get the wrong result if there are DMARC records above the psd=y.


That's undoubtedly correct.  The point I'm raising is the one at point 2 (both sections).  For org discovery, it's in the hunk tagged @@ -720,13 +722,13 @@ in the same pull request, here:
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/pull/47/files#diff-758de98ab8f970604c5891fceb8cb498ffe212c02060fdbf0e6ee5bffbb0a3cbL720

That affects messages From: psd@c.b.a, in John's example below.  In that case, the change sets the org domain at b.a (assuming that blah stands for a DMARC record) instead of c.b.a.  That is, a PSD domain itself is a regular subdomain of the org domain below.  Apart from slightly complicating the algorithm, that might be a reasonable position.  IIRC, it wasn't discussed on list.  More importantly, it isn't explained in the draft.


> I sent this example on June 21, link is
> https://mailarchive.ietf.org/arch/msg/dmarc/T-8NX63L8ilHPhHXMygKdTJ6zMM/
> 
> a NXDOMAIN (or psd=y, doesn't matter)
> b.a blah
> c.b.a psd=y
> d.c.b.a blah
> e.d.c.b.a NXDOMAIN
> 
> I think the org domain for e.d.c.b.a is d.c.b.a.
> 
> If you don't stop at the psd=y, you get b.a as the org domain which still looks wrong to me.
> 
> The description in the current draft gets d.c.b.a.


Yes.

Best
Ale
--