Indeed... The issue here is this: 1. I get a (free) account on free-email.com. 2. I send myself email from my account to my account. Of course, free-email signs it, because it's sent from me to me: why would it not? 3. I take that signed message and cart it over somewhere else, sending it out to 10,000,000 recipients through somewhere else's infrastructure. It's legitimately signed by free-email.com. 4. Of course, it fails SPF validation. But DKIM verifies and is aligned to spam...@free-email.com, because there you go.
That's the attack. It's happening all the time. If between 1 and 2 we could use x= to cause the signature to time out, we'd be OK. The trouble is that we have to make x= broad enough to deal with legitimate delays. And during that legitimate time, it's trivial for a spammer to send out millions of spam messages. Crap. So x= doesn't help. We have to look at other options. We thought of this when we designed DKIM, but couldn't come up with anything that would work. We have new experience since then, and we want to look at alternatives, and decide whether priorities have changed, use cases, have changed, and so on. It's entirely possible that we still can't fix it without breaking use cases that we're not willing to break. But we have to try. Barry On Fri, Nov 11, 2022 at 3:19 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > > On Fri, Nov 11, 2022 at 11:42 AM Laura Atkins <la...@wordtothewise.com> wrote: >> >> >> The MP limits the volume of messages that a user can send out. However, by >> signing even one message, it takes the responsibility for its content. >> >> >> This appears to be the disconnect. The MP takes responsibility for the >> *MESSAGE* - that message, sent to that user. > > > I think you've hit on possibly the most interesting part of this: In RFC > 6376, we said "You're taking some responsibility for this message... and oh, > by the way, it could get replayed, and your claimed responsibility extends to > that case as well". I don't know that we underscored the latter very much > then or since. > > So to me, part of this hinges on whether we feel we need to remedy that, or > be comfortable pointing at 6376 and telling people to read it again, properly > this time, and seeing if the industry is OK with that. > > -MSK > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
