I think this discussion shoulg probably move to the Anti Spam Research Group list No? asrg@xxxxxxxx -Tom thomasgal@xxxxxxxxxxxx > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Valdis.Kletnieks@xxxxxx > Sent: Thursday, October 28, 2004 1:14 PM > To: test > Cc: spamtrap.ietf@xxxxxxxxxxxxxx; ietf@xxxxxxxx > 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... > > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf