on Thu, Jul 31, 2003 at 04:57:30PM -0700, Alan Connor (alanconnor@earthlink.net) wrote:
> > From aaron@core-dev.com Thu Jul 31 16:34:18 2003
> Spam is UCE (unsolicited commercial email) and stopping it can only be done
> with a Challenge-Response mail program, such as the one I put together.
> There isn't ANY other approach that works.
Bullshit.
> What people mean when they say they are fed up with spam, is that they
> are fed up with SOME spam, but want to get the others.
>
> There simply is no way that a "negative" approach will work. The
> "don't pass" list is infinite and its characteristics are
> ever-changing.
A whitelisting plus filtering system is highly effective.
> So they end up spending good money on programs that kill things they
> would like to see, and don't kill things they find objectionable,
> because these programs are obsolete a week after they are released.
>
> To stop spam you have to decide who you WANT to hear from, and dump
> EVERYTHING else.
>
> You cannot accept any mail that doesn't have a valid return address.
Thanks, I feel differently.
By your own rule, alanconnor@localhost is an illegal, invalid return
address. It's the address provided by your C-R system, incidentally.
The goal of spam filtering is _not_ to block 100% of all spam. It is
twofold:
- To block a _sufficient_ portion of spam to be useful. The negative
cost of a single spam message is low, it is the aggregate cost which
is high.
- To pass as many non-spam messages as possible, given the first
objective. The cost of missing legitimate mail is high.
> > I can't say any of those have landed in my inbox, though ;-) Straight
> > to ~/mail/spam with no stops in between.
> >
>
> See? You aren't blocking spam, you are saving mail that MIGHT be spam
> to a directory and then reading through it.
Speaking for myself: the mail is eyeballed for any obvious
mis-filterings. It's archived (for training, for wupses), mostly
because I perfer to keep stuff until it's clearly not needed. I've,
incidentally, run into problems based on auto-whitelist rules tagging a
sender's address as spam when it was spoofed in several spam mails
received. The fourth (legitimate) mail was also spam-filtered. My
report was among those which reduced the negative penalty AWL feature of
spamassassin.
> Why? Because SpamAssasin doesn't work, and will never work.
A second time: bullshit. My own experience is 98%+ true postive, 2%-
false negative, 0.02% false positive, 99.98% true positive, used in
conjunction with a recipient-side whitelist.
> If any mail comes to me from an email address or domain that isn't on my
> pass list, it goes to /dev/null and an auto-response is sent to whatever
> return address the sender supplied.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
> I don't get ANY spam. It ALL goes straight to /dev/null. If anyone
> wants me to read their mail, then they MUST give me their real email
> address.
Amusing. See 'localhost' comment above.
Peace.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Verio webhosting? Guaranteed downtime:
http://www.wired.com/news/politics/0,1283,57011,00.html
http://www.dowethics.com/r/environment/freedom.html
Attachment:
pgp1BE77nT3Q1.pgp
Description: PGP signature