Challenge/Response still exists, and it's still a problem

Challenge/Response is a specific type of email filter. If you use a Challenge/Response (C/R) spam filter to protect yourself from spam, here's what happens:

1. Your email server or service receives a new inbound email message.
2. The system checks to see if this is a person that you've talked to before.
3. If yes, the mail is forwarded to you, skipping the challenge step.
4. If no, the mail is NOT forwarded to you, and the sender receives a notification back -- a "challenge."
5. The notification encourages the sender to "respond" to the "challenge" by clicking a link, solving a puzzle (think CAPTCHA) or (this is a new one I've seen recently) paying a designated charity.

The charity angle might be new; but C/R has been around forever. I know well how it works, having built my own implementation of it back in the late 1990s. And I've been pointing out the imperfections behind the concept since all the way back in 2006. It seems to pop-up again every few years, leading me to have a modest, but non-empty, section on Spam Resource covering just C/R.

There were a couple patents covering Challenge/Response as a spam filtering mechanism, but those no longer seem to be in force, and the patent troll who used to go around suing companies about it seems to have sold his company to AOL long ago.

Challenge/Response is a premise flawed from the start in that it can't be done any way but imperfectly and annoyingly, in my ever-so-humble opinion. Thankfully, email technology has evolved since I built my own C/R filter in the late 1990s, perhaps softening a few of those imperfections, but even with improvements in email authentication and bot detection, implementing C/R involves making a series of tradeoffs that lead to something that just won't work quite right all the time.

I can understand the desire to use C/R. Oh, trust me, I do. I get too much "cold lead" spam and C/R is often touted as a way to make it stop. But at what cost? Because there are a lot of limitations, caveats, and imperfections in how this all works.

C/R doesn't play nice with bulk emails. And whether or not you like it, a lot of the legit emails you receive (password resets, order receipts, etc.) come from automated systems. They're not 1:1 emails from individual people. There is no individual to reply to. The visible from address is often a "noreply" address (and whether or not you think "noreply" is a bad practice, it's out there) and the return-path/envelope sender address is often meant to capture and process bounces (usually using something like VERP). And a reply-to address in general shouldn't be trusted (or in the case of a lot of these is going to fall into a ticketing system). So there's literally nobody there to respond to the "challenge," regardless of what address you respond to. And when these bulk messages are indeed solicited, the recipient is pushing extra work back onto the sender, that just is not scalable. In my personal experience, I know that no legitimate ESP is going to set up a mailbox and have a human respond to the numerous challenges likely to be generated.

That means the end user never gets their password reset email. Thus, the C/R service typically needs a way to address that, leading to even more imperfect choices. Usually, this means dropping un-responded messages into a quarantine queue. But now the recipient's C/R experience is diminished by having to go look at a folder full of mostly spam to try to dig out which order receipts or password resets they actually wanted. Or, the C/R system may choose to implement a system-wide whitelist to let messages from various bulk email platforms through automatically. Also problematic, because sometimes those systems get abused to send spam. And spam will drip through, leading to unhappy users of the C/R filtering system -- they don't always understand that C/R doesn't play nice with automatic "bulk" mail, and that not all "bulk" mail is spam. Damned if you do, damned if you don't.

The spam problem is one of consent. A C/R system doesn't really know much about consent. Users cobble together a consented sender list by whitelisting everybody they can think of. A C/R system might help a user parse their mailbox to facilitate that process, but still, imperfectly, because it's not going to know about people who haven't written you yet, from some specific address they don't know about yet. (Like when I changed jobs last year and my work email address changed.)

A C/R user is outsourcing their spam filtering externally. This can lead to unexpected results. Does the C/R filter always know how to avoid sending challenges in response to spoofed mail? Sending a challenge to the wrong address is a type of "backscatter" and it's a scourge. Hopefully minimized today, in modern C/R systems, thanks to email authentication. But some legit mail does fail email authentication tests, so do you skip sending the challenge, and thus the legit message falls through the cracks? Yet another example of damned if you do, damned if you don't.

Then there's the insult and delay inherent to the process. The newest version of C/R seems to involve "pay money to a charity" to pass your message through. I didn't find it amusing to receive that as a "challenge" in response to escalate an urgent support ticket with a vendor on a Friday evening. When it happened to me, I thought to myself, you know, we already pay this vendor a lot of money. Now I have to put more coins in the slot to be able to communicate with this person? And the vendor's C/R tool provider takes a cut of that? What?! I understand their frustrations about spam -- I share them -- but all this did was sour the support experience for an existing customer.

And this doesn't even really stop that cold lead spam email from somebody who is truly determined. It just slows them down.

When you think about building this sort of thing, you might think of RFC.5321 versus RFC.5322 from addresses, interactions with bounce processing, playing nice with the largest CRM/ESP platforms, preventing challenges being sent to addresses forged in spam, slowing down legitimate communication while still letting hand-crafted cold lead spam through -- any switch your set one way to address one problem has the potential for a different problem to bubble up somewhere else. No design choice comes with a cost that impacts a user (or a sender to that user) in some other bit of the process.

It's kind of a Rube Goldberg-esque mess, because while the problem is consent, the machine can't really well determine consent. And in the end, a sender can usually still get to a C/R user's inbox, non-consensually. It just takes extra clicks and/or a donation. Not all senders will follow through, but some will, and users will miss some amount of legitimate email in the meantime. What good is a spam filter that offers a way for the spammer to bypass it?

The charity angle is a new one, but the concept of applying a financial cost to inhibit spam is not that new; Bill Gates told us back in 2004 that charging the cost of an e-stamp would solve the spam problem forever. Well, it's about eighteen years later, and we're still waiting. All the potential problems faced with the design of that and other systems since then -- it makes me wonder about the risks of fraudulent transactions, stolen e-stamps and credit cards, hijacked systems and the overhead of payment processing for micro-transactions just seemed insurmountable at the time. Grafting payments onto C/R is certainly not something I would have ever considered, given the potential challenges in both the payment models and spam filtering systems. But who knows -- I don't know everything, and my name isn't even on patent US20060075028A1.

I will note in closing, that Challenge/Response is used a lot less often, and there are a lot fewer implementations of it today, compared to years past. That's not because of patent trolling, I think, but likely more due to an evolution of spam filters to more modern mechanisms and filter implementations, with better fingerprinting, engagement as a measure, and so on. C/R is an old technology, and newer and different spam filtering concepts do more and scale better to help solve the spam problem, beyond the level of the individual mailbox.