I haven't had time to read the DKOR drafts so I'm not sure how it would work in this case. From the discussion on the list, it seems like it would be similar to the DKIM2 proposal though, from the perspective of replay mitigation. I'm also very much behind in generating a draft containing a list of example mail flows that I think are interesting for this work. $dayjob pays the bills and hasn't left time for much else lately.
I think it's fair to say that DKIM2 doesn't make it possible to distinguish between abusive and non-abusive signing. However, a key aspect of DKIM2 is that it requires that the abuser sign the message to achieve a DKIM2 passing result. Reputation systems work better when there's an authenticated identity for the message being evaluated. Consider a DKIM2 chain for a message to this mailing list. Your initial post would have a chain like this i=1 d=tana.it [email protected] [email protected] The copy delivered to me would have i=1 d=tana.it [email protected] [email protected] i=2 d=ietf.org [email protected] [email protected] And the copy delivered to Bron would have i=1 d=tana.it [email protected] [email protected] i=2 d=ietf.org [email protected] rt= [email protected] The i=1 signature in copies to me and Bron will be identical, because it's being replayed legitimately. Similarly, both messages likely contain the same (probably broken) DKIM signature from tana.it. Unlike DKIM, this chain provides a clear indication that this is happening and who is responsible for doing it. It is impossible for someone to replay any of these three messages (your post, or the copy sent to me or Bron) to a DKIM2 system with a new recipient and get a passing DKIM2 result because the recipient listed in the signature would not be the same as the one in the SMTP transaction. There's also protection in requiring that the chain be contiguous, so you can't maliciously attach a signature containing your target recipient unless you have a signing key for the receiving domain of the previous signature. Now to your question of what happens when the receiving domain is malicious. Let's say that my mail host is actually a malicious system. It could generate millions of signed copies of the message, like this i=1 d=tana.it [email protected] [email protected] i=2 d=ietf.org [email protected] [email protected] i=3 d=google.com [email protected] rt=<somewhere else> The systems performing DKIM2 evaluation of these malicious messages would see the i=1 and i=2 signatures repeatedly, and every message would have a distinct i=3 listing the recipient for that copy. Seeing the same signature multiple times is an indication that some sort of replay is happening. By having the additional information that i=2 is seen repeatedly and i=3 is not is an indication that the domain in i=3 is the one generating the replayed messages, and not the domains in i=1 or i=2. Reputation could be applied to determine whether this system is considered a bad actor or not, and reputational damage could be accumulated if the messages end up looking malicious in some way. On Thu, Jun 5, 2025 at 10:50 AM Alessandro Vesely <[email protected]> wrote: > On 03/06/2025 00:18, Bron Gondwana wrote: > > On Mon, May 26, 2025, at 18:15, Dave Crocker wrote: > > [...] > > >>> If it detected DKIM Replay in the general case, it would not be > trivial - however it only detects DKIM Replay in the direct case. > >> Given that Replay is about actions involving an intermediary, I don't > know what direct vs. indirect means. > >> > >> In any event, yes, there are legitimate scenarios that match Replay > abuse scenarios. > >> > >> And there always will be. > > > > Can you give some examples of legitimate scenarios that match Reply > abuse scenarios (in a world where every site which sends you indirect mail > is running DKIM2. I agree that until then, there will be scenarios that > match Replay abuse) > > > I may be dumb, but I cannot figure out how DKIM2 (or DKOR) can tell > Replay abuse from, say, this list post as relayed by mail2.ietf.org. > Even if both ietf.org and the abuser implemented DKIM2, what do the new > rt= and mf= tags add to the equation? If their respective > implementations are correct, the new tags will bear the formally correct > values in both cases. > > I guess one can draw some conclusion when mf=*@gmail.com, but this is a > reputation driven reasoning that can be done even now, like so: If the > recipient is not in the To:/Cc: fields, i.e. an *unofficial recipient*, > and the actual sender is *unknown*, then it must be an abusive message. > > What am I missing? > > > Best > Ale > -- > > > > > > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
