> I think we all understand the inconvenience that DMARC can cause to a > subset of domains, or more accurately its users.
The problem here that we're describing as an interoperability issue is not that DMARC causes problems for the users of domains that choose to use p=reject -- that would be the domain's problem -- but that it causes cascading problems for the users of *other* domains. That makes it more than an inconvenience. > 8996 has a section > about operational considerations, and discusses the impact of > systems/users that do not support TLSv1.2 and how it will break > interoperability. Can we not do similar in DMARCbis with a more > lengthy section about the implications of "reject"? Perhaps even > expand it to cover the use cases of each policy type, and the > implications of each? That's the sort of thing I proposed, and which some participants here are objecting to. I continue not to understand the objection to clear language that says that if you do <this> under <these> conditions, it will cause problems, so don't do <this>. I don't buy the idea that saying "don't do <this>" when we know that some deployers will ignore that makes us look out of touch with reality, but that *not* saying that is better (when that already *has* given DMARC a bad name in the wider Internet community). Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
