It all depends on what problem this is trying to solve, Murray. "Name exists", as defined by NS data/nxdomain, provides a clear and simple boundary between names that are in use and names that are not in use. This is based on the principle that when a name is created in DNS, the domain administrator has the opportunity to protect it with SPF and DMARC policies if desired. A name that has never been used for any purpose cannot be protected, except with SP=reject, because all other defenses make the name used, and the scope of possible names is infinite. The purpose of the NP test is to allow domain owners to deploy NP=reject early in the DMARC process, long before they are willing to deploy SP=reject.
I do not see that MX/A/AAA creates a useful and well-defined boundary between two risk categories, which is why I asked for a justification from someone who did understand the theoretical foundation. What I hear is that nobody knows with any certainty how this test relates to a real-world boundary problem. As best I can tell, thd MX/A/AAAA test is creating and attempting to enforce a rule that "any mail domain used in a FROM address must also have a physical server for receiving messages to that mail domain." I do not see that such a requirement is either necessary or appropriate, and I do not believe that it will be true that 100% of all legitimate messages will meet this requirement. As for filtering characteristics of the two tests: - If MX/A/AAAA produces pass and SP, then the NS test will also produce pass and SP. - If NS produces fail and NP, then the MX/A/AAA test will also produce fail and NP - There is a bunch of stuff in the middle where NS produces a pass because the name is used, but MX/A/AAA produces fail because the required types of RR types are not used. If the middle area could be scored reliably, it would exclude some additional threat vectors, but I don't see reliability. The A/AAAA test is so broad that it will allow many names that are not actually mail servers, allowing the attempted enforcement to be easily defeated. I expect it will also produce false positives, as the volume of no-reply messages from ESPs is large, and such messages simply do not need an MX for the FROM domain. As I tried to observe in the previous note, the MX/A/AAAA test could score "host1.div1.example.com" as exists/SP, but "div1.example.com" as does-not-exist/NP. I just don't see any value in that level of scrutiny. In short, MX/A/AAA involves more complexity for less usable results. That is a big double negative for me. We have no data submitted on either test rule, so it is not yet a distinguishing characteristic. I think I can build filters to begin collecting that data, but my data set is relatively small. Doug Foster On Tue, May 18, 2021 at 2:19 AM Murray S. Kucherawy <[email protected]> wrote: > On Mon, May 17, 2021 at 10:19 PM Douglas Foster < > [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
