Re: [dmarc-ietf] Final, I hope, tweaks to the tree walk

[Alessandro Vesely <[e-mail]>]

On Wed 29/Jun/2022 12:40:36 +0200 Scott Kitterman wrote:
> On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely <[e-mail]> wrote:
>>On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote:
>>> On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely <[e-mail]> wrote:
>>> 
>>>> What can one find continuing the walk after psd=y?
>>>> 
>>>> For example, let's consider an imaginary bank, com.bank, say.  They use that domain as corporate domain, and have a DMARC record.  They also delegate zones to local subsidiaries.  One of them, uk.com.bank in turn delegates to other banks in the UK and sends mail like uk.com.  So you may end up having a DMARC record at each level:
>>>> 
>>>> bank -> psd=y,
>>>> com.bank -> psd=n or psd=u (for private use),
>>>> uk.com.bank -> psd=y.
>>>> 
>>>> Does our model support that?  How else should they set their records up?
>>> 
>>> I think that's sufficiently obscure that I doubt we care, but I think it is supported just fine.
>>> 
>>> The only nuance is that in this scenario, mail that is 5322.from uk.com.bank would have to use 5321.mailfrom and DKIM d= uk.com.bank.  Subdomains wouldn't align, which I think is fine.
>>
>>
>>However, if you continue the tree walk after uk.com.bank, you'll find the org domain is com.bank.  That way, d=whatever.com.bank in a signature would be aligned, which is not correct.
> 
> Why is it not correct?  If it shouldn't be used for alignment, then come.bank should have psd=y.


Hm... not sure.  Say you want full usage for your domain, including alignment. 
  Then you publish psd=n or u.  Delegations are done from subdomains which 
publish psd=y.  This is a logic similar to that sometimes used by mailing lists 
hosted at a domain --using @lists.example.com rather than @example.com directly.

The point is that there can be a domain with a DMARC record with psd!=y after 
one with psd=y.


>>> The operational distinction between a PSD and a non-PSD is that subdomains of a PSD are different organizations and subdomains of non-PSDs are part of the same organization.  I believe that's the correct distinction.
>>
>>Yes.
> 
> If uk.com.bank is a part of com.bank as an organization, then alignment with other subdomains within com.bank is appropriate.  If they aren't, then come.bank's record is wrong.


Uk.com.bank should've been just the base domain for UK branches of the 
commercial bank, perhaps london.uk.com.bank and the like, each one 
administratively independent of the central com.bank.  Uk.com.bank weren't 
supposed to use their domain to send mail, but they did.  This is similar to 
uk.com restricted to bank subjects.

Recall that sites like uk.com are the reason why we cannot just assume that 
PSDs cannot have MX records.


> I think you have answered the question you asked John regarding why not stop if psd=y in step 2.  The current process produces a more logically consistent result than if that constraint were added (in this admittedly contrived case).


Did I?  I don't understand John's pet example.  Why would cats.petlovers.com 
set psd=y, by mistake?  If cats and dogs have antagonistic instincts toward 
each other, perhaps they shouldn't be associated under the same administration.

Yes, the example is contrived, but since there are no rules limiting delegation 
to third parties, we cannot be sure how subdomains are going to evolve.


Best
Ale
--