-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
Sent: Thursday, October 28, 2004 1:14 PM
To: test
Cc: spamtrap(_dot_)ietf(_at_)dja(_dot_)mailme(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: Re: A new technique to anti spam
On Wed, 27 Oct 2004 11:52:26 +0800, =?gb2312?B?dGVzdA==?= said:
3.The authority database guarantee all \"Email-content
servers\" are related with legal ESPs.
This is somewhere between "highly unlikely" and "totally unworkable".
Problems:
1) Who controls the authority database? Why should I trust
them any more than I trusted Verisign even *before* the
'wildcard *.com' incident? (of course, long-time IETF readers
know that I'm paranoid, and by default don't trust *any*
governments or corporations, not even my own. ;)
2) There are some 75 *million* .com domains. There's
probably dozens of registrars. How do you ensure that *NO*
employees of any of those dozens of companies are bribed?
3) If the spammer's current ISP is willing to "pink contract"
their network access and DNS services *now*, why will that
same ISP *not* be willing to pink-contract a registration in
your database? (Hint - the ISP won't change their business
model unless there's an *additional* threat of other sites
not talking to them - and most of the problem ISP's are
*ALREADY* in enough blacklists that there really isn't any
*realistic* chance that they will be shunned more than they are now.
The spammer can create a lot of spam-pointer point to ONE
email which is on a legal server.
How to prevent it?
The legal \"Email-content servers\" provides \"retr\" and
\"top\" command to let users download the content.
\"retr\" can only be used once.
\"top\" can be used more than once.
\"retr\" is more popular than \"top\".
So only the first receiver can download the junk-mail from
the legal server through the spam-pointer,and the second
receiver can\'t download it if he use \"retr\" command.
Do you *seriously* think it will take more than 15 seconds
for the spammer to modify the software so that 'retr' and
'top' work the same, and both can be used multiple times?
Remember - the spammer controls the server you're fetching it
from, and has *very* good reasons to give the first copy to
the first recipient, and then lie to the next several million
and tell them that *they* are the first recipient.....
D)It\'s difficult to confirm the qualification of
\"Email-content servers\".
But I think CA can works,it can works too.
Matt Blaze had an interesting statement about the role of a
CA in security:
"A CA is able to protect you against anybody they aren't
accepting money from".
Think about that, and remember that in the *real* world, not
100% of the companies in *any* business are honest - and in
this case, it only takes 1% or 2% of dishonest CA's to ruin
the scheme.
Or - what if the largest CA started selling certs to
spammers? What could you *realistically* do? Take them out
of your list of root CA's? That would cut you off from a
large fraction of people who have certs signed by that CA.
It's the same "they *have* you where they *want* you" that
makes a merchant accept a Mastercard or Visa - it's the rare
merchant indeed that can afford to lose the business by
saying "I don't take Visa because they sometimes issue cards
to crooks"....
(And yes, yours is *NOT* a new idea, at all, and the previous
several hundred people who came up with it didn't do any
better at finding solutions to the problems. In fact, we
hear so many of the same "new" ideas over and over that Vern
wrote this page:
http://www.rhyolite.com/anti-spam/you-might-be.html
Please don't be insulted - it really *is* the best one-page
summary of all the previously suggested-and-didn't-work ideas
we've heard already.
Also, note that the fact that we still *have* a spam problem
is proof that none of us "experts" in the IETF can think of
an idea that doesn't break under at least one of those
points, *either*. And yes, the best experts in the IETF
*do* believe that a "final" solution to spam *will* have to
survive *all* those points. (Existence proof - if a workable
solution existed even though it failed one of Vern's points,
we'd have deployed it anyhow...)
Personally, I think you're better off *not* trying to come up
with one scheme that addresses it all, but come up with
several interlocking methods that each address one part of
the problem. For instance, *by itself*, the only thing that
Meng Wong's SPF and Microsoft's Caller-ID and Yahoo's
Domain-Keys proposals do for spam is provide information
regarding whether the mail is from an "authorized source",
which does almost nothing about spam *directly*.
However, if you approach it as "If we deploy one of those,
then we can do <some other thing> about spam which isn't from
an authorized source". My own feeling is that if
SPF/Caller-ID/Domain-Keys is widely spread, the only real
effect will be to force the spammers to use zombie software
that routes to the zombie owner's ISP mail server so the
victim's mail servers will accept the mail as being from the
ISP's "authorized" mail server, rather than directly to the
targets as the software usually does now....
Of course, at *THAT* point, the ISP will have more of a
reason to *do* something about the zombie, because now it's
filling up the ISP's mail spool with the outbound spam that
was previously sent directly to the victims...