On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas <m...@mtcc.com> wrote:

> On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas <m...@mtcc.com> wrote:
>
>> Have you considered something like rate limiting on the receiver side for
>> things with duplicate msg-id's? Aka, a tar pit, iirc?
>>
>
I believe Yahoo does currently use some sort of count-based approach to
detect replay, though I'm not clear on the details.

>
> As I recall that technique is sometimes not suggested because (a) we can't
> come up with good advice about how long you need to cache message IDs to
> watch for duplicates, and (b) the longer that cache needs to live, the
> larger of a resource burden the technique imposes, and small operators
> might not be able to do it well.
>
> At maximum, isn't it just the x= value? It seems to me that if you don't
> specify an x= value, or it's essentially infinite, they are saying they
> don't care about "replays". Which is fine in most cases and you can just
> ignore it. Something that really throttles down x= should be a tractable
> problem, right?
>
> But even at scale it seems like a pretty small database in comparison to
> the overall volume. It's would be easy for a receiver to just prune it
> after a day or so, say.
>

I think count-based approaches can be made even simpler than that, in fact.
I'm halfway inclined to submit a draft using that approach, as time permits.
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to