On June 10, 2023 9:04:57 PM UTC, John Levine <jo...@taugh.com> wrote:
>It appears that Scott Kitterman <skl...@kitterman.com> 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
