Challenge–response spam filtering

This article is about e-mail. For other uses, see Challenge-response authentication.

A challenge–response (or C/R) system is a type of spam filter that automatically sends a reply with a challenge to the (alleged) sender of an incoming e-mail. In this reply, the sender is asked to perform some action to assure delivery of the original message, which would otherwise not be delivered. The action to be performed is typically one that

• can be performed once relatively effortlessly, but
• needs great effort if performed in large numbers, in this way effectively filtering out spammers.

Challenge–response systems only need to send challenges to unknown senders. Senders that have previously performed the challenging action, or who have previously been sent e-mail(s) to, would be automatically whitelisted.

The challenge in challenge–response systems

C/R systems attempt to provide challenges that can be fulfilled easily for legitimate senders and non-easily for spammers. Two characteristics that differ between legitimate senders and spammers are exploited in order to achieve this goal:

• Legitimate senders have a valid return address, while spammers usually forge a return address. This means that most spammers won't get the challenge, making them automatically fail any required action.
• Spammers send e-mail in large quantities and have to perform challenging actions in large numbers, while legitimate senders have to perform it at most once for every new e-mail contact.

Listed below are examples of challenges that are or could be used to exploit these differences:

• Simply sending an (unmodified) reply to the challenging message.
• A challenge that includes a web URL, which can be loaded in an appropriate web browsing tool to respond to the challenge, so simply clicking on the link is sufficient to respond to the challenge.
• A challenge requiring reading natural language instructions on how to reply, with the inclusion of a special string or pass-code in the reply. Other Turing Test approaches include a simple problem, or answering a simple question about the text or the recipient.
• Systems can attempt to produce challenges for which auto response is very difficult, or even an unsolved Artificial Intelligence problem. One example (also found in many web sites) is a "CAPTCHA" test in which the sender is required to view an image containing a word or phrase and respond with that word or phrase in text.

Nowadays C/R systems are not used widely enough to make spammers bother to (automatically) respond to challenges. Therefore C/R systems generally just rely on a simple challenge that would be made more complicated if spammers ever build such automated responders.

Recommendations for C/R systems

C/R systems should ideally:

• Allow users to view and act on messages in the holding queue.

• Comply with the requirements and recommendations of RFC 3834^[1].

• Obey a detailed list of principles maintained by Brad Templeton ^[2], including allowing for the creation of “tagged” addresses or allow pass-codes placed in either the Subject: header or the body of the message—any of which allow messages to be accepted without being challenged. For example the TMDA system can create "tagged" addresses that permit:
  • mail sent from a particular address
  • mail that contains a certain “keyword”
  • mail that is sent within a pre–set length of time, to allow correspondence related to an online order, but which then expires to disallow future marketing e-mail.

Problems with sending challenges to forged email addresses can be reduced if the challenges are only sent when:

• the message header is properly formed
• the message is sent from an IP address with an associated domain
• the server has passed a greetpause test
• the server has passed a greylisting test
• the originating IP address is not found on trusted blacklists
• the sender's email address has not failed an E-mail authentication test, using techniques such as SPF and DKIM.

Criticisms

Critics of C/R systems have raised several issues regarding their usefulness as an email defense. A number of these issues relate to all programs which auto-respond to E-mail, including mailing list managers, vacation programs and bounce messages from mail servers.

Challenges sent to forged email addresses

Spammers can use a fake, non-existent address as sender address (in the From: field) in the e-mail header, but can also use a forged, existing sender address (a valid, but an arbitrary person's address without this person's consent). The latter would become increasingly common if e.g. callback verification would become more popular to detect spam. C/R systems challenging a message with a forged sender address would send their challenge as a new message to the person whose address was forged. This would create e-mail backscatter, which would effectively shift the burden from the person who would have received the spam to the person whose address was forged. In addition, if the forged sender decided to validate the challenge, the C/R user would receive the spam anyway and the forged sender address would be whitelisted.

Though definitely an undesirable side-effect, this issue would be non-existent if people, whose email address was used as a forged address in spam, happen to run a C/R system themselves. In this case, one of the C/R users would need to implement some form of return address signing (such as Bounce Address Tag Validation) in order to ensure that the challenge goes through. Also, if systems like SPF and DKIM would become common, forged sender addresses would be recognized by these systems before reaching a C/R system.

