On April 13, 2023 5:49:30 PM UTC, "Brotman, Alex" <Alex_Brotman=40comcast....@dmarc.ietf.org> wrote: >> 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). > >I don’t think folks are objecting to cautionary language. I think folks are >objecting to a blanket MUST NOT. If we're going to qualify the MUST NOT with >a bunch of language, that's a bit different. The original proposal was: "To >be explicitly clear: domains used for general-purpose email MUST NOT deploy a >DMARC policy of p=reject." I'm still fuzzy on what constitutes general >purpose, or perhaps more accurately when p=reject is acceptable? Is it >acceptable to use p=quarantine in those cases? If a domain (such as >comcast.com) decides p=reject is what they really want .. then what? (I know, >we're not the protocol police..) >
The 'then what' is there will be interoperability issues. I don't see anyone claiming that's not true, despite an extreme reluctance (as I see it) to actually say it. I don't think saying [some constraining words] domains MUST NOT publish p=reject should be in any way controversial. Even if we explicitly add the implicit 'or there will be interoperability problems', it's no different. As a technical point, I don't understand why there is a problem with this. The tricky part is defining [some constraining words]. If we could get [some constraining words] defined, I think it would be useful to the community as it would help address the question of 'but I want p=reject, what should I do'. The answer is, change your domain email usage so you no longer fit the definition of [some constraining words]. It might even be as simple as [unconstrained email usage]. Then we write an appendix that explains the things to do in terms of constraints that will avoid (or mostly avoid) the interoperability issues. I feel like we are making this much harder than it needs to be. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
