On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex <[email protected]> wrote:
> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and > the website signs records via DNSSEC. The website I want to go to breaks > their DNSSEC. My ISP cannot retrieve a record to return to my browser that > can be used. A is the browser, B is the website, C is the ISP DNS platform. > > > > I understand your point, though I think mine still has reasonable merit. > I understand the charter is to resolve the interoperability between > indirect mail and p=reject. I’m just not sure I see an intersection of > “fix indirect email” and “p=reject”. > I see what you're getting at, but I don't think they're comparable. There are a few main differences: 1) DMARC is a surprise to some actors. The intermediary in DMARC doesn't know that it's suddenly contributing to a problem. In the DNSSEC example, the ISP DNS platform knows it's participating; it is, after all, a DNSSEC-aware resolver. In DMARC, suddenly MLMs around the world have to change what they're doing and don't know they're part of a new problem. 2) DMARC causes collateral damage. In the failure you've described, "A" is simply unable to reach "B". Other users of "B" are not blocked as a result of anything "A" did. The same goes for your TLSv1 example; it stopped working, but only for the outdated client. Meanwhile, in DMARC, something "A" does causes other users of "B" to be unable to make use of "B". 3) DMARC's damage is persistent once the issue is corrected. In DMARC, once "C" decides "B" is unavailable, "C" causes "B" to do things that will degrade or prevent "A" from using "B" in the future unless "A" takes some kind of corrective action even after the outage is resolved. The blast radius is very different. Each of these individually is a barrier to adoption; DMARC suffers from all of them. -MSK, participating
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
