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”. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Murray S. Kucherawy <superu...@gmail.com> Sent: Wednesday, April 12, 2023 9:51 AM To: Brotman, Alex <alex_brot...@comcast.com> Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject? On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy <superu...@gmail.com<mailto:superu...@gmail.com>> wrote: To my mind, there's a substantial difference between something like TLSv1 or HTTP whose deprecation excludes you from participating in something until you upgrade, versus the DMARC situation where because of an unfortunate interaction between A (e.g., me) and B (e.g., you) through intermediary C (e.g., this list), D (e.g., someone else) is negatively impacted. Sorry, that's not quite right: You don't need "D"; if "A" sets a policy and "B" generally enforces anyone's policies, "B" will be impacted by messages from "A" transiting "C". I think your analogy would be more apt of "C" simply refused to accept anything from "A", or refused to let "B" subscribe. But that doesn't seem to be the kind of mitigation on which we've settled. And there's no way for "C" to know that "B" is enforcing until it's seen a bounce. And "C" would need to be sure about the reason for the bounce. -MSK, participating
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
