Re: Challenge-response mail filters considered harmful (was Re: Look at these update from M$ Corporation.)
On Sun, Aug 03, 2003 at 05:13:26AM +0100, Karsten M. Self wrote:
> As some here are aware, I maintain a rant-o-matic with some standard
> screeds on frequently iterated issues. The C-R issue is one that's been
> nagging at me for a while, here's the draft of why C-R is considered
> harmful. Critique/comment welcomed.
>
> You're problably receiving this because I've received a C-R from
> your mail system. If you've received this, that is....
>
> Spam is a growing, heck, exploding problem. No doubt.
> Challenge-response (C-R) is a flawed tactic, for the following
> reasons.
>
> 0. Weak, and trivially abused, verification basis.
>
> The 'FROM:' header of email can be, and routinely is, spoofed.
> It offers no degree of authentication or evidence of identity.
As filtering is a spam-reduction system, so is C-R. The chance of
receiving spam from a whitelisted address is, in the experience of tmda
users, very rare. And even if it happens, it only adds up to low
statistics.
>
>
> 1. Misplacement of burden.
>
> Effective spam management tools should place the burden either
> on the spammer, or at the very least, on the person receiving
> the benefits of the filtering (the mail recipient). Instead,
> challenge-response puts the burden on, at best, a person not
> directly benefitting, and quite likely (read on). The one party
> who should be inconvenienced by spam consequences -- the spammer
> -- isn't affected at all.
The spammer is affected in the same way as it is affected by filtering:
it sees revenues going down, fast. Additionally, if a spammer wants to
deal with challenges, it has to not only use valid addresses, it has to
use addresses which he can read replies from. That way, it is usually
easy to report to his ISP.
>
>
> 2. Privacy violation.
>
> A record of our correspondence is being maintained by a third
> party who has no business knowing of the transaction. Many
> people will refuse to respond to C-R requests for this reason.
I don't see this point.
>
>
> 3. Less effective at greater burden than reciever-side
> whitelisting.
>
> A C-R system is essentially an outsourced whitelist system. The
> difference between a C-R system and a self-maintained whitelist
> is that the latter is:
>
> - Maintained by the mail recipient, rather than a third party.
> - Is the responsibility of the mail recipient, rather than the
> sender.
> - Places the burden on the recipient to add new addresses to
> allow/deny lists.
>
> I might add that I myself use a mix of whitelisting and spam
> filtering (via SpamAssassin) to filter my own mail with a very
> high level of accuracy, in terms of true positives, true
> negatives, false positives, and false negatives.
I don't see the third party.
>
>
> 4. High type II error (beta).
>
> Because of numerous issues in sender-compliance with C-R
> systems, C-R tends to a high false postive rate. This is known
> as type II error, in statistical tests, and is denoted by beta.
>
> The mechanics of C-R systems lead to a fairly high probability
> that users of such
I don't know anything about this.
>
>
> 5. Potential denial of service.
>
> C-R systems can be used in a denial-of-service or "Joe" attack
> on an innocent third party. In fact, this is likely to start
> happening shortly as C-R becomes more widespread.
>
> How? Simply: Spammer spoofs a legitimate sending address (this
> is already commonplace). C-R systems then send out a challenge
> to this address. With only 1% penetration of C-R, the victim of
> the C-R/Spam attack is deluged with 100,000 challenge emails.
> This could likely lead to lawsuits or other legal challenges.
This can also be done right now. I guess that people who've had their
mail addresses spoofed know this because they receive a lot of bounces,
angry mails, replies from stupid people, etc. And if a spammer really
wants to start a DoS attack, why using such an elaborate way if he can
spoof whatever address he'd like?
>
>
> 6. C-R - C-R deadlock
>
> This is almost funny.
>
> How do two C-R system users ever start talking to each other?
>
> - User A sends mail to user B. While user B's address is then
> known to A, user B's C-R server's mail is not.
>
> - User B's C-R system sends a challenge to A...
>
> - ...who intercepts the challenge with A's C-R system, which
> sends a challenge to user B's C-R system...
>
> No, I didn't think this one up myself, see Ed Felton's "A
> Challenging Response to Challenge-Response":
>
> http://www.freedom-to-tinker.com/archives/000389.html
>
> Bypassing this deadlock then opens an obvious loophole for
> spammers to exploit.
This must be very, very old. Uh, no... it's not. This guy obviously
hasn't read through tmda.sourceforge.net. I'm sorry, tmda doesn't have
a loophole. Only automatic whitelisting and dated addresses which, in
the experience of tmda users, are not a risk. And even if they were a
slight risk, C-R is a spam_reduction_ system.
>
>
> 7. Potential integration into spam email harvest systems.
>
> One commonplace piece of advice for avoiding spam is to not
> respond to opt-out, aka email validation testing, requests.
>
> C-R spoofing on the part of spammers would simply hijack a
> presumption that C-R requests were valid to provide spammers
> with higher-quality mailing lists.
TMDA _always_ includes the original e-mail, so the recipient of the
challenge can check if it really was him sending a mail.
>
>
> 8. Likly consequences.
>
> The C-R user is likely to find their own address added to
> blocklists from many users and/or mailing list adminstrators
> burned by malformed, or simply unwanted, C-R requests.
If not set up correctly, this might happen.
>
>
> 9. Mailing list burden.
>
> C-R systems typically misfunction on mailing lists in one of
> two ways, neither of which is acceptable:
>
> 1. The C-R sends a challenge to the list for messages received.
>
> 2. The C-R sends a challenge to each individual listmember for
> the first post received.
>
> In both cases, the burden is placed on a party who could care
> less about the benefits of the C-R system. Several lists of my
> aquaintance have taken to permanently banning any users who
> exhibit use of misconfigured C-R systems.
Those C-R systems are set up _very_ incorrectly. TMDA says: _don't_ mess
with mailing lists or you'll anger a lot of people. Spam send through a
list won't be blocked anyway. Don't send your mailing list traffic
through tmda and optionally use a filter. TMDA doesn't pretend to be the
ultimate and only answer to spam.
>
>
> 10. Fails to address techno-economic underpinnings of spam.
>
> Spam exists for one reason: it's profitable.
>
> It's profitable because technology allows the costs of sending
> a large number of mail messages to be lower than the revenues
> available for doing so.
>
> Any effective spam remedy must attack one or the other side (or
> both) of this equation: raise the costs or reduce the
> technological effectiveness, on the one side, or reduce
> revenues on the other.
>
> C-R, as with most recipient-side filtering systems, imposes
> negligible incremental overhead on the spammer. A delivery is
> made, the spam server moves on, the cost is a single SMTP
> connection for a fractional second. Collateral costs are high:
> for legitimate senders, spoofed reply addresses, mailing lists,
> and retaliatory actions on the C-R user.
>
> A truly effective spam defense must attack the techical and
> economic aspects, in as unobtrusive a manner as possible.
>
> The one system which seems to best fit this requirement is the
> Teergrub -- the spam tar-baby, FAQ at:
>
> http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
>
> A teergrubing mailserver costs a spammer multiple SMTP
> connections, an inherently finite resource, for possibly hours.
> Workarounds on the part of the spammer are possible, but all
> result in higher costs, reduced delivery, or both. The net
> effect is essentially a delivery payment requirement, though
> the payment is in the form of time and configuration on the
> part of the spammer. Collateral damage is low -- if a
> teergrube _does_ unintentionally filter a legitimate sender,
> the only cost is a single (or very small number of) delayed
> delivery. This and other issues are covered at the FAQ above,
> read it before posing hypothetical problems.
You mention that workarounds are possible, but result in higher costs.
The same is true for TMDA: by requiring spammers to set up a C-R
auto-reply system, they make their mails traceable to their origin. I
don't think spammers can spoof a valid mail address _and_ capture the
replies.
To read a nice pro C-R page, read tmda.sourceforge.net. Check their FAQ,
for example, or read the introduction. In particular, the part about
'Won't senders just refuse to confirm their messages?' is nice, if you
read through to the part about using 'dated' addresses.
David
Reply to: