The situation will converge to two separate but unequal environments, those that prioritize security, and those that require insecurity.
As people get burned, the pro-security segment will grow and the insecure segment will find more and more restrictions on their ability to connect to their high-risk environments I see no reason to expect any other outcome. Whatever words we publish will be ignored or followed based on the camp that domains have chosen. Doug Foster On Fri, Apr 14, 2023, 9:48 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely <ves...@tana.it> wrote: > > > >> Heck, MLMs should start rejecting messages sent from domains that > publish > >> a > >> blocking policy *when they fail authentication on entry*!! > >> > > > >That's not enough to avoid the damage we're talking about. > > > > > >> From: rewriting is the de-facto standard. In DMARCbis we can only > >> substitute > >> "de-facto" with "proposed". Better methods, implying different, > possibly > >> experimental, protocols are to be defined in separate documents. > >> > > > >Are you suggesting we put that forward as our Proposed Standard way of > >dealing with this problem? It's been my impression that this is not a > >solution that's been well received. > > > > > >> Let me recall that when I proposed something like that, I was told that > >> that > >> was phase II and the WG was then already in phase III. So, let's > complete > >> DMARCbis /without cannibalizing the spec/ by saying that it MUST NOT be > >> used > >> (as it is being used already). > >> > > > >What you describe as "cannibalizing" is actually a matter of presenting > the > >correct normative advice about interoperability. So I don't agree at all > >with that characterization. > > Agreed. If people can't get over saying some domains will have > interoperability problems when that's demonstrably a technically accurate > statement (and I don't see anyone claiming it isn't), I don't see how > progress is possible. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
