On 4/11/2025 1:04 PM, Richard Clayton wrote:
>> Find the highest numbered DKIM2 header that reports a modification.
>> Undo the modification and repeat. When all modifications have been
>> done then there should be a match with the original signature (at
>> hop1). If not then the email has been altered (in an undocumented
>> manner) on its way to you and it SHOULD be rejected.
> Do not embed policy directives in the middle of algorithm
specifications.
Just to highlight this rather basic specification methodology point...
>> 6.4. Dealing with replays
>>
>> Checking source and destination as recorded by the previous hop
makes
>> many “DKIM replay” scenarios impossible.
> There is more than one DKIM scenario? What are they?
there is some helpful information in the now expired draft:
draft-chuang-dkim-replay-problem-03.txt
Rather than a generic citation of an entire document, perhaps you can
give or cite specifics?
On the average, when someone asks for specifics, telling them to go look
over there, somewhere, is not helpful.
>> If not then you would expect that the
>> (original) hash of the email is unique and duplicates can be
>> rejected.
>>
>> If a expansion event is recorded then receiving multiple copies
would
>> not be a surprise.
> To whom? And how is this, somehow, a useful point?
the way in which DKIM replay is currently successfully dealt with is by
counting instances of DKIM signatures. If more than <N> are received
then further copies are rejected. The difficulty is of course
determining a suitable value of <N> ... and that is currently done by a
mixture of heuristics and manual overrides.
having the expansion event documented informs those heuristics
I thought the goal is to get away from needing heuristics for this problem?
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]
