> 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 idea is MUST NOT because it harms interop with long-standing deployments. If you decide you're more important than that, you do what you want and there it is. It's as simple as that. The "then what" is that you don't interoperate with mailing lists (and perhaps other things, depending upon the exact configuration). That's the definition of MUST NOT. It doesn't mean that someone will come down on you if you do. It means you will likely fail to interoperate if you do. As to "what constitutes general purpose", if you are providing email addresses to the general public, that qualifies. If your domain is sending email only from employees, and you have policies about employees using their email addresses to conduct business, then that's a different issue. Of course, if their business involves posting to mailing lists, you have some decisions to make. Again, none of this is on pain of death. We're just talking about how to use the protocol interoperably. If you have reasons you think are important to do otherwise, you can do what you want. The protocol specification needs to define interoperability clearly and strictly. Barry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
