On 2/14/23 1:16 PM, Evan Burke wrote:
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.
The problem draft mentions it, but if it's Yahoo doing it have they documented it? Or is this just hallway chatter, maybe?
One thing that occurs to me is that if filters can have knobs to dial up the sensitivity of detection (at risk of false positives), maybe that can be applied if you're seeing tons of dups. That would be especially frustrating to a spammer since they could get something through in the small only to be detected as spam when they are trying to exploit it.
Mike
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
