On Sat 28/Oct/2023 16:51:27 +0200 Scott Kitterman wrote:
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely <ves...@tana.it> wrote:
You're the only one strongly opposing the idea, AFAICS, and I still don't know
why.
As to why, I don't think there's a valid use case and the proponents for this
haven't really thought it through. As an example, someone (I don't recall who)
cited the issue of domain owners that publish SPF, but can't be bothered to set
up DKIM. The implication is that this minimum effort domain owner will read
DMARCbis when it comes out and decide to update their records as a result with
the new tag. I don't think that's very realistic.
So who would use this tag then?
It would have to be a domain owner which publishes an SPF record that enables
spoofing their domain, understands SPF and DMARC well enough to know that is a
concern for DMARC and yet simultaneously doesn't know how to fix their SPF
record and does know about this new tag.
I don't think that person exists. At best this new tag is some kind of
security theater.
Perhaps your hypothetical domain owner knows how to fix SPF records, but
/prefers/ to use auth=dkim. Actually, she has to fix SPF records anyway, for
DMARC parsers which don't recognize the new tag.
Being a security theater would match the other use of auth=, to purify DMARC by
eliminating years of mumbo-jumbo SPF advice. In case that becomes a widespread
trend, DMARCter could drop SPF for good.
I think this is the only thing we're doing in DMARCbis that will actively
worsen DMARC.
No, that is t=. auth= would be backward compatible.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
