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]
