On Wed, Oct 23, 2024 at 9:59 PM Steven M Jones <[email protected]> wrote:
> 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. > I think it is (or would be) fine if we had some other document to advance that "reduces or eliminates" effects on indirect mail flows, but I don't think that's happened. Again, I'm happy to be corrected. You raised ARC, which is the obvious answer, but I also concur with your point that we've fallen short of actually proving anything by collecting and publishing efficacy results, despite me asking more than once. > But then those "tacit expectations" come back to haunt us. However... > Well, you're making the point more firmly than I did. :-) Maybe it's not all that tacit. > 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. > I would volunteer that, as far as the IETF is concerned, DKIM2 doesn't exist yet. It can be offered neither as an alternative nor as a solution. > 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. > The charter is the outcome of a discussion with the community, and I remember (and will look for evidence since the archives exist) that this was part of the discussion. Apparently at the time, people equated that expectation with the text that ended up in the charter, but now reading it (10 years later!) I agree that this could've been more crisp. So you're right, it's not as explicit as it should've been, but I'm uncertain how much we'll get away with making the argument that we didn't solve the problem because doing so was accidentally not in the contract. I think it's a gamble, and I tend to be risk-averse. > And whatever deficiencies people see in ARC, it is a protocol-based > response. > We have made no statement that ARC even works, much less that it solves the stated problem. Our story is incomplete. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
