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.
>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. 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.) The rollout process that worked for me was to concentrate on investigating SPF failures for messages that did not have relevant DKIM signatures. That allowed me to blocked a little bit of impersonation traffic and a lot of unwanted spam, so my overall filtering process became more accurate and more efficient. Getting to mandatory SPF PASS or aligned DKIM PASS solved most of my authentication problems. (My biggest problem today is single-use Gmail accounts used to send phishing attacks.) At this point, I am gradually resolving the SPF PASS without alignment problems. This has a long tail, so I am still allowing some of it through. I have updated my External Sender warning to notify uses about the small volume of traffic that has unverified From addresses. I don't look at the domain owner DMARC policy at all. Doug Foster On Thu, Oct 24, 2024 at 12:59 AM Steven M Jones <[email protected]> wrote: > On 10/23/24 4:35 PM, Murray S. Kucherawy wrote: > > On Wed, Oct 23, 2024 at 11:55 AM Jim Fenton <[email protected]> > wrote: > >> It hardly seems like the agreement was tacit when it’s quite explicit in >> the WG charter. >> > > The charter is explicit (twice, by my count) that addressing the problems > with indirect mail flows is in scope for the working group. What it > doesn't make clear (hence "tacit") is the understanding, at least at the > time of chartering, that it's not only in scope, it's required. > > "Tacit" is tricky, and we tend to avoid that when writing documents for a > reason. > > The way I read Track 1 of the charter, the WG was to "reduc[e] or > eliminat[e]" effects on indirect mail flows, but it doesn't state that the > DMARCbis spec itself has to be what does it. And I don't see where in Track > 2, "Reviewing and improving the base DMARC spec," that it says DMARCbis > revisions themselves must remediate impacts on indirect mail flows. > > But then those "tacit expectations" come back to haunt us. However... > > ARC was published, and support has been baked into Mailman and Sympa for a > good while now. I think the stumbling block in citing it in a response to > this point, is that RFC8617 is Experimental. Given the timing now, leaving > ARC in Experimental status - and not actually running it as an experiment - > may have left us between a rock and a hard place. This is reflected in > comments from Ale V and John L on the GitHub thread. > > The problem with DKIM2 (another point from the GitHub thread) is that it > would be a forward reference. I know a great deal of thought has gone into > the "design outline," but I don't think there's a specification so that's > at least one step behind ARC in terms of this thread, and I imagine it > doesn't have experimental data either. > > > DMARCbis appears to address this via the text of Section 7.4, which in > essence tells senders to ... The completion of WGLC with no further > discussion suggests that the WG believes that this is satisfactory. That's > fine if so, but I claim it falls short of what I imagine was anticipated, > that being a protocol solution, and I'm suggesting we should say something > in the document that reconciles or explains this. > > There is a problem inherent in trying to address implicit, undocumented > expectations that weren't written into the charter. I don't say that to be > a jerk but to ask, How are we supposed to know where the bar is if it was > never written down? You can talk yourself into or out of anything depending > on what you imagine those expectations were, or have become since. > > And whatever deficiencies people see in ARC, it is a protocol-based > response. > > > To reiterate something I said earlier: I'm not obstructing the progress of > the document even though I disagree with a couple of the decisions made, > but I think those decisions -- especially this one -- need to be explained > or face scrutiny and delay during Last Call and/or IESG Evaluation. > > Anticipating objections so we can address them in advance is not > obstructive, but constructive. Thank you for taking the time to carefully > consider the situation and kick us in the collective behind. > > > --S. > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
