> I don't see any hope that people will back away from the perceived security > benefits of DMARC to > accommodate mailing lists, even if we publish Barry's language.
But here's where we're missing my main point, so I'll highlight it: The spec needs to say what the right thing is for the protocol to do, and what the right way to deploy it is to avoid damage to existing services. "MUST NOT use p=reject for a domain that hosts general-purpose user email" is the right thing to say. Saying the right thing is not dependent upon whether some large senders will decide not to abide by it -- they have the right to make their own decisions, and whether they back away or not isn't the point of this text. We should not have an IETF proposed standard that can knowingly break existing services without strong normative text that warns against deploying it that way. I have no illusion that certain large senders will change, and I don't care whether they do.[1] I care that our standard says what it should say to maintain interoperability and avoid damage. Barry [1] Well, I *do* care, really, but I "don't care" for the purpose of this particular discussion. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
