Monday, February 12, 2007

Salesforce spam: fixing web-to-lead

For more than 3 years, I’ve been a very happy Salesforce.com user. Unlike more bloated CRM applications that require training, lengthy implementation cycles and user revolt, Salesforce.com is in the sweet spot of sophistication and simplicity. For us at FeedBurner, it’s been a great way to scale our lead management and is taking a growing role in proactive communication with customers and partners. Its web-to-lead feature, which lets you connect a web form to your Salesforce.com install to seamlessly create leads within Salesforce.com, is great.

Over the last 9 months, however, we’ve been plagued by a phenomenon all too common with weblog publishers: spam. The exploit is simple: spammers scrape your lead intake form, capture your Salesforce.com OID number, and then use that to bypass your form and hit the Salesforce.com lead submission script directly. The result? Thousands upon thousands of bogus leads cluttering up our system, and very annoyed users at FeedBurner. Not Good. (And not new either.)

I assumed we were missing a simple fix, so I submitted a case to Salesforce.com support. No dice: “Find a way to secure your form, and the problem will go away.” Nice try, guys, but the problem’s not our form: we use Javascript to force the selection of a value in several fields, so someone trying to auto-submit our form would be blocked from submitting. No, the problem was that they were bypassing our form and submitting the data to Salesforce.com directly. After several calls and twice escalating the case to Level 2 support, Salesforce.com wouldn’t budge: Not their problem.

As I see it, this is absolutely a Salesforce.com problem. And hopefully they’ll recognize that. (As I mentioned in the IdeaForce post linked above, simply hooking up to Akismet would be a huge step forward.)

But until they do, I figured I’d document what we’ve done to stem the tide of Cialis, Viagra, Phentermine and Online Casino leads that have been polluting our system for months. Thanks to the good folks at Arrowpointe for their suggestions over at Perspectives on Salesforce blog. Two weeks ago, they documented their approach, which is conceptually what we’ve done.

This requires using Validation Rules (click “Setup” then “Customize” then “Validation Rules” (under “Leads”)). Click New to create a new validation rule, and then enter in your rule. Here’s ours:

What it does: in a field that identifies the lead as created by Web to Lead (“ourfieldname” and “ourwebtoleadfieldvalue”), it looks for any of the text in the description fields that matches the strings in quotes. In addition to the popular pills, I threw in strings that don’t get submitted in valid leads but are almost always included in spam submissions: hyperlinks (formatted in either HTML or in popular bulletin board markup, [URL=]).

When a lead matches this rule, it effectively aborts the lead creation process (computationally intensive for Salesforce, but as they pointed out, this isn’t their problem!) and triggers an alert message to the default lead owner. Eric is the designated default owner, so he now has a rule in Gmail that traps the alert message and throws it away.

We’re keeping an eye on things. So far, it appears to have been largely successful. It’s already blocked dozens of spammy leads, while letting legit ones through. If it starts missing spam leads, we can tweak our rules to match to other criteria (there are a handful of names that appear to be pretty popular), so this should be flexible enough to keep up with the arms race that is form hijacking by spammers.

(For those that wonder why they’d do this, my best guess is that they’re simply trying to submit to the form to capture as many valid e-mail addresses as they can by seeing what auto-responder rule gets triggered by Salesforce.com when a lead is submitted. They can then add that e-mail to their spam list, which they’re presumably selling to others. Anyone have any other ideas what they might be up to?)

Are you using Salesforce.com? Are you seeing similar spam problems? What are you doing to tackle them?

Steve - I have looked at Sugar in the past. It's a phenomenal SFA tool - much more than we needed when we got started with Salesforce. At the time we started we had just 3 people hitting the app, and we've now grown to a dozen or more. That said, we need basic contact management, account assignment, etc. - and when I looked at Sugar, it was really overkill for our pretty simple needs. If we were a more sophisticated shop, I think it'd be a great alternative to Salesforce.

SPAM is a huge problem, but you already knew that. :-). Email was one thing, but it's starting to overwhelm any and everything, especially with social media. Myspace, Facebook, even mybloglog are starting to become spammer havens! I'm pretty sure FreeiPhone isn't a real reader on my blog. Now that it's starting to infect enterprise software, is really pissing me off. This is a problem for everyone, but in this case, SalesForce should most definitely do something. I'm personally not a huge salesforce fan in terms of the application (too cumbersome and ugly), but love salesforce as a company. Simple reasoning: if something is making your app not work the way it should or decrease its performance for your users, especially paying ones, it is your problem. I'll definitely be following this meme/discussion.

I think that these bot programs are unfortunately trying to post most of this stuff as blog comment spam, and they just get caught up in any form they can submit. So they wouldn't want these submissions going into a private system like Salesforce.com, but of course they don't really care.

I've just used assignment rules and created a queue called "delete" which doesn't show up in any of my standard views. Then I can mass delete anything in this queue a few times a week.

Rick, the more likely reason that your form is being spammed is that spam bots are indiscriminate. They're filling out every form they can, trying to leave some sort of visible spam droppings.

Feed Crier is getting hundreds of subscription attempts an hour from spammy user names. The local Cub Scout site I run gets dozens of fake signups a week. A honeypot form I have sitting in an undisclosed location on a high PageRank site is filled out thousands of times a day.

They're just spam bots that are filling out forms, hoping to hit a blog comment form or a guestbook form.

The lesson to web services is, if you have a public form, expect it will be submitted by a bot and prepare for what that will do to your app.

If you could share the case # that you submitted where you got this response, I can follow up with the rep and make sure they are aware of some solutions we have.

We recently created a solution that is similar, but slightly different than your solution. It involves using javascript to set a hidden field to the document location, and then using validation rules to check for this. It's basically obfuscating a shared secret, with the assumption that most bots won't set the document.location property and fill in the hidden field. This trick also involves allowing regular users to create leads in the UI, which involves passing another hidden field that's always set in the web2lead form.

We've also kicked around the idea of checking the referrer, but it turns out not all browsers set it.

A CAPTCHA is not acceptable to most customers who are generating leads.

It looks like you posted on IdeaExchange about Akismet. We'll take a look at that as well. I know SXIP had a solution to blog spam, not sure if it was similar to this.

There doesn't seem to be a one size fits all solution here, but I'm curious to hear if your solution continues to work. If so, we'd like to be able to add it to our public knowledge base until we come up with a product enhancement to help address web2x spam.

Benji - Thanks so much for the comment. I'll send my case # by e-mail.

3 days in, this seems to have stopped the vast majority of spam leads. This is why I think it's solvable by Salesforce: rather than force all customers to duplicate this filtering system, you could implement something centrally that traps for obvious spam. (Using just the above rules I've already stopped 99% of the bogus leads generated. If I put a little more effort into it, I could probably boost that to 99.99%.) This is what Akismet would do for you - bring the power of a community of hundreds of thousands of sites to bear on identifying what would be "obvious" spam, and offloading the evaluation of that to a service dedicated to the task.

Whatever the solution, it's great to know that you're aware of it, and glad to hear that you're looking at ways to improve the system. Keep up the good work.

We use our own form to validate and capture sales leads, and when that form is submitted a server side perl script submits the information to salesforce using web-to-lead. This avoids exposing our OID and also allows us to do some custom logic on the leads we get.

Between this and validating the email address on the form, we rarely get any lead spam.

If you're interested, I can check with our IT guys about sharing the perl code.

Rick, wow, just when you think spam is under control they find another way to get their garbage in front of us. And you're right, Salesforce could easly cut this off - good for you to put the pressure on them. Most of their users are not technical enough to understand where it is coming from and complain.

If I may suggest something - another web-based CRM system you might want to look at is Big Contacts. It is for people for whom salesforce is overkill but still want all the important core contact management features. We just launched last month and are growing quickly. Sales opporutnity tracking is being added this week. And there will be an open API, so you can roll your own lead tools.

I predict this will stop web-to-lead spam for as long as blacklisting stopped weblog comment spam... which is to say, not very long.

There is no ultimate solution (apart from not putting forms on the web; obviously not practical) but at the moment the best approach seems to be Akismet. It'd be nice to see Salesforce implement this so individual users don't have to come up with their own band-aids.

We have had the spam issue for about two months now. At first, just the usual pharma and auto loan stuff. No big deal, 10/week. Bu then the deluge came from the spammer using these names and emails:

Arnie Arnie Arnie BillArnie DieselArnie HeroArnie Jane

At Salesforce suggestion, we created a Junk Leads Queue which routes all of this mail (those submitted with no company name). That works great,. Trouble is, the Junk Leads Queue is an Owner Alias that still mixes these leads within the General Leads Queue and Mass Deleting them through the Setup menu requires 10 clicks. A pain! To date, we have received more than a thousand of these spam.

Soooo, we tried installing a hidden field on our SF web to lead form that track IP. The idea was to track which IP they were coming from and block them. That works for the drug, auto loan and other small scale spam, but the people using the spam names above must be using some sort of dynamic IP generator because it does not come through into SF.

This is becoming a major problem for us and to me SF needs to fix it. The Junk Leads Queue solution would work just fine if Salesforce could route these leads to the Recycle Bin directly instead of making me do 10 clicks to get rid of them. Does anyone have any ideas on how to get junk leads to route automatically to the Recycle Bin using Lead Assignment rules?

I just posted another Salesforce spam solution on my blog. I created a PHP script that you can post your web to lead forms to and it will validate whether it's spam or not against the Akismet spam detection service.

according to my experience web content manager of officeClip is best it have Security Levels – Fine-tune who can access what information at organization, role and user level.Tracks Contacts, Accounts, Opportunities for your organization Tracks Appointments, Tasks, Notes, Issues, Documents etc. Provides ability to create and track campaigns and many other feature ,

SugarCRM is abysmal compared to salesforce. We used it for a year. Might have destroyed my company. Too many issues to list. After 3 months with Salesforce, we're completely won over. Using SugarCRM instead of paying the small amount for Salesforce was the stupidest, most penny-wise and pound-foolish thing I've ever done in my life.