On Fri, Dec 17, 2021 at 6:27 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote:
> 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. > > DMARC PASS != "this email is legit" You are looking for a specific test that an email can go through which will turn a crank and at the end of it says "Yes" or "no". The text in -04 version is pretty clear: A DMARC pass indicates *only* that the RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From domain has been authenticated for that message. *Authentication does not carry an explicit or implicit value assertion about that message or about the Domain Owner. * You read "PASS" as "legit email" while I have always read it as "this variable is true". What the vendors like Agari, Valimail, Proofpoint, et al, is to collect all the variables (SPF, DKIM, DMARC, plus organization specific info) and allow the organization to tweak as needed. You are looking to solve the problem of legitimate email. DMARC is not trying to solve that. tim > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
