On June 29, 2022 10:16:00 AM UTC, Alessandro Vesely <[email protected]> wrote:
>On Tue 28/Jun/2022 18:46:18 +0200 Scott Kitterman wrote:
>> On June 28, 2022 4:33:15 PM UTC, Alessandro Vesely <[email protected]> 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.

>> 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.

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).

Scott K

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to