"Challenge Response" antispam systems send an automated reply to an email, asking the original sender to confirm their authenticity in a reply before the original message will be delivered. The idea isn't to block Unsolicited Bulk Email (UBE), but rather to allow only email from humans (who can discern that a response to the challenge is necessary). This prevents email from automated systems from being delivered.

Challenge/response systems are not good for fighting spam and should especially not be used if you need to receive email from automated systems or new potential contacts. Many senders will find the additional burden annoying, possibly preventing communication. The requirements of the challenge may also be too confusing or simply go unread, causing messages to be delayed or go completely unconfirmed. And, since these systems are fundamentally designed to simply prevent automated email from reaching your inbox, they will not reject unsolicited bulk email at the SMTP layer.

SpamStopsHere and Challenge Response System

SpamStopsHere does not offer a Challenge Response system because they don't block unsolicited bulk email (spam). Rather, they are designed simply to prevent automated email, which includes mailing lists and email confirmations from automated systems (e.g. commercial product order confirmations or electronic filing confirmations), from reaching the recipient's inbox.

Challenge Response System Weaknesses When Used For Anti-Spam

Although C/R systems are simple to implement and don't require any software updates, they have numerous weaknesses when applied as anti-spam systems:

Misplaced Burden

One should not place the burden of an anti-spam system on the sender. Although placing the burden on spammers may be considered quite valid, the problem comes with any legitimate e-mail, where the C/R system mistakenly places the burden on an innocent sender to confirm incoming e-mail so that the recipient doesn't have to review any unconfirmed e-mail messages. The recipient is receiving a benefit, which the sender is paying for. Perhaps this would be okay if the recipient paid senders to confirm their e-mail messages. Some challenge/response system supporters equate this burden on the sender as the same "inconvenience" that a telephone solicitor has historically had when trying to get past a telephone operator to talk to a decision maker. A better analogy would be that one is requiring a second phone call to be placed. Most organizations offer a service or product and can not expect potential customers to jump through hoops before being able to contact your organization. A business that required potential clients to place a second phone call in order for their first phone call to be handled appropriately would soon find that it stops receiving phone calls from potential clients.

Many challenge/response systems are configured to send a challenge to anyone trying to reply to an e-mail message. The user of a challenge/response system may find that e-mails go unanswered because the recipient of the e-mail message was nice enough to take the time to reply to the user's e-mail message, only to find that the reply went undelivered. That can be annoying enough for the responder to not waste any more of his or her valuable time assisting by confirming the response.

Unconfirmed Automated Messages

Although some supporters of challenge/response systems will say that this is by design, C/R systems prevent automated messages from being confirmed and therefore read by the recipient. There are very few e-mail users that don't require the ability to subscribe to and receive automated messages from mailing lists for important up-to-the-date information in one's industry. Additionally, with the advent of online purchasing, where more and more people are purchasing at least one item online a year, users will need to receive confirmations of their order by e-mail from automated systems. Some challenge/response system supporters indicate that the way to properly handle e-mail from automated systems that one wants to receive e-mail from is to manually confirm the sender beforehand. This usually isn't possible, as many automated systems don't offer enough information to discern what e-mail address the automated e-mail messages will come from.

System Stalemates

If the sender and recipient both use challenge/response systems, the two entities may never be able to communicate. If someone with a C/R system sends an e-mail message to someone else with the same type of system, the sender may never receive the challenge, because the challenge may simply result in the original recipient's challenge being challenged by the original sender's system.

Confirmations Are Easily Defeated

If spammers really wanted to ensure that the e-mail that they sent to a challenge/response system got confirmed, they would simply need to use a valid e-mail sender e-mail address and have an automated system respond to the challenges.

Additionally, the confirmation instructions in a challenge, no matter how well written, are often confusing enough to prevent even the most legitimate senders from successfully responding to the challenge, especially in a timely manner. Many challenges may also simply go unread, preventing the sender's e-mail message from ever reaching the recipient's inbox.

Challenges Cause Abuse

Because spammers typically forge the sender's e-mail address, most challenges are being sent to invalid e-mail addresses, or worse, the innocent victim owners of those e-mail addresses. To make matters worse, a spammer or other malicious entity could easily use the challenge/response system to bombard a victim with challenges by sending a large amount of e-mail messages to the C/R system that appear to be from the victim's e-mail address. This vulnerability is inherent to all auto-response systems, and not simply C/R systems.

Spam Is Still Accepted

Even though most automated system generated spam may never reach the user of a challenge/response system's inbox, the e-mail is accepted from the spammer for delivery. As far as the spammer (who often doesn't get the challenge) knows, the e-mail was delivered successfully. It is now well accepted that one shouldn't accept spam from the spammers, but instead REJECT it at the SMTP layer.

Recommendations

If one is going to use a challenge/response system, there are implementation guidelines that one can follow to help address some of the problems inherent to the system:

  • Ensure that the recipient of any of your outgoing e-mail messages is already confirmed, to allow replies. After all, you solicited the reply.
  • To prevent abuse, ensure that no more than one reply per hour is sent when responding to email messages from the same email address or IP address.
  • Find a way to be interoperable with other C/R systems so that the system doesn't send challenges to challenges, but instead delivers them to the inbox.
  • Say "please" in your challenge's response instructions and don't be rude and use any terminology that suggests that the sender's e-mail may be spam if the sender refuses to respond. One may also want to list a phone number, in case the sender has become frustrated enough with trying to give up on contacting you by email.
  • Put e-mail messages that go unconfirmed into a quarantine that is frequently reviewed. Of course this prevents the use of the system as an anti-spam system. One might as well not use the system and review the messages in real-time in the inbox.