On Mon, May 17, 2021 at 10:19 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> Fatal flaws with the MX/A/AAAA test > > - During DMARC policy evaluation, the process may have retrieved an > SPF policy or a DKIM public key which is associated with the RFC5322.From > domain or one of its descendants, even though the SPF test did not pass and > any relevant DKIM tests did not verify. Obtaining such data provides > evidence that the domain name is in use by the domain owner and therefore > the failure should be handled as SP rather than NP. But adding this > condition into the evaluation means that the evaluation is no longer > deterministic, since the pool of supplementary information can vary from > one message to the next.. > > In what way does the SPF and DKIM information fetched for one message taint the resolution of the message coming after it from the same domain? > > - If the RFC5321.MailFrom domain is a parent of, or unrelated to, the > RFC5322.From domain,. then the DMARC evaluation will not have checked for > an SPF policy on the From domain. The presence of an SPF policy indicates > that the domain does exist and that the domain owner has implemented this > sender authentication mechanism. If SPF is present, the policy > evaluation should be SP, not NP, but the SPF policy is not considered by > the MX/A/AAAA rule. > > The same is true for an unaligned DKIM signature. To me, this just means trying to piggyback the MX/A/AAAA semantics off of the presence of DKIM and SPF results is fallible. Problematic ambiguity, depending on the presumed justification for the > MX/A/AAAA test > > - Both MX and SPF can be used to allow or block traffic. MX can > block message delivery using a host name of "." (RFC 7505) or any other > invalid or non-routable name. SPF can be used to block traffic if the > policy is "-ALL". If the selection of MX is intended to score the domain > for a probability that it is used for email, then the block signals should > be considered as indicators of NP, and the non-blocking signals should be > considered as SP. But then what to do if the signals are not in the same > direction? > > I don't follow this at all. A "." MX is an indication that the domain exists but wishes to publish that it offers no way to receive mail. It might send perfectly legitimate and possibly even desirable email. An SPF "-all" is an indication that the sender handles all of its own mail (or at least thinks it does). It, too, might send perfectly legitimate and possibly even desirable mail. Neither of those strike me as equivalent to "this domain doesn't exist for the purposes of email". > - > > Constraints imposed by DNS > > DNS Queries for a specific RR type produce one of three results > > - Data: An entry matches the requested name, exactly or by wildcard, > and also matches the requested RR type. > - NoData: An entry matches the requested name, exactly or by > wildcard, but the requested RR type cannot be matched > - NXDomain: No entry exists for the name, either exactly or wildcard, > for any RR type. > > When multiple query types are checked for the same domain name, the > multiple three-way results must be consolidated into a single binary > conclusion: SP or NP. That conclusion will be heavily influenced by > assumptions about how domain administrators will configure their domains, > and such assumptions are difficult to apply globally. > DMARC is clear about this, in my opinion: RFC 7489, Appendix A.4, says NXDOMAIN and NODATA are equivalent because in both cases "no such records were published". If you're arguing that this definition is hurting DMARC's efficacy, I'd love to see some data. The one exception to this problem is the NS query. It acts as a query for > type=ANY with the specific results discarded. As a result, it has only > two outcomes: > > - Data: The name is used in DNS (policy applied = SP) > - NXDomain: The name is not used in DNS.(policy used = NP) > > Interesting. Are there any data to suggest this is more effective or accurate than the MX/A/AAAA test? -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
