(Sorry, forgot to reply to the list on my previous message. Grant's quotes include it in full.)
On Fri, Dec 16, 2022 at 1:57 PM Grant Taylor <gtaylor= [email protected]> wrote: > On 12/16/22 12:50 PM, Evan Burke wrote: > > Yes, but the other issue is there's no reliable real-time reporting or > > monitoring mechanism to tell you your domain is getting replayed*. > > It doesn't seem like the lack of real-time reporting is isolated to > DKIM. The lack of real-time reporting seems like a larger issue that > far supersedes anything that DKIM can do. > > > So you wait for end recipients to send you spam complaints, sometimes > > a day or two later, or you use ISP provided tools which are available > > with 1 day delay, and that's quite a bit too long when an attacker > > can send on the order of 50-100 million per hour. > > I know that replay spam is an issue. But I don't understand the > mechanics of it. Do the messages not include a To: header? Or is it > something like "undisclosed recipients"? > > I ask because I would assume that a proper DKIM signature including the > To: header would mean that the message could only be replayed to the > same recipient and pass DKIM validation. -- There is the separation > between the envelope RCPT and the To: / CC: headers. > The separation between RCPT TO and To: (or CC:) is exactly what's being exploited here. To: is present, the signature covers it and is valid, but To: does not match the RCPT TO address. Just like BCC delivery. > > * With the exception of DKIM-based complaint feedback loops. As far as > > I'm aware, replay spam volume has been many orders of magnitude higher > > to domains which *don't* offer those. I suspect that's intentional. > > Probably. > >
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
