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