Steven Jones observes correctly that "DMARC is a _cooperative_ endeavor" between the Domain Owner and the Mail Receiver. This is true once DMARC is operational.
But before DMARC becomes operational, it is a cooperative effort between the mail system owner and the software developers. By defining functional groups, I believe IETF can facilitate the development of usable products and facilitate the intelligent purchase of suitable products by organizations that wish to implement DMARC. As a particularly bad example: I have access to a product that has a single checkbox for enabling DMARC. When it is on, messages that do not pass DMARC verification are blocked or quarantined, When it is off, DMARC is not evaluated. It provides no ability to test the impact of DMARC evaluation prior to activating the feature. The logging subsystem is just a capture of the SMTP chatter, so finding all of the DMARC failures would be difficult. Depending on the reject codes used, it may not even be possible to identify which messages are blocked because of DMARC. Once found, there is no mechanism for creating exceptions to correct false positives. There is no configuration of whether SPF evaluation is strict or relaxed. In short, the implementation is useless in the real world. But it can be marketed as "implements DMARC" (without outbound reporting), simply because the developers coded something that complies with part of the specification.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
