Re: Challenge-response mail filters considered harmful
> From dfokkema@ileos.nl Sun Aug 3 12:04:08 2003
>
>
> 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....
Any decent CR program auto-matically passlists anyone that they send a
message to.
> >
> > 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.
>
That's silly. The spammer would have to have your passlist.
Besides that, you can test the Received: headers if need be, or even include
a one-time password with each transaction if it comes down to it.
Formail will generate unique message IDs with a simple argument...
> 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.
>
Never seen it happen. If you are passlisting a domain, then you test the
Received: headers for the path, too. Same for any high-profile address.
> >
> >
> > 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.
Right. A properly designed CR requires the recipient of the CR to hit Reply
and paste a string on the subject line. ONCE. Only one time EVER.
I suppose that when you go to the bank and they demand to see your ID for
the thousandth time, that you rant and rave about the inconvenience.
Withe CR it is the same amount of effort ONCE.
>
> 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.
> >
CR programs ARE receiver-side passlists. It is the CORE of the system!
> > 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...
> >
Do your HOMEWORK, Karsten. Any decent CR program automatically passlists
anyone you send a mail to.
> > 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.
>
>
<snip>
The above gibberish contributed by Karsten is typical of the reaction that
spammers give when asked what they think of CR programs.
And it would make any slimy politician or sleazeball lawyer proud.
Here's the basic dilemma:
Most people want to be able to send anonymous mail to others,, but don't want
others to be able to send it to them.
That's why there alleged 'spamfighting' programs never work. The spammers
just search for the loopholes that they KNOW exist because of the
essential hypocrisy of the alleged 'spamfighters'.
*I* don't get any spam. Why do YOU?
But then, a CR doesn't bother ME a bit. Been encountering a lot of them
lately.
Don't complain when I have to log in to a website either, which is more of
a hassle than answering a CR, and I have to do it over and over and over.,,,
Alan
--
For Linux/Bash users: Eliminate spam with the Mailbox-Sentry-Program.
See: http://tinyurl.com/inpd for the scripts and docs.
Reply to: