Re: [dmarc-ietf] PSD flag vs Version bump

[Scott Kitterman <[e-mail]>]

On June 10, 2023 9:04:57 PM UTC, John Levine <[e-mail]> wrote:
>It appears that Scott Kitterman  <[e-mail]> said:
>>
>>What's the incentive that any existing DMARC users (senders or receivers) would have to invest additional resources in another email
>>authentication protocol?
>
>We have two of the largest mail operators in the world saying that if
>they can't tell which org domain scheme domain expects, they won't
>implement the tree walk. We have to do something or we are wasting our
>time.
>
>So how about this: in the tree walk, you look for DMARC records that
>have an explicit psd=y/n/u tag. If you find at least one record with a
>tag, you use the new scheme. If you find no records with a tag, you
>fall back to the old scheme. I think this will let people do
>everything they can do with the current tree walk, while being
>backward compatible. If you want a domain to be an org domain you put
>psd=n, if you want the tree walk to skip it and keep looking, you put
>psd=u, and if it's one of the 0.001% of domains that actually is a
>PSD, you put psd=y.
>
>We already added DiscoveryType to the aggregate report schema so we
>are OK there.

Generally, I think it's fine, but specifically, I think we need to be careful about the language.

Using PSL is 7489DMARC.  Using tree walk is DMARCbis.  I don't think we want to include all the PSL stuff in the bis document, so I think we need to avoid talking about it.

We can update the tag description and include a statement that the presence of the tag is an indication that the record has been evaluated as being compatible with DMARCbis (which is I think what they actually want).

At the rate we're going on the description of overall interoperability status of DMARC, I think there's plenty of time to work out the details.

Scott K