That is not my position, and I don't know how you drew that conclusion from those words.
I do take the position that DMARC PASS means "This name correctly represents the stated domain", and NP=TRUE means "This name cannot represent the stated domain because the domain owner never uses that name". I am willing to say that if NP=TRUE produces an accurate result, I will block the message and I can see no reason why anyone else would do otherwise. DMARC FAIL is an ambiguous result, which was your point. DMARC PASS is not ambiguous. NP=TRUE should be ambiguous if at all possible, otherwise it adds no value. But back to the actual topic: - Do you believe the NP test can be useful? If so, for what purpose? - What is the optimal test to evaluate NP? How did you reach that conclusion? Doug On Fri, Dec 17, 2021 at 6:38 PM Tim Wicinski <[email protected]> wrote: > > > On Fri, Dec 17, 2021 at 6:27 PM Douglas Foster < > [email protected]> 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 <[email protected]> >> wrote: >> >>> On Thu, Dec 16, 2021 at 3:52 PM Douglas Foster < >>> [email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
