On Sun, Feb 12, 2023 at 12:16 PM Dave Crocker <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. 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 > mast:@dcrocker@mastodon.social > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
