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