On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" <[email protected]> wrote: >On Fri, Mar 31, 2023 at 5:48 PM Dotzero <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
