Yours is the most reasoned argument in support of "MUST NOT" vs "SHOULD NOT", even if I disagree with you. You recognize the issues involved with going the "MUST NOT" path even though you ultimately support it.
Michael Hammer On Sat, Apr 1, 2023 at 6:30 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Fri, Mar 31, 2023 at 5:48 PM Dotzero <dotz...@gmail.com> wrote: > > > >> > >> > >> > >>> > >>> > >>> But when you deploy DMARC and force lists to change the way they work, > >>> the experience is altered in a way users perceive as a degradation. > We're > >>> taking something significant away, and the benefit is not perceived to > be > >>> worthwhile. > >>> > >> > >> It may or may not be true for any given situation. You are assuming > facts > >> not in evidence. There are end users who do not subscribe to email > lists. > >> My wife is one such person. If users overall were truly upset as you > >> indicated, we would have expected users to flee en masse from the large > >> free webmail providers after they switched to p=reject. And yet they are > >> still around providing email services to millions and millions of users. > >> > > > >Oh, the facts are very much in evidence. There's no need to assume > >anything. > > > >Hang around any IETF meeting for a few hours. It may not take even that > >long for someone to ask when the <expletive> DMARC problem is going to be > >fixed. > > > >I guess the point that I'm trying to make is that reality is nowhere near > >> as neat and simple as some might make things out to be. > >> > >> I would support SHOULD NOT but I think MUST NOT is a bridge too far. It > >> falls into the category of King Canute commanding the waters to retreat. > >> Publishing a standard (MUST NOT) which you know <some/many> will ignore > >> reduces the credibility of a standards organization which does so. > SHOULD > >> NOT with an admonishment and explanation as to potential consequences > makes > >> more sense to me. > >> > > > >Quoting from RFC 2119 which defines the all-caps key words we've come to > >know and love: > > > >4 <https://www.rfc-editor.org/rfc/rfc2119#section-4>. SHOULD NOT > >This phrase, or the phrase "NOT RECOMMENDED" mean that > > there may exist valid reasons in particular circumstances when the > > particular behavior is acceptable or even useful, but the full > > implications should be understood and the case carefully weighed > > before implementing any behavior described with this label. > > > >If we use SHOULD NOT, as you suggest, there's an implication that there > >might be a valid reason for non-transactional mail to use "p=reject". Are > >we okay with that? > > > I think that's not quite it. > > There is clearly a valid reason. There are domains that value the > security properties of p=reject more highly than the negative effects to > interoperability. > > The challenge for DMARC is that the understanding the "full implications" > of such a choice is infeasible as the implications are not limited to the > domain in question. The choice to deploy p=reject for domains with users > that use email in varied ways impacts the entire email ecosystem, not just > the domain making the decision. > > Technically I don't think there's any question about the negative > interoperability implications so MUST NOT [because there will be > interoperability problems] is clearly accurate. It's equally true that > approximately no one is going to change their minds about publishing > p=reject if the IETF puts MUST NOT in the DMARCbis RFC. If we do it there > will be, once again, people who point and laugh about how out of touch the > IETF is with reality. > > As the meme says, technically correct is the best kind of correct. I > think it's the IETF's job to be the pedantic nerd who won't let go of an > issue that everyone else is sick of hearing about, so we should stick with > MUST NOT. I also understand why that's profoundly unsatisfying for many. > > 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
