On July 17, 2022 10:40:47 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>On Sat 16/Jul/2022 18:00:25 +0200 Scott Kitterman wrote:
>> On Saturday, July 16, 2022 11:56:04 AM EDT Alessandro Vesely wrote:
>>> On Sat 16/Jul/2022 17:34:24 +0200 John Levine wrote:
>>>> It appears that Scott Kitterman <skl...@kitterman.com> said:
>>>>> I think the proposed change is incorrect. To pick a real example, gov.uk
>>>>> is a PSD with a DMARC record. It's one that I expect will add psd=y
>>>>> once the tag is assigned.
>>>>>
>>>>> There is no benefit from preventing gov.uk from sending mail and having
>>>>> it pass DMARC. We have discussed this concept before. With the draft
>>>>> as it stands, even if gov.uk had psd=y in its DMARC record, if the
>>>>> 5322.From, 5321.MailFrom, and DKIM d= were all gov.uk, uk.gov would be
>>>>> the organizational domain. With your change there would be no
>>>>> organizational domain determined and so nothing would align. Why would
>>>>> we want to do that?
>>>>
>>>> I agree with Scott, and considered scenarios like this when I wrote the
>>>> current text.
>>>>
>>>> A better example is uk.com which is a PSD, and has MX, SPF, and DMARC
>>>> records. It already has an np= tag so I expect they'll add psd=y once
>>>> it's in the registry.
>>> No. Since there's a record, a tree walk for d=uk.com will determine
>>> the organizational domain correctly based on point 3, with or without
>>> the change proposed. That change, therefore, does not prevent a PSD
>>> from sending DMARC-compliant mail.
>>>
>>> Instead, a tree walk starting at d=com would determine that com is the
>>> organizational domain unless my change is accepted. (Yes I know that
>>> d=com won't verify, that's not the point.)
>>
>> No. You'll never get to step 3.
>>
>> In step 2 it says to stop if you find a DMARC record with psd=y and that the
>> organizational domain is the one below the psd=y domain. In the case of
>> uk.com (or gov.uk) there is no domain one below the psd=y domain, so step 2
>> yields no result and you never get to step 3.
>
>
>This thread proves that we (you and me, but probably the whole WG) didn't grok
>the tree walk well yet. (We need more examples.)
>
>My understanding is that, since John's final tweak of June 26, psd=y on the
>input domain is discarded. Which step 2 are you talking about? The one I see
>is:
>
> 2. If a valid DMARC record, other than the one for the domain where
> the tree walk started, contains the psd= tag set to 'y' (psd=y),
> the Organizational Domain is the domain one label below this one
> in the DNS hierarchy, and the selection process is complete.
>
>Without John's change in the other step 2, that of Section 4.6, this step 2
>should have been worded differently, but the concept is that a PSD which sends
>mail or signs messages should be treated as a regular (sub)domain, /within/
>the process. That is, without taking recourse to the statement, put after the
>process steps:
>
> If this process does not determine the Organizational Domain, then
> the initial target domain is the Organizational Domain.
That's the one.
>Recall that you corrected me on March 21st:
>mailarchive.ietf.org/arch/msg/dmarc/VmB5_CMIrm9rulqlkILMMEw_nW8
>
Yes.
I don't understand what you are arguing for the WG to do. I believe that you
are agreeing that the current text gets the desired result and yet you still
want to change it because it should have been different if Section 4.6 was
different.
I think the tree walk and related org/policy domain discovery are sufficiently
specified. I have running code which I think is an good indicator of
sufficiency.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
