ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - AMTP (rev 01) - MPC

2003-10-07 09:42:10
At 10:33 AM -0400 2003/10/07, Ken Hirsch wrote:

 Of course you can't absolutely guarantee that a server won't be hijacked,
 but that's no argument for the current system where all IP addresses are
 presumed innocent.  Barring perfection, you can have a system where you do
 have some assurance of trustworthiness.  The very minimum standard should be
 that you know who's responsible for the server.

That's never going to happen. We can't get ISPs to do edge filtering, or bogon filtering. Over 50% of the ccTLD servers are still open public/recursive caching nameservers.

The level of incompetence, and total lack of interest in being competent, is overwhelming.

You can't even really use transactional authentication (which is only good for a single connection), because the root CA is inherently untrustworthy themselves -- VeriSign/NetSOL wants to pimp the entire Internet for their own personal private profit.

 I don't get what point you're trying to make here.  If we have an effective
 system for deterring spam, that's going to reduce the load on the servers.

        If it can be deterred, yes.


I submit that the only effective deterrence can come from providers who find it unprofitable to provide access or bandwidth to spammers, and who enforce the restrictions at the edge. That will happen the same day that we get ISPs around the world to implement edge and bogon filtering in their routers, so that packet spoofing becomes impossible anywhere on the Internet.

Meanwhile, I'm waiting for pigs to fly under their own power and for hell to freeze over.

 Analysis, please.  And define "scalable" please.  I see there's overhead but
 it looks to me that the overhead scales linearly and the work can be
 distributed among servers rather easily.

Scalable means that providers the size of AOL all the way down to one-person shops with less than a dozen customers can implement the same methods, and continue to have a viable business model that allows them to get sleep at night.

Scalable means that you don't have to buy a hundred thousand servers with custom hardware accelerators, just to handle the load this week, and then have to dump them and completely replace them with five hundred thousand servers with the next generation of even faster hardware accelerators, next week.

Scalable means that the worst reasonable case you can project for workload growth doesn't put us into these kinds of situations.

 Also, remind me what scalable solution to spam you are for.  If I recall
 correctly, you're against RMX, challenge-response, as well as PKI
 authentication.  So what solution are you for?  Does it have less overhead
 than authentication?

I'm coming around to the view espoused by Paul Vixie where the real problem isn't the spammers, it's the things that the anti-spammers are willing to do to try to "solve" the problem.

        As bad as the disease is, many of the proposed cures seem to be worse.

 If it turns out that some countries decide to become spam havens, then there
 are means for controlling that.

I doubt it. They're already using hijacked PCs today. Why not continue to use hijacked PCs with their SETI(_at_)Home-style distributed CPU power to continue to pose as legitimate systems?

                                  Systems that require cash up front (e.g.
 www.bondedsender.org) do not require cooperation of the authorities in
 another country to enforce agreements nor particularly strong identity
 requirements.  And there are other ways.

        I have yet to see any.

--
Brad Knowles, <brad(_dot_)knowles(_at_)skynet(_dot_)be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
    -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg