> On Aug 11, 2016, at 5:42 PM, Robert Mueller <[email protected]> wrote: > > Hi mailop > > So it appears at the moment that we're experiencing a DKIM replay attack > against us. Basically some people are signing up a trial FastMail > account, sending a couple of emails to a gmail account (to get them DKIM > signed by us), and then copying the entire content of the email and > sending it from an AWS instance.
[...] > 2. I bet a number of services out there are using the domains in DKIM > signed emails for reputation tracking. So this may be affecting the > reputation of our domains, even though we're not the genuine source of > the majority of the emails. > > Does anyone know if (2) is actually true, or what sites might be doing > to avoid this? I guess checking the uniqueness of b= value in each DKIM > signature to see if it's truly the same email just replayed over and > over is one way? (2) is absolutely true, it's what DKIM is for. You're vouching for / accepting responsibility for every mail you sign. If your users are bad actors - as they are in this case - you're accepting responsibility for that. > > That's an interesting thought actually, I wonder if seeing many emails > with the same b= value is an easy way to actually detect spam and/or a > replay attack? > > I can't see an easy way to stop this. It's impossible to block every > single sent spam email ever, and all it takes is one email sent and > signed by us to be able to be replicated as much as anyone wants. > > I know that this is a known problem with DKIM, just wondering if anyone > else has seen this and or dealt with it and has any idea if we should > even be worried about it at all? It's trashing your domain reputation exactly as though the mail came from your servers. It's something to be concerned about. Messing around with invalidating selectors won't help, as by the time you know that a user is doing this the damage is already done - and reputation is tied to the d= value. What headers are you signing? 90% of the things DKIM does are to try and mitigate replay. Signing the To and Cc means that they can't be replayed with other email addresses in those fields (which makes a replay attack less attractive) and signing message-id and date help a little too. Begin careful to double-sign where appropriate - as we talk about at https://wordtothewise.com/2014/05/dkim-injected-headers/ - can help with clever replay attacks, but not against crude "immediately duplicate a message a thousand times with identical headers and body". There are some other things you could do to mitigate, but they might be too intrusive into your business model - assigning different d= values for different customers or different classes of customer, for example. The problems are caused by you sharing a reputation between legitimate users of your system and others. If the illegitimate users are all, for example, on free trials or new signups there are several obvious things you can do to mitigate. If they're not it gets trickier and most of the "obvious" mitigants would likely be more harmful than just eating the domain reputation hit. Cheers, Steve _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
