RE: A new technique to anti spam

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]