On June 29, 2022 5:13:14 PM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>On Wed 29/Jun/2022 12:40:36 +0200 Scott Kitterman wrote:
>> On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>>> On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote:
>>>> On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely <ves...@tana.it> 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.
My view is that we are in a case that is sufficiently obscure that the answer
to complaints should be "then don't do that". We should move on to other
critical topics like what to call the tag.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
