On Sat, Apr 1, 2023 at 2:53 AM 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. >>> >> You invoked "end user experience" in your post I responded to. " When you change the URI scheme you're using from "http" to "https", there's some complexity introduced in the implementations, but your experience as a consumer is largely the same" The end user experience wasn't exactly the same. In many cases end users couldn't access websites or couldn't visit them without clicking through warning screens that the website is insecure and/or forced to explicitly "approve" those sites. That is hardly "largely the same" experience. Sure, years after that time frame things have settled down. It is convenient to ignore or minimize what end users experienced during that transition. I'm not a fan of domains with lots of end user accounts implementing p=reject but I also recognize that in the real world things evolve. > >> 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. > And presumably you'll also find people asking when the <expletive> placing of all that crap in TXT records 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? > Looking at the real world, I'm ok with that rather than splitting hairs. If a domain sends a million transactional emails a day, has 5 end user accounts which are subscribed to a handful of maillists which all accept their mail and which starts experiencing significant direct domain abuse, are you seriously suggesting they MUST NOT implement a p=reject policy? Would you stand in front of them, wag your finger and say to their face, "Thou must not!"? What alternate solutions would you offer them? Are you planning on being the "standards police"? If not, whom do you propose should be the "standards police"? Will offenders be banished from the Internet? If there is little or no consequence for violating (a generic, not you specifically Murray) YOUR mandate, what does it actually mean? Perhaps maillists SHOULD reject mail from ALL domains with end users and which publish a policy of p=reject. Why hasn't that been incorporated into DMARCbis? If working group participants truly believe this to be anathema to interoperability then they should be clamoring for incorporating such a requirement. If you feel this strongly, where is the record of your advocating for "MUST NOT" for domains with end users implementing an SPF policy ending in "-all"? That certainly breaks interoperability through mailing lists and various forwarders if honored by validators. DMARC allows for a PASS if either aligned DKIM or SPF validates, yet it does not require that a sending domain implement both. Where is the hue and cry? Or is that hue and cry only selective in what it targets? Are you going to propose that they should be put on block lists if they aren't going to comply? How about ewe include "Receivers and Validators MUST block Sending Domains which have end user accounts AND publish a policy of p=reject." That will show those scofflaws who don't comply! For those who are so adamant about MUST NOT, are you going to block domains which violate MUST NOT? If this is so important to you, why are you going to put the words down on electrons (I'd say paper but, you know.) but nothing to inflict consequences on those who do not comply? The reality is that if a standards body puts forth standards that people choose to ignore, that standards body risks its relevance in the real world. I'm sure you have heard the old joke that the nice thing about standards bodies is that there are so many to choose from. The real world is that despite a current $125 Billion+ annual spend on cybersecurity, the Internet ecosystem is in worse shape from a security perspective than it's ever been. Email authentication is a key aspect in fighting abuse. I get that there are purists and idealists who would rather go down with the ship than find ways to resolve real world issues. I am not one of those people. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
