On 12/7/2022 1:47 PM, Murray S. Kucherawy wrote:
Yes, it's definitely true that the standard was written from the
perspective of delivery-time evaluation, and then sending that result
to MUAs rather than having MUAs actually do the evaluation. So
although 4686 says that's a design goal, 6376 sure doesn't have that
flavor.
I don't see either RFC clearly "disagreeing" with the view that
DKIM is for transit-related work. That's contrary to Murray's
assessment. But again, the RFC doesn't make that limitation clear
(enough, IMO), either.
Right, I think that's what I'm driving at. And because of this, we
can't take "transit-time" as a given.
Possibly beating this poor horse beyond equinimity...
It's not meant to be about 'given' but about current reality. Even with
the reality that the signatures are used forensically, that was not a
design goal and, based on thoughtful consideration as reflected in that
article, it's not very good for it. This of course doesn't prevent
anyone from using it that way, but neither does it mean that a new
specification has to accept that use as... acceptable.
It is absolutely within the purview of the reconstituted WG to "fix"
this by clarifying using current operational realities and acquired
experience. An applicability statement, for instance, would not be
out of the question.
As appealing as the AS concept is, I've never been clear how
operationally useful they are.
More to the current point, if the anti-replay work to be done benefits
from a position on transit vs. non-transit, then including it directly
in an anti-replay specification would be more helpful than in a separate AS.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[email protected]
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim