The way I evaluate a design is to first look for logical consistency or inconsistency. If there is obvious inconsistency, then the design needs to be re-evaluated to correct the problem. Once a design appears to be logically consistent, we do data analysis to validate our design. The criteria for DMARC PASS (the identity is authentic) and NP (the identity cannot be authentic) should be aligned so that they produce results that are not in direct conflict. We seem to have an obvious design hole, with an obvious solution, which is what I proposed.
As to examples, my data set is large enough to be informative but not large enough to be determinative. I see very little forwarded mail, so my data set is not expected to answer your specific question. I do see legitimate messages using From domains that are not in DNS. The existence of legitimate non-DNS names, and the lack of a suitable compliance mechanism for those names, is what got me concerned about this test definition. I have provided the group with examples, as has someone else. Yet, the test specification has not been modified to address that concern. How do you think that makes me feel? A year after raising my concerns, I am still trying to get a collaborative discussion started about what the optimal test looks like. In a collaborative discussion, those who are happy with the status quo convince the skeptics to come on board, listen to their concerns, acknowledge them, and do what they can to accommodate those concerns so that consensus can be achieved. I am willing to be convinced, but I am skeptical and I am looking for some collaboration. Doug On Fri, Dec 17, 2021 at 11:00 AM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> We both know exactly what causes messages to lose credentials: >> - A record that is only SMTP validated, which is then forwarded without >> SMTP rewrite >> - A message which is forwarded after modifications, such as the >> ubiquitous "this message received from an external source". Of course, it >> could be a mailing list modification also. >> > > Yes, I'm aware of this aspect of message authentication. That wasn't my > question. > > The point of an NP test was, in my understanding, to identify names that >> were never valid in any circumstance, like 'junk.junk.ietf.com", without >> any dependencies on message path. Why would we want to create a >> duplicate of the mailing list problem? >> > > I understand the first sentence. I do not see how the second follows. > > However, if MX/A/AAAA is really the right test for fraudulent identifiers, >> then we need to open a CVE against all implementations of RFC7489, because >> implementations based on that spec have been confidently asserting honest >> identifiers without checking the MX/A/AAAA condition. >> > > I don't follow this either. > > Why do I need to provide case studies? Isn't the burden of proof on the >> team that told us that MX/A/AAA was absolutely the best possible test to >> use? >> > > Because I'm trying to understand your concern. Sure, it's reasonable for > us to question our assumptions. But if I don't understand how you get your > premises, or how your premises lead to your conclusions, am I being > unreasonable when I ask for clarification or concrete examples? > > -MSK >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
