On Tue, Jan 18, 2022 at 9:36 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> 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. > RFC 7489 and DMARCbis both say that if a policy record is not discovered, then "Mail Receivers SHOULD NOT apply the DMARC mechanism to the message." The domain owner is always subject to the rules and policies of the mail receiver, regardless of whether or not a DMARC policy is published, but a domain owner does have the ability to exert some control over whether or not the DMARC mechanism is applied to any message using its domain. The domain owner has no control over how the results of that DMARC mechanism application are used, but it does have the ability to express an opinion or preference on what should be done if the message fails a DMARC mechanism check. > > 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. > This is true, but any mail receiver applying a DMARC mechanism to a message for which no DMARC policy exists isn't really following the DMARC protocol. > > 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 don't know that "demolished" is a word I'd agree with. As a domain owner, I can publish a DMARC policy record for my organizational domain and have full control over the DMARC policies that exist for any subdomain, existing or not, of that organizational domain, and the tree walk would stop with my organizational domain. The tree walk is, I believe, intended to allow for a policy published at b.domain.tld to apply to messages using a.b.domain.tld in the RFC5322.From domain. With RFC 7489, we don't have that, because b.domain.tld's DMARC policy is never queried for during the policy discovery process. Only _dmarc.a.b.domain.tld and _dmarc.domain.tld are queried for under the current RFC. If the intent of the tree walk is, at least in part, to allow for publishing of policy records at the PSD level and for those records to be inherited by existing subdomains (e.g., _dmarc.tld is inherited by domain.tld if domain.tld does not publish its own policy record) then I have badly misunderstood the tree walk. If that's not the intent, then the next rev of DMARCbis needs to make that more clear. > 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. > > A policy of "none" isn't useless to an evaluator; it's communicating to the evaluator that the domain owner isn't yet confident that all mail sent using its domain in the RFC5322.From header is properly authenticated, and so messages that fail the DMARC mechanism check should not be automatically assumed to be unauthorized. I would expect an intelligent evaluator to use the data point resulting from a fail with p=none differently and/or to attach less significance to such a verdict than a fail with p=quarantine or p=reject. I would further expect an intelligent evaluator to not apply the DMARC mechanism to messages for which no policy was discovered, but if they did, I would expect them to generally give little if any weight to the results because they should have no expectation that the message should pass the DMARC mechanism check, because the domain owner has given no indication that it's authenticating mail in a way that might generate a pass. Perhaps an intelligent evaluator with essentially unlimited resources would have data available to them that tracked all possible combinations of sources, paths, and domains used for SPF, DKIM, and RFC5322.From to have established a common thread for which combinations tend to pass DMARC and which don't, but that seems like a lot of work to me. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
