It appears that Barry Leiba  <[email protected]> said:
>> With this comment, we see the pernicious effect of using a binary psd=(y|n) 
>> token to represent a multi-valued role.    When the role indicator is 
>> missing, there is no default
>value, instead it must be inferred from the context.    Since the author of 
>the proposed text is confused on this point, it is certain that the general 
>community will be confused
>as well.
>
>I don't see that that follows at all.  Regardless of how the tag is
>formed, the text needs to specify what happens when it's not present.
>Saying, explicitly, that the default is "psd=n" if the psd tag is
>absent makes the situation quite clear, with no inference needed.

Making explicit psd=n the same as no psd would screw up the tree walk since
it would mean you always stop at the first DMARC record.  On the other hand,
there are plenty of letters, and we can make the default psd=u for unspecified.
You can even put that in your DMARC record if you want.

R's,
John

>Barry
>
>> On Wed, Mar 16, 2022 at 11:27 PM Scott Kitterman <[email protected]> 
>> wrote:
>>>
>>> On Wednesday, March 16, 2022 11:02:00 PM EDT John Levine wrote:
>>> > It appears that Scott Kitterman  <[email protected]> said:
>>> > >It took a fair amount of editing and I expect you all will have further
>>> > >suggestions, so instead of getting up to my elbows in XML, I took the
>>> > >published DMARCbis-05 text and updated it directly.  The modified version
>>> > >and an rfcdiff are attached.
>>> >
>>> > It's closer, but I think it still needs some reorganization.  I think this
>>> > is where we want to end up:
>>> >
>>> > Policy domain: if a domain has a dmarc record, that's the policy, 
>>> > otherwise
>>> > use the org domain's policy or if no org domain policy, PSD policy.
>>> >
>>> > You need to find org domains if
>>> > a) the domain has no DMARC record so you use the org domain's instead, OR
>>> > b) the DKIM domain doesn't match the from header domain and policy 
>>> > adkim=r.
>>> > OR c) the SPF domain doesn't match the from header domain and policy
>>> > aspf=r.
>>> >
>>> > To find the org domain for a domain:
>>> >   chop the domain to the last five labels and walk up the tree.
>>> >   stop when you find a DMARC record with psd or you hit the root.
>>> >   if a record has psd=n, that's the org domain
>>> >   if a record has psd=y and it isn't the original domain, the org domain 
>>> > is
>>> > the one below it otherwise the org domain is the last (highest) DMARC
>>> > record you found
>>> >
>>> > Relaxed alignment doesn't change, if two domains have the same org domain,
>>> > they're aligned.
>>> >
>>> > Minor nit: if a name has two or more DMARC records, that's invalid so
>>> > pretend it had none.
>>>
>>> Thanks.  I think that makes sense.  Based on an offlist comment I got, I 
>>> think
>>> it needs to say has an explicit psd=n in the record or something like that.
>>> Since psd=n is the default, it's implicitly true for any record that doesn't
>>> have psd=y in it.

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

Reply via email to