On Wed, Aug 24, 2022 at 2:09 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> I understand the need to limit scope, if DMARC limits its claims to what > it covers. This complaint was triggered largely with the "MUST NOT" claim > in the draft, which implied that DMARC is the all-inclusive tool for > validating the RFC5322.From address using SPF and DKIM. If it is all > inclusive, it needs to be comprehensive. If not, it should be clear that > other options are possible. I would be satisfied with changing the "MUST > NOT" into a reference to local policy, and including this language in the > scope and goals section. > This is the text in question, yes? "If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message." That's from section 4.7 in DMARCbis, and updates RFC 7489 by changing "SHOULD NOT" to "MUST NOT". Please help me understand how you arrived at the conclusion that this statement declared DMARC "the all-inclusive tool for validating the RFC5322.From address using SPF and DKIM", because I don't take that meaning. Rather, it reads to me as "If there's a DMARC policy found, do DMARC validation. If there's no DMARC policy found, don't do DMARC validation." I don't see anything there declaring DMARC to be the only way to validate the RFC5322.From domain (DMARC doesn't validate the RFC5322.From address); I would expect your interpretation (i.e., DMARC is the one true way) to be supported by text that read as follows: "If the set produced by the DNS Tree Walk contains no DMARC policy record (i.e., any indication that there is no such record as opposed to a transient DNS error), Mail Receivers MUST apply the DMARC mechanism to the message anyway." > "The combination of SPF and DKIM provide a concept for validating the > RFC5322.From address. DMARCbis defines a protocol for using this concept > with bi-directionaoll communication between the recipient and the domain > owner, using SPF, DKIM, a DMARC policy, and a reporting framework. > Validation strategies which do not use a DMARC policy, use different > alignment strategies, or do not include reporting are considered out of > scope." > > > About Decisonmaking > Both DMARC FAIL and NO POLICY create concern that the message might be a > malicious impersonation. FAIL probably adds greater weight than NO POLICY, > and .FAIL with "p=reject" adds even more weight. A reasonable solution is > to proceed with content filtering. Messages which die in that filter > provide confirmation that the message is unwanted. For messages that > survive content filtering, the decision is how to disposition the message > given the DMARC result. > I will agree that DMARC FAIL probably adds further weight than NO POLICY, and I'll also say that the DMARC result should be independent of whether or not a message is subject to content filtering. Put another way, DMARC PASS says nothing about the content of the message and whether or not it might be wanted; it only says that the use of the domain in the RFC5322.From header was authorized by the domain owner based on the results of the SPF and/or DKIM checks. > DMARC PASS means that the message is judged free of impersonation risk. > This improves the probability of acceptance by any disposition system > based on risk weighting which is why I asserted that a PASS may increase > delivery rates for a sender.) > DMARC PASS does not mean that the content is wanted mail. It only means that the domain in the RFC5322.From header wasn't impersonated. Any domain can achieve a DMARC PASS. > > If a particular domain is trusted and configured for whitelisting, > eliminating impersonation risk becomes essential. Since any domain may be > selected for whitelisting, the system administrator needs to be able to > validate any trusted message source. Much of my desire to maximize DMARC > PASS results is to minimize the complexity of providing validation via > other strategies. > DMARC PASS does not mean that the content is wanted mail. It only means that the domain in the RFC5322.From header wasn't impersonated. Any domain can achieve a DMARC PASS. > Finally, PASS simplifies risk management by reducing the volume of > messages that need to be evaluated for malicious impersonation risk. > I'm sorry, but I don't understand this statement. DMARC PASS is achieved through applying the DMARC mechanism to a message, which is evaluating the message for impersonation, is it not? > > In sum, PASS is more useful than FAIL because the result is more certain. > Tthe value of DMARC PASS seems poorly understood by the vendor community. > DMARC PASS means that the domain in the RFC5322.From header wasn't impersonated. Any domain can achieve a DMARC PASS. -- *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
