NXDOMAIN and Return-Path-Check are two different ways of identifying non-existent domains. I believe NXDOMAIN to be the better one, but since the group seemed to be in love with return-path-check, I was willing to go there. Whichever one could solve the problem best, the issue for us is that the problem has not been solved.
Prior to PSD for DMARC, the IETF role in sender authentication could be summarized as follows: "An attacker may seek to hide his own reputation and acquire a better one by impersonating another domain. This is of interest to IETF and has been addressed by the specifications for SPF and DMARC. An attacker may also seek to hide his own reputation and acquire a neutral one by impersonating a non-existent domain. This is of no interest to IETF.;" This dichotomy is hard to defend. It has been made worse by embracing PSD for DMARC. The statement must now be revised to say: "IETF is interested in attacks of the form 'otherdomain.nonexistentdomain.psd', but IETF is not interested in attacks of the form 'nonexistentdomain.otherdomain.psd'. Todd's comments suggest that the whole issue of non-existent domains is a non-problem because everybody who matters is already well protected from non-existent domains, because they have implemented non-IETF tests such as return-path-check. If this were true, attackers would move on to other strategies and PSD for DMARC would have no advocates. When we start using ARC to accept results which cannot be independently tested, we need to know what tests were peformed. Since address rewrite can eliminate the ability to reproduce earlier tests for NXDOMAIN or Return-Path, it must be part of the ARC results. The success of ARC depends on having this information included, and the success of "new" DMARC has been tied to ARC. Non-existent domain usage is not a minor issue and not an issue that is already solved. It is the elephant in the room, and it needs to be addressed. Doug On Thu, Apr 8, 2021 at 1:06 AM Murray S. Kucherawy <[email protected]> wrote: > Further to what Todd said: > > On Wed, Apr 7, 2021 at 5:04 AM Douglas Foster < > [email protected]> wrote: > >> I am hearing that we have a defacto standard to check return-path using >> MX/A/AAAA. It is implemented with sufficient breadth,that (unlike SPF) >> senders should consider it mandatory. Additionally, and more importantly >> for this group, it is presumed to be equally applicable for validation of >> the RFC5322.From, even though that address is unrelated to the >> SMTP return-path. But because the test is not explicitly documented, some >> products (my vendors) do not implement it at all, leaving a protection gap. >> > > I think I'm confused about how this ties to DMARC. What you're describing > is, I believe, a common anti-spam tactic that was in use even before SPF or > DKIM were a thing. It probably still is, irrespective of those protocols. > > However, RFC 7489's Appendix A.4 points out that earlier versions of DMARC > had such a test, but it was removed because of too many false negatives. > > >> If DMARC is to be dependent on return-path-check and inter-dependent with >> ARC, then I do not see how we can avoid producing a formal specification >> for the test and integrating it into A-R, as a co-requisite to the DMARC >> specification. >> > > How is DMARC dependent on a return path check? SPF is, but DMARC isn't. > DMARC only cares what the SPF result was, and whether the domain it > evaluated is aligned with the RFC5322.From domain. In fact, a DMARC filter > could operate correctly with no knowledge of what the return path was, > provided the A-R fields are correct and complete. > > Another perspective: If the RFC5322.From domain doesn't exist, it's not > possible for a DMARC policy to be discovered for it, nor is it possible > that SPF or DKIM will pass for it or align to it. Therefore, is such a > domain even in scope here, much less a need to describe a way to test it? > > -MSK >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
