On 4/22/2025 3:02 PM, Richard Clayton wrote:
In message <[email protected]>, Dave
Crocker <[email protected]> writes
> On 4/21/2025 11:51 PM, Richard Clayton wrote:
>> I think you may have overlooked some aspects of what is needed to
make a
>> difference to the current situation.
>>
>> Your design records and signs the RCPT TO of the original email and
>> insists that there is only one recipient per email -- so far so good.
I agree with John Levine that you cannot determine that other systems
checked this ... so that "so far" is not in fact very far at all
1. Once again, you are criticizing it for not doing things it was not
intended to do
(This is starting to be a pattern.)
2. Further, you are asserting an obligation to do things that
a) are not specified as a requirement, with specific respect to
handling DKIM Replay, unless you care to point to where it is, and
b) you have not presented any evidence that whatever it is you are
demanding to be done cannot be done as a separate mechanism that
will work with this.
I guess the other point seems to be that since you offer no criticism
about this doing what it is intended to do, you do not disagree it can
do it.
The operative design point here falls under the rubric of 'divide and
conquer'.
Rather than having everything be conflated and mixed together, it is
pretty much always better to define separate functions separately.
Merging them become useful only after there is enough experience to know
how merging them will create benefits. We are a very, very long way
from that.
Also, this goes to the underlying issue with the Motivation document,
which states some problems it is reacting to but has no overall design
framework, never-mind any threat model to build on.
>> However, you do not capture whether an intermediate system has
>> intentionally replayed the message (and what their identity might be).
> Richard, excluding things that are out of scope is not 'missing' them.
> My spec seeks only to deal with detecting Replay. It does that.
If you do not add other features to it then your proposal is of no
practical use
Oh? Sounds dramatic. Except, of course, it is quite wrong.
There is a goal of permitting receivers to detect DKIM Replay. This
accomplishes that.
If you think it does not, please engage in the typical IETF practice of
offering a technical analysis and show how it does not.
.. there are many flows where "replay" occurs, where
everyone wishes to deliver the resulting email.
Please show what specific mechanisms will provide that, and then show
how they cannot work with DKOR.
However, there are situations where the replay is malicious (and usually
at considerable scale) and delivery of the email is not a sensible
outcome.
I outlined in my previous email what other features could be part of a
protocol beyond merely recording the existence of replay -- and how
systems could use those features. Mere identification of "replay" is
just not sufficient to address any of today's abuse issues.
The problem is with your assertion by authority that they cannot be
achieved with this mechanism in place. Feel free to show you work.
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]
