> On Aug 13, 2016, at 8:47 PM, Neil Jenkins <ne...@fastmail.com> wrote: > > On Sun, 14 Aug 2016, at 11:55 AM, Security Desk wrote: >> I think I'd start by not letting random people sign up as >> secure_m...@internet-mail.org > > That has zero relevance to the topic in hand, which is DKIM replay attacks. > But just to address that anyway: this is "enumerating badness", #2 on the > list of six dumbest ideas in computer security. Apart from the fact that > legitimate users have email addresses that aren't necessarily first.last and > might be something generic and anonymous, there's simply no end to the > various forms you might use as part of a phishing attack. It's pointless to > try to block them all, and still doesn't address the issue of the actual > email being sent. > > I probably wouldn't let random signups use this address, either. > p0stmas...@fastmail.com > > Of course not. Any I guess you wouldn't allow postmastar@... postmasler@… > either. But why stop there? I'm sure we can think of more similar looking > variants to block. But then I have to ask, what exactly is your threat model > you're protecting against here? It's not for any RFC defined purpose (only > postmaster@ will do). It's not for phishing our own customers, because you > can pretty much put anything there: we've seen most people that fall for > phishing will do so for a message from joeblo...@hotmail.com, and so we've > put our effort into detecting and blocking the mass phishing attempts as they > arrive and making it easy to identify legitimate messages from our staff. And > I presume it's not for phishing some random other service, as then the bit > before the @ has even less relevance, as you're presuming they're going to > ignore the domain as well? > > Anyway, back to the topic in hand. DKIM replay attacks…
This is somewhat on-topic. There is no technical way to prevent DKIM replay attacks. All you can do is to make them unattractive, by making mail sent using them less likely to be delivered or unprofitable. You're DKIM signing mail for people who are total strangers, many of whom you know are malicious. That is what makes DKIM replay attacks profitable. That's not really a criticism, just that as your business model involves taking responsibility for malicious mail, some of the mail you take responsibility for will be malicious. There's some interesting secondary discussion about delivery rates of Bcc-ed mail, effectively monitoring abuse like this and so on. But most of the mitigation is going to involve business process changes to make it unattractive rather than technical changes to make it more difficult. If your business model include 30 days of access with no payment, no credit card, no contract and no authentication ... that's going to be part of the discussion. Not a fastmail-specific observation - a similar argument applies to many other C2C DKIM-signers (most noticeably Gmail and Yahoo in my inbox)[1]. Cheers, Steve [1] Well, fastmail distinguishes itself by not allowing the bulk spam to be sent from their network. Allowing that would likely eliminate DKIM replay attacks... _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
