I own a website.

The website connects between people providing a service ("servicers") and people interested in receiving that service ("servicees").

A servicee performs a search on the site and gets a list returned of possible servicers. Then the servicee can send the servicer a message through the site (the servicer's direct contact info is not provided).

I recently had a spammer contact a bunch of servicers in the way described above.

I took care of this one problematic spammer by blocking his ip and email.

I am wondering if there are any suggestions for how I might stop future spammers like this from doing the same thing. One possibility is to have all messages go though some sort of human validation. Is this a reasonable approach? (messages aren't too long and are very sparse at the moment). Are there any other approaches? Things that other companies do? (I currently have a Captcha set up when a user registers).

Also, I suspect that this one spammer might have come from my new AdWords campaign, I'm thinking of changing around the keywords to attract less attention. If anyone has any insight in this regard as well I'd be happy to hear it.

Thank you.

  • 1
    Captcha upon registration does not prevent somebody writing some code to spam your servicers. Maybe you could try using captcha for every message user wants to send.
    – n32303
    Aug 19 '16 at 8:16
  • That's an interesting idea, although I don't think this spammer used anything automated. He didn't send out that many messages. Although, when I looked at the access log for his IP his use of the site (1.5 hrs) was very strange, he clicked on a lot of (unrelated) links several times...It definitely didn't look like the behavior of a human.
    – theyuv
    Aug 19 '16 at 8:24
  • 1
    Some rate control tied to account and IP might also help here.
    – billc.cn
    Aug 19 '16 at 10:21
  • 1
    You could pass each message through SpamAssasin or similar and present a captcha if it is flagged as spam. Aug 19 '16 at 15:22
  • 2
    @theyuv rate control would impose a limit on a number of messages sent in a certain period of time. This would at least slow down the spammer while you manually deal with them. Aug 19 '16 at 15:23

This is an age old battle I'm afraid, well as old as the internet at least!

The comments pretty much add up to the answer, but in an attempt to summarise;

Having things in place to stop automation is good, but will not stop all spam successfully, and not just spam, but messages which breach your terms of use (I'm guessing passing direct communication details for example?).

If you have a small number of messages to deal with currently, then passing them through a "human filter" is a possibility, but this could become a problem as the number of messages increases.

At that point you could explore other options such as community moderation, or automated things such as keyword matching, rate limiting etc.

You could establish an algorithm for triggering the human filter. For example, you might decide that if a new user sends messages to x number of servicers in y amount of time, that a human should look at the messages.

tl;dr; Only you can say for definite what constitues and a message you would like to prevent/detect, and while automation prevention is essential, you may want to pass messages/users which match specific criteria through a check by a human.


Typically, you approach such problem in two steps:

First, prevention: you attempt to prevent automation as much as possible. This means trying to find out if a client interacting with your service is controlled directly by a human being or if it is some form of autonomous software or script. CAPTCHA is a simple way to do that although it is far from perfect (it's not that usable and most have known to be broken). Still, when used properly it does raise the bar for a would-be attacker quite a bit and isn't too annoying for the users.

Typically, you also add some form of rate control to limit the damage in case someone manages to overcome the CAPTCHA (maybe manually). Rate control is a mechanism that limits the rate at which outgoing messages are accepted. A simple scheme is to limit each account to sending a fixed number of messages per day (how many depends on what you're doing).

The second step is recovery: you provide an easy way for recipient of spam messages to report it. Depending on what your application looks like, you can even make it automated: if a 10 different users reports the same sender as a spammer, chances are they are right: you can automatically ban the offending account from sending any new message pending investigation and "delete" any unread messages dropped in other people's inbox (don't delete them, just hide them until you un-ban the sender). That's what stackexchange site does: it allows you to mark a pots as spam and if enough people with a good reputation do it, the message is automatically deleted.

Of course, in order for the spam reporting to work, you also need someone to check on the reports in order to decide of the final outcome: ban the user or release his messages.


Charge for your service. Either the spammers will go away, or you get rich. Either way, no problem. For a slightly more user friendly solution, give the cash to the spamees in the form of credits to use the service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.