On Mon, Aug 7, 2023, at 10:24 PM, Murray S. Kucherawy wrote:
> On Mon, Aug 7, 2023 at 7:43 PM Jesse Thompson <[email protected]> wrote:
>> __
>> Similar to what Emmanuel is saying about detecting SPF/DKIM zone
>> misalignment, the solution to DKIM replay is for receivers to maintain some
>> state and feed it into bespoke replay detection algorithms. If all receivers
>> can maintain this kind of state, then there's nothing senders need to do, I
>> suppose? Given that *normally* all of the messages we emit have unique
>> message-ids, receivers can just limit the amount of duplicative message-ids
>> they accept from us. Assuming they know the situations in which message-ids
>> would not be unique. That's another thing that maybe needs to be
>> communicated somehow as "this is normal in this situation".
>
> Isn't this a derivative of the "Count DKIM signatures" approach identified in
> the current problem statement document? If so, do you have any comments on
> the points against such an approach?
Yes, it is derivative. But I don't see why the solution needs to describe
exactly how a receiver must fingerprint a mail stream. Presumably they
can/will/do use all of the available information to get the most fidelity.
The larger issue is how senders communicate to receivers how to correctly
interpret the different signals. Receivers can choose whether to trust what the
sender is communicating, and incorporate into their disposition.
Chained DKIM would use a domain as the key for receivers to index and look up
this information, without having to invent a new header to be signed (which
would then involve another internal policy lookup to see if they trust the
signing domain, so why not just use the signing domain as the key).
DNSxL is a proven workable lookup mechanism, is it not?
> Since you specifically mention Message-IDs, does anyone have data on how
> often that header field is included in signatures? If it's not, then
> rotating Message-IDs at random defeats such an approach and drives up the
> receiver's operational cost to boot.
Can't speak for everyone. All I can say is that we sign message-ids and we use
message-ids as the username part of the return path to ensure message-level
attribution of such events. Our interest is to maximize visibility on bounces
and other kinds of feedback to ensure customers adhere to deliverability best
practices.
Jesse
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
