On 4/25/2025 8:13 PM, Bron Gondwana wrote:
On Fri, Apr 25, 2025, at 12:31, Dave Crocker wrote:
Your approach requires changing the entire email infrastructure.
When will you achieve utility at scale? Not for a (very) long time
as ARC and IPv6 demonstrate.
Agree,
Bron,
Glad you agree that your proposals entail a massive barrier to adoption
and isn't likely to reach critical mass for a long time.
which is why it's "our" approach, not "mine" or "Wei's"
This is clearly meant to make a point but there is nothing about it that
anything to do with what I wrote or intended.
- and has been socialised among many of the high traffic sites of the
email infrastructure, such that the benefits of becoming interoperable
will be high because the alternative is to lose the ability to send to
"must send to" sites. In the same way that supporting HTTPS became
necessary to access web sites at some point due to pressure from major
sites.
HTTPS followed an incremental adoption path, not all that different from
what I've proposed, since there is utility for any pair of client and
server that adopted it. This is profoundly different from your proposal.
As for all the socialization you've done, please refer to the 15 years
of government and corporate support OSI had. And IPv6. See how well
that worked for them?
Also, your referencing all that support seems to qualify as an attempted
appeal to authority, since your reference is quite vague, but claims
broad support. Also, other than very, very few folk, none of those
supporters are here. I'm sure you are not saying that the ones who
/are/ here are the only ones that matter. Right?
When will mine achieve utility? As soon as any sender and their
receivers implement it. When will they achieve it at scale? As soon
as more pairs implement it. Incrementally.
Your approach entails quite a lot of mechanism. Mine is utterly
trivial. That is not a minor difference.
Your turn.
Our approach solves the whole problem enough to be worth the effort.
You keep saying that. I keep asking for detailed scenarios that show
how. You then keep coming back witht he same, generic claims.
Yours brings some benefit, but the overall benefit is trivial
So, making it easy to detect DKIM Repaly is a trivial benefit? Wow.
because it doesn't close the forwarding hole and forwarding becomes
even more of a poisoned chalice than it has already become (Wei showed
evidence of this and a credible theory for why).
Scenarios, Bron. Show yours working in detail for all this extra
benefit, so others can a) evaluate what it will take to adopt it, b)
evaluate its likely efficacy, and c) consider being able to use
different components that might have superior characteristics.
To date, we get a constant refrain that has similar semantics to Love It
or Leave It rhetoric that strongly suggests you are looking for the
IETFto do nothing other than rubber stamp your proposal. While I doubt
that's in your head, it is what your behavior looks like to me.
This is my objection to your proposed approach. It's both trivial in
its implementation, and trivial in its benefit.
Again, saying that making it easy to adopt and easy to use and effective
for finding Replay is a trivial benefit seems really quite surprising.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
