Revision as of 09:09, 15 June 2009 by Johnl (talk | contribs)
Jump to navigationJump to search
Anti-spam technique: Challenges
Date of first use: 1990s
Effectiveness: Medium
Popularity: Low
Difficulty of implementation: Medium
Where implemented: MTA or MUA
Harm: High

Challenges or Challenge/Response (C/R) attempts to validate unknown senders by replying to their mail with a challenge message. If the sender responds to the challenge in a way the C/R system approves of, the mail is delivered and the sender is whitelisted. The expected responses may be any return e-mail (typically to a coded address in the Reply-To: header), a return message with a particular key phrase, a clickthrough to a web page, or a clickthrough followed by solving a Captcha problem.

C/R systems are widely considered to be abusive and ineffective. Problems include:

  • They generate backscatter harming innocents - most spam has forged sender addresses, so most challenges are sent to people who had nothing to do with the message being challenged.
  • They don't work with messages sent by anything other than an individual human sender: newsletters, receipts and other transactional messages, and so forth.
  • Recipients of challenges to forged mail often confirm them, since that's the easiest way to make the challenge spam go away.
  • It can generate loops - if two poorly configured systems challenge each other's mail, an indefinite mail loop can result.
  • Delays are introduced, which may be larger if the sender doesn't immediately receive the confirmation request or simply doesn't have access to network for some reason.
  • Access control is often managed by senders, not by the mailbox owner. One of consequences is that if a spammer wants to send messages to someone it's enough to send a first message from some email address under his control, in order to confirm the captcha.
  • Message loss - many senders do not respond to challenges.