What Steve said: Unique domains per account, or for different groups. We had to do this for link-tracking domains: userid.example.com instead of links.example.com for all accounts.
-Tim On Fri, Aug 12, 2016 at 10:34 AM, Steve Atkins <st...@blighty.com> wrote: > > > On Aug 11, 2016, at 5:42 PM, Robert Mueller <r...@fastmail.fm> 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 > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