In some cases, C/R systems can be tricked into becoming spam relays. To be useful, some part of the message under challenge is generally included in the challenge message. A spammer, knowing that he's sending to a C/R using system, could design his message so that his "spam payload" is in the part of the message that the challenge message includes. In this case, the forged sender is the actual recipient of the spam, and the C/R system unwittingly is the relay.

Social issues

Disseminating an ordinary email address that is protected by a C/R system will result in those who send mail to that address having their messages challenged. Some C/R critics consider it rude to give people your email address, then require them (unless previously whitelisted, which might not always be possible) to answer the challenge before they can send you mail^[3].

Advocates of C/R systems argue that the benefits by far outweigh the 'burden' of an incidental challenge and that there will probably never be a final solution against spam without laying some kind of burden on the e-mail sender. They reason that the more widespread the use of C/R systems will be, the more understood, accepted and appreciated they will be. In an analogy with snail mail, the sender is prepared to pay for the stamp, in an analogy with phone calls, the caller is prepared to pay for the outgoing call.

Interaction with mailing lists or other automated mailers

Some C/R systems interact badly with mailing list software. If a person subscribed to a mailing list begins to use C/R software, posters to the mailing list may be confronted by challenge messages. Order confirmations, billing statements and delivery notices from online shopping systems are usually sent via automated systems. Email challenges sent to such systems will be lost, and legitimate mail sent by these systems will not reach the C/R system user.

Advocates of C/R systems argue that, although it will take an extra effort, solutions for these problems exist if the end-user behind the C/R system will do these simple things:

• whitelisting a mailinglist address manually as soon as one subscribes to it.
• using 'tagged email addresses' for mailinglists or automated mailers like the above that can be recognized and cleared automatically by the C/R system.
• manually inspecting the message queue and overriding the C/R process in case an expected message from an automated mailer is held by the C/R system.

False positives

C/R advocates claim that such systems have a lower rate of false positives than other systems for automatically filtering unsolicited bulk email.^{[citation needed]}

Critics argue that typical users of C/R systems still need to review their challenged mail regularly, looking for non-bulk mail or solicited bulk email for which the sender has not responded to the challenge.^{[citation needed]} This issue is particularly notable with newsletters, transactional messages, and other solicited bulk email, as such senders do not usually check for challenges to their mail. However, if the bulk email in question was solicited, then the C/R user could be expected to have added it to the whitelist. If the bulk email was not solicited, then by definition it is spam^{[citation needed]}, and will be properly filtered by the C/R system.

Implementations

• Tagged Message Delivery Agent
• Channel email <- Just wants a reply, doesn't actually try to determine if the user is human (thus getting rid of the spammers that don't use legitimate emails and doesn't require costly processing).
• FairUCE[1] ("Fair use of Unsolicited Commercial Email"), developed by IBM, tried to find a relationship connecting the envelope sender's domain name and the IP address of the client delivering the mail, using a series of cached DNS look-ups. If a relationship could be found, FairUCE checked the recipient's whitelist and blacklist, as well as the domain's reputation, to determine whether to accept, reject, challenge on reputation, or present the user with a set of whitelist/blacklist options. As of 2010, the project is listed as "retired" technology.

References

1. ^ RFC 3834: Recommendations for Automatic Responses to Electronic Mail
2. ^ Proper principles for Challenge/Response anti-spam systems
3. ^ Challenge/Response systems considered harmful

External links

• SpamHelp Challenge/Response Services A listing of challenge/response filtering service providers
• When Spam Filters Aren't Enough, Walt Mossberg of Wall Street Journal, March 22, 2007
• Why Challenge-Response is a Bad Idea July 2006
• Challenge-Response systems make matters worse February 2006
• Challenge-Response Anti-Spam Systems Considered Harmful December 29, 2003
• John Levine: Challenge-response systems are as harmful as spam May 2003
• A Challenging Response to Challenge-Response May 2003
• What You Need to Know About Challenge – Response Spam Filters 2003