Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted

[Alessandro Vesely <[e-mail]>]

On Tue 14/Feb/2023 23:42:36 +0100 Scott Kitterman wrote:
> On Tuesday, February 14, 2023 4:16:00 PM EST Evan Burke wrote:
>> On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas <[e-mail]> wrote:
>>> On Tue, Feb 14, 2023 at 11:18 AM Michael Thomas <[e-mail]> 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?


The ration between duplicate count and x= is the spamming speed.


>>> 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.
>
> I suppose if the thresholds are high enough, it won't hit much in the way of 
> legitimate mail (as an example, I anticipate this message will hit at least 
> hundreds of mail boxes at Gmail, but not millions), but of course letting the 
> first X through isn't ideal.


Scott's message hit my server exactly once.  Counting is a no-op for small 
operators.


> If I had access to a database of numerically scored IP reputation values (I 
> don't currently, but I have in the past, so I can imagine this at least), I 
> think I'd be more inclined to look at the reputation of the domain as a whole 
> (something like average score of messages from an SPF validated Mail From, 
> DKIM validated d=, or DMARC pass domain) and the reputation of the IP for a 
> message from that domain and then if there was sufficient statistical confidence 
> that the reputation of the IP was "bad" compared to the domain's reputation I 
> would infer it was likely being replayed and ignore the signature.


Some random forwarder in Nebraska can be easily mistaken for a spammer that 
way.  Reputation is affected by email volume.  Even large operators have little 
knowledge of almost silent MTAs.

Having senders' signatures transmit the perceived risk of an author would 
contribute an additional evaluation factor here.  Rather than discard validated 
signatures, have an indication to weight them.  (In that respect, let me note 
the usage of ARC as a sort of second class DKIM, when the signer knows nothing 
about the author.)


> I think that approaches the same effect as a "too many dupes" approach without 
> the threshold problem.  It does require reputation data, but I assume any 
> entity of a non-trivial size either has access to their own or can buy it from 
> someone else.


DNSWLs exist.


Best
Ale
--