Peer initiated, “send to a friend”, “forward to a friend”, “send to a network”… while these terms can conjure visions of dollar signs for potential revenue bumps — nobody sells your products better than a consumer who’s passionate about them — they can also turn into persistent sores which ultimately tarnish your sending IPs’ reputations, as well as your business image. In 2011, social networks utilizing peer-initiated messages had a whopping average of 20.8 spam traps per IP address, and 73% of our sending clients’ security issues in Q2 of 2012 so far have been caused by deficiencies in peer-initiated messaging protection.
It stands to reason… Virtually all websites nowadays have some form of peer initiated sharing component to them. The idea of enabling website visitors to share content, or products, or sales notices to a trusted network is effective, hence why it’s become so prolific. What you can’t see, though, is the oftentimes complex set of algorithms and rules that sit on the apache server, or the sendmail hosts (or insert webserver to SMTP technology here) which filter this “shared” web traffic before it’s sent outwards. So while the idea seems simple, the successfully protected implementation is far more complex.
I don’t have enough fingers to count the instances over the years when — in running one of the largest email systems in the world at my previous employer — I had to shut down a new product launch because the peer initiated email feature of this new product was insecure. Trust me when I say that if you think your legitimate consumers find an email API sans-captcha more convenient than one with a captcha, spammers do too. Spammers do what they do to make money. What’s more, the more time hacker/spammers spend in and on your system, the more they know about how you work, and the less they’re incentivized to attack someone else.
It’s the old story of being at a picnic in the woods, and having a grizzly bear stumble on your delicious meal. You don’t have to be the fastest runner to escape, you just have to not be the slowest. Unfortunately for the slowest runners, they often end up getting mauled over and over again, requiring they invest far more than they would have, had their mail form started with some rudimentary security measures. In other words, if you start off wearing running shoes rather than flip-flops, by default, you end up being a less appetizing target.
At the least, and at low cost, it should be fairly straightward to segregate your sending IPs, such that peer initiated messaging comes from its own, dedicated space. That way, if by sheer chance your insecure peer initiated form is identified and exploited, the rest of your IPs may escape unscathed. If you are signing with DKIM, you’ll want to denote the segregation in your DKIM record as well, to keep any potential negative reputation effects of abuse from bleeding over onto your other IPs. While this won’t protect you from abuse, it will minimize the effects of abuse after it’s happened. This would be akin to deciding that, by virtue of going on a picnic in a state park in Alaska, it would be a good idea to keep watch for bears.
Better would be to implement preventative mechanisms. Bring bear repellent and some running shoes. Limit the number of addressbook uploads you’ll allow-per-period of time to something reasonable, like 100/day, if your API permits uploads. Similarly, limit the number of recipients an IP address can “share” content with per minute, per hour, per day, to what a real person would do. Don’t think pie in the sky, think realistically. You can always raise thresholds later if you need to.
Odds are, that by showing spammers that you care even the tiniest bit about security, they’ll leave you alone. But sometimes they don’t, so be prepared to start running.
Captchas, those image-challenge type puzzles that seek to identify whether users are a computer or a human, are fairly easy to deploy, and should give you leverage against most botnet attacks. Be careful to select a captcha program which evolves; a puzzle with the same set of hundred “answers” can be easily scripted. Recaptcha, Secureimage, WebSpamProtect, and Cryptographp are all free, and have a regularly contributing development staff.
There’s been some debate about the effectiveness of using captchas to stop manually initiated spam runs (most often employed by 419/Nigerian/Advanced Fee Fraud type scammers), which is where sophisticated user-level, and outbound email content filtering come into play. Consider this to be akin to training for a 5K race. Spam Assassin, also free, is fairly trivial to install on most MTAs, and its heuristic set is updated regularly by the Internet community. Mail which Spam Assassin, or any similar content-based filter, identifies as “spammy” should be quarantined or removed from the outbound queue until some additional level of validation has occurred.
User level filtering is more technically challenging to implement, and really only necessary for organizations whose primary revenue streams depend on peer initiated messaging, or who face constant abuse. These are the organizations who are already running marathons, many of whom have abuse staff dedicated to stopping spam. These orgs may employ techniques like creating authentication profiles for their users (ex: patterning user-sessions based on IP geolocation… if the org spots an anomalous login, the session is halted), or applying a more holistic perspective to filtering, like aggregating content sent across multiple connecting IP addresses (rudimentary example: if outbound messages have the same md5 hash, quarantine the relevant emails).
If you’ve done all of these things and the bear is still chasing you, go nuclear. Remove all possibilities of user configured text, and instead provide some level of customization via prefabricated choices. Once spammers lose their payload delivery vector, they’ll go away.
Over time, you may even be able to relax your security measures some. Just be ready to tighten those laces again at a moment’s notice.