I entirely agree that the DMARC result is different from the wanted/unwanted result. If my opening failed to convey that, it was not intentional. My real point was that DMARC is, or should be, for the benefit of the evaluator.
Specifically, I have trouble with the language about "Domain owners enable verification...", because it implies that DMARC is controlled by, and consequently for the benefit of, the domain owner. The evaluator does not need the domain owner's permission to use publicly available information to assess whether a particular message is or is not accurately identified. After doing so, the evaluator does not need the domain owner's permission (in the form of p=reject) to block messages which he determines to use malicious impersonation. Domain owner control, if it was ever there, has been demolished by the tree walk. Every message will have a DMARC policy applied. This new workload may have some performance impact on evaluators, so it deserves a passing mention. I thought it curious that my default policy comment received so much resistance, because it was really targeting the transition period when the PSL still has some use.. Once the PSD policies are deployed, evaluator-supplied default policies will never be activated, but the PSD policies will produce the same result.. The perspective that the domain owner is in control also appears in the latent assumption that a NONE policy is useless to the evaluator, contributing only overhead (if reporting is done) but doing nothing to help with message disposition. I have tried to explain in some detail why NONE is no obstacle to an intelligent evaluator. In many respects, DMARC is two policies, one for computing PASS and one for obtaining suggestions for handling FAIL. The extended discussion about mailing lists convinced me that even the disposition suggestions in DMARC are not very useful. DF
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
