On January 25, 2022 5:36:23 PM UTC, Alessandro Vesely <[email protected]> wrote:
>On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote:
>> On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely <[email protected]>
>> wrote:
>>> On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote:
>>>> On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote:
>>>>> On January 25, 2022 12:46:48 AM UTC, John Levine <[email protected]> wrote:
>>>>>> It appears that Scott Kitterman <[email protected]> said:
>>>>>>> What I implemented is roughly:
>>>>>>>
>>>>>>> For policy determination, first check the From domain, if that has a
>>>>>>> DMARC
>>>>>>> record, then that's the policy domain. Otherwise, tree walk up to the
>>>>>>> apex
>>>>>>> looking for DMARC records. First domain you find with a record is
>>>>>>> policy
>>>>>>> domain, use the policy (p=, sp=, np=) from that domain's DMARC record.
>>>>>>> This matches my interpretation of dmarcbis-04.
>>>>>>>
>>>>>>> For org domain determination (for alignment), if any of the records
>>>>>>> retrieved during the policy search have psd=y, then add one more label
>>>>>>> and that's the org domain (as written). From there it's anyone's guess.
>>>>>>> Unlike John, I continued down the tree and made the first match the org
>>>>>>> domain.
>>>>>>
>>>>>> Seems reasonable. What's the point of going more than one level below
>>>>>> the
>>>>>> PSD? Make it look more like a pure tree walk?
>>>>>
>>>>> Yes. For consistency. You'd walk down until you hit a non-psd record or
>>>>> the limit. Stopping at one more after the psd=y record is an optimization
>>>>> for a relatively rare case of a PSD record. Other than that case you have
>>>>> to keep going until you find a DMARC record or hit the limit, since
>>>>> there's
>>>>> no knowing what's a PSD otherwise.
>>>>
>>>> The attached change would solve the problem, at least to a first
>>>> approximation.
>>>> The wording could be tightened up, but this is at least a complete
>>>> description.
>>>
>>> I don't think "in the reverse order" makes much sense. Usually, I
>>> don't walk downward on a DNS, so the meaning of "reverse" is not clear
>>> to me. Phrases like "toward the root" or similar might be clearer.
>>>
>>> Then, may I insist on having role=psd rather than psd=y? It can
>>> better the heuristic.
>>
>> I agree it needs work. I think the tree walk section needs to be updated to
>> be bidirectional. Walk up to find policy and walk down to find org. I'm
>> only suggesting that this be added for now as an interim step to fix a clear
>> gap in -04.
>
>
>As John said, the gap is that PSD domains are not going to publish
>psd=y. Maybe, eventually, the ones interested in DMARC will.
>However, this is going to be a problem during rollout.
>
>
>> My impression is that the group is generally okay with PSD=y. I prefer it
>> over your suggestion. My strongest preference is that we pick something,
>> stick with it, and move on.
>
>
>Would you mind elaborating on why you prefer psd= over role=, apart
>from the latter arriving late?
>
>Besides, do you agree that finding psd=n can save a lookup in some cases?
I think psd is more precisely constrained to the need. Role is rather open
ended. I have no idea what it covers.
I think arriving late and not having a clear technical advantage is enough. If
this WG is ever going to achieve its goals, we need to decide stuff and not
keep revisiting things.
Ideally, I'd like to get this nailed down so we can get an early (RFC 7120)
assignment of the tag. This will help us with getting things moving forward.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
