Barry's comment: I don't agree with the characterization of the second group. I would say that we are partitioning messages into these two groups: - Those for which we can confirm that they originated in the domain they say they did. - Those for which we can not confirm that.
When we use P=REJECT, we assert that anything which cannot be confirmed is unacceptable. That makes for two pretty disjoint groups. If Authentication is only to be used to validate a whitelisting decision, then a one-sided test would be sufficient. In practice, the primary use for DMARCv1 is to block messages, and much of our discussion has been around the unwanted disposition that this places on mailing lists. DKIM treats an invalid signature as non-existent. It also treats a DKIM signature as fully optional. DMARCv1 changes the rules to gather more usable information from the message. DMARCv1 with P=REJECT says that a message which lacks authentication is unacceptable, and since any message might be forwarded, it has effectively made DKIM non-optional.. So we have already modified the interpretation of DKIM. I have observed that IF the domain owner indicates that all messages originate with DKIM signatures, then the presence of a signature is no longer optional at the evaluation point. As I have said previously, this provides a valid basis for partitioning messages between verified, ambiguous, and repudiated. If you accept the premise that mailing list messages should not always be repudiated, then nothing we have done up to this point has provided a reliable way to repudiate. I am saying that this is a problem that we can fix. Upward Compatibility Yes, I have gone radical, and I am no longer willing to be limited by the design limitations of DMARCv1. While DMARCv1 was apparently a great success for PayPal, I perceive it as a failure when implemented generally: · DMARCv1 has a significant problem with mailing lists, and the mailing list interest has been well represented in this group. Until my proposal, the mailing list problem remained poorly addressed, even with ARC. · DMARCv1 has poor implementation support. I remember someone presenting a statistic to this group that only 6% of DMARC policies are enforceable (p=reject or quarantine). If this is even close to correct, after 10 years of DMARCv1, it suggests a significant failure to capture the affection of domain owners. · DMARCv1 has poor product support. Many lower-end email filtering products do not implement DMARC at all, which is not terribly surprising. But several high-end solutions implement DMARC enforcement within their filter for incoming mail, while implementing DMARC violations within their secure webmail product for outbound mail. In-between these extremes are some products that implement DMARC without adequate exception methods, so the first false positive will require the feature to be disabled. I am no longer prepared to put window dressing on DMARCv1. We need DMARCbis to have a better design.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
