I can put together plenty of text if the WG want to listen. I was repeatedly told that what I wanted in DMARCbis was very different from what the rest of the WG wanted, so we agreed to disagree and I went silent for a long time. But when you asked about the mailing list problem, you exposed the emperor's new clothes: DMARCbis does not solve anything important.
Is the WG ready to admit that no combination of present or future Authentication Results will ever determine intent? Intent requires natural language processing, and DMARC does not do that. Given the last few posts asking if ARC is the answer, we still seem to be chasing a mirage. To my mind, a protocol should cover how things are supposed to work and how the participants should detect and correct error conditions. Early on, I called this "Exception Management". But then, as now, your position is that this topic is off limits. Without as discussion of exception management, we should expect readers to conclude that the process is simpler than it actually is. The solution begins with the target audience. The WG strategy is to tell domain owners to not publish p=reject, on the assumption that evaluators will not pay attention to failures when p not equal reject. This assumption embodies two lies: (1) that p=reject will be treated as malicious because the documentation implicitly ore explicitly encourages people to do so, and (2) that nothing can be done about impersonation when p not equal reject. I have asked before, and am asking again, to write a document that targets evaluators, since they are the ones actually making evaluation decisions. If you think the current document covers the bases, ask a neutral party to read the text and explain what they think an evaluator should do to keep malicious impersonation out of their network. If they choose "p=reject means malicious" or "I have no idea", then the document has failed. Doug On Thu, Oct 24, 2024 at 10:54 AM Murray S. Kucherawy <[email protected]> wrote: > On Thu, Oct 24, 2024 at 4:34 AM Douglas Foster < > [email protected]> wrote: > >> The necessary first step is to acknowledge that RFC7489 is a heuristic, >> and like all heuristics, it will make mistakes. So the interesting work >> is determining how to detect and correct mistakes. >> > > Please explain how Section 7.4 falls short of this "necessary" step. I > agree that it would be nice for DMARCbis to admit these weaknesses while > also presenting comprehensive mitigations, but the latter is not always > both possible and standards-worthy. > > It's perplexing that you make these proclamations in the presence of > contrary evidence and repeated explanations. > > From a security standpoint, authentication is a binary Pass/Fail issue. >> There are not 4 types of failure. Because any unauthenticated message >> MIGHT be a malicious impersonation, the most secure response to an >> unauthenticated message is quarantine. But you cannot do that early in >> the rollout process because you will be overwhelmed by the quarantine >> volume. So you triage, and let some unauthenticated messages through >> sender authentication and hope that content filtering catches the worst >> stuff. But if you do things right, the quarantine volume shrinks steadily. >> > > In my view, you've basically restated Section 7.4 here. > > >> You cannot afford to investigate the same quarantine issue over and over >> again. So every quarantine investigation needs to lead to an allow/block >> decision, and the result of an allow decision is to provide alternate >> authentication in local policy. (Alternate authentication does not mean >> whitelisting to bypass content filtering.) >> > > This is operational advice. I would argue we don't need to spell this out > because it's out of scope of the protocol itself, but if the WG decides to > add text of this sort either here or in a best practices document, that's > fine. > > I asked before and never got an answer: Do you have a draft available that > collects all of this advice and mitigations? Or are you expecting the WG > to do this on its own? > > I don't want to step into the chairs' domain, but I think we're long past > the point of changing the entire scope of this document to incorporate best > practices material of the volume and breadth you're espousing. > > -MSK > >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
