Challenge–response spam filtering

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. It was originally designed in 1997 by Stan Weatherby, and was called Email Verification. In this reply, the purported[lower-alpha 1] sender is asked to perform some action to assure delivery of the original message, which would otherwise not be delivered. The action to perform typically takes relatively little effort to do once, but great effort to perform in large numbers. This effectively filters 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.

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

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 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. For example, converting a date string (such as 'Thu Jan 12 08:45:44 2012') into its corresponding timestamp (1326379544). 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 lets messages 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 legitimacy and usefulness as an email defense.[3] 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 and which may be treated the same as any other Unsolicited Bulk Email (UBE) by the receiving system, possibly leading to blacklisting of the mail server or even listing on a DNSBL. 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 must implement some form of return address signing (such as Bounce Address Tag Validation) to ensure that the challenge goes through. Also, if systems like SPF and DKIM became 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 results in challenges to those who send mail to that address. 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 is, the more understood, accepted and appreciated they are. 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 can be lost, and legitimate mail sent by these systems may not reach the C/R system user.

Advocates of C/R systems argue that, though it takes extra effort, solutions for these problems exist if the end-user behind the C/R system does these simple things:

  • Whitelist a mailinglist address manually as soon as one subscribes to it. Note: for many email groups, the new member won't know the group's address until after receipt of the "welcome" email, thus making this recommendation unworkable.
  • Use 'tagged email addresses' for mailinglists or automated mailers like the above, that can be recognized and cleared automatically by the C/R system.
  • Manually inspect the message queue and overriding the C/R process in case where the C/R system holds an expected message from an automated mailer.

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.

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. 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, and is 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[4] ("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.

Notes
  1. See #Challenges sent to forged email addresses.

References
  1. RFC 3834: Recommendations for Automatic Responses to Electronic Mail
  2. Templeton, Brad. "Proper principles for Challenge/Response anti-spam systems". Retrieved 13 June 2014.
  3. Schryver, Vernon. "Challenge/Response systems considered harmful". Retrieved 13 June 2014.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.