On 2/4/2025 4:20 PM, John Levine wrote:
It appears that Dave Crocker<dcroc...@bbiw.net> said:
If your above statement is true, then why is it necessary to do the
reversal?
So you can tell if the earlier signatures in the chain were real.
A DKIM signature is self-validating.
Why doesn't one handler's taking responsibility eliminate the need to
worry about the predecessors.
That's what ARC did, a chain of signatures with no way to tell whether anything
but the most recent one actually matched the contents of the messages. We tried
that and its acceptance has been underwhelming.
There are many possible reasons for that. Is there data that points to
a specific adoption and use problem that the current one solves? If so,
it would be helpful to see it. If not, then this sounds like a guess,
within a very complicated problem and solution space.
Anyhow, I took Wei at his comment. As he stated it, the utility of the
preceding signatures is not at all clear.
It seems to me that a validated chain can be useful for developing the
reputations of all of the entities with signatures in the chain, not just
the most recent one.
Can be is different from will be, especially since it also permits might
not be. An international standard requiring widespread implementation
and use is a rather expensive experimental sandbox.
Also, we know that most of the changes that mailing lists make are fairly
simple, so I can imagine filtering schemes that recognize changes that
lists usually do, so if it sees a message with list-like changes, it can
give more weight to the reputation of the earlier signers. IF it can't
evaluate the changes, it's no worse off than it is now.
Hence my use of "Procrustean" since what you've described is an
environment that will penalize places doing otherwise legitimate changes
but not conforming to the fairly simple changes the filtering engines
expects (ie, demands.)
This makes it easier to handle the issue that lists often do lousy
filtering of incoming mail, so now you can do retroactive filtering
and DMARC enforcement.
If someone's going to say we don't know if this will work, it's true,
we don't. But the only way to find out is to try it with some
interoperating implemetations and see.
1. cf, 'experiment', above.
2. This would seem to require a pretty clear, reviewed, and
consensus-based specification of that experimental use.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
