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...
pgpFXfFh9yGI0.pgp
Description: PGP signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf