> On 12 Feb 2023, at 20:48, Wei Chuang <weihaw=40google....@dmarc.ietf.org> > wrote: > > > > On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker <d...@dcrocker.net > <mailto:d...@dcrocker.net>> wrote: > Folks, > > There appears to be no perfect way to distinguish a Replay attack from a > legitimate re-posting by an Alias or even a Mailing list (that preserves > the original DKIM signature.) > > The only 'signal' that is valid, also is ambiguous. The signal is that > the rfc5321.Mail command has an address that is not in any of the > rfc5322 address fields. The ambiguity, of course, is that that's also > true for Alias. > > I'm wondering about designing some assistance by the author's platform > and the Aliasing platform, to flag what they've done. > > Imagine adding a header field like "Separate-Envelope:", possibly > listing the domain name of the site putting the flag there, and having > them add a DKIM signature to cover it and the rest of the message. > > This could also be done by a spammer doing Replay, of course. But the > point is that this added mechanism now creates a noise-free basis for > evaluating this class of traffic associated with that signed domain. > > Agreed that reputation systems can play a role when the spammer decides to > participate.
One thing I’ve been telling folks is that a DKIM d= isn’t a reputation. The d= is a strong identity. That identity can be used to hang a reputation on - where the reputation is based on all the mail containing that identity. I think it might be helpful if we shifted the discussion from DKIM is a reputation to DKIM is an identity. That reframes the question as: How do we improve the DKIM protocol so that we can minimize the ability of an unauthorized 3rd party to misappropriate the identity of the signer? laura > > It's not that the receiving filter could not detect the disparity > between envelope and content addresses. It's that the receiver is > getting a flag from whomever did it. > > If, for example, the domain name is of the originating service, then > it's clearly not Replay. > > If it is from an Aliasing site, the receiver can quickly build up a > reputation for that site, to aid in determining replay or not. > > Thoughts? > > In this model, let's consider the Receiver's actions. > 1. Say the spammer doesn't want to participate in creating a > Separate-Envelope, how would a receiver detect this as Replay? Is the idea > that Separate-Envelope identifies the Alias or Mailing-lIst? Is the > verification process that the Receiver notices that the header is missing? > 2. You've noted what happens when the spammer participates in generating > Separate-Envelope > 3. A non-spammer should have a Separate-Envelope, which will validate. > > FWIW a different approach but overlaps this idea is that a sender identifies > the domain they intend to send to. The receiving system verifies that they > are the intended recipient domain. I think John Levine has a draft about > this. I have a draft that expands some of that idea further. > > -Wei > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net <http://bbiw.net/> > mast:@dcrocker@mastodon.social > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org <mailto:Ietf-dkim@ietf.org> > https://www.ietf.org/mailman/listinfo/ietf-dkim > <https://www.ietf.org/mailman/listinfo/ietf-dkim> > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
