At 4:17 PM +0000 6/22/08, Paul Vixie wrote:

with EC2, it's game-over for the IP reputation industry, other than possibly lists of dynamic IP blocks (modems, DSL, etc) from which SMTP ought not come. but for the wider IP address space, we now return to content based filtering, and i predict a mighty increase in the number of pink contracts in colo rooms. (the silver lining is, this could reduce pressure on BGP piracy/injection.)

as randy bush often says, "it's just business." amazon has solid business reasons for creating EC2 and there's no way it could be profitable if they can't scale the user base, and there's no way to scale the user base if they have to police it at the application or "intent" level. so, i'm not whining, just pointing out that this is a sea change, the end of an era.

I agree that it's going to be difficult to deal with this on an IP reputation basis (at least using IPv4 :-), but not certain that means that a total lack of policing will stand long-term. The litmus test will likely be subsequent to the first large scale P2P service appearing in the EC2 cloud and distributing quantities of copyright material... /John

hi andy.

...

with EC2, it's game-over for the IP reputation industry,

I was discussing this on an e-commerce practitioners list earlier today, and argued basically that, from an abuse point of view, EC2 is the same as any other bad neighborhood, and that operators needing to make impact fast, will treat it as they do any other bad neighborhood.

i wish i agreed. a bad neighborhood that's mostly access customers or mostly small businesses can be dealt with by address. but if it's mostly services and most of those are things your own customers want to reach and many of those are large, then the leverage is on the wrong end of the stick. if we lived in an ipv6 world, such that every EC2/GAE customer had its own dedicated IP address, not to be reused within a five year span, then blocking by IP address would remain practical, even though blocking by IP prefix or ASN is still ruled out. but in an ipv4 world where IP addresses are too precious to dedicate or retire on a per-customer basis, i don't see any large eyeball network subscribing to any IP reputation service who lists any part of EC2's address space. the problem with this model change is deeper than "we'll all get more spam". in http://www.vix.com/personalcolo/ i wrote that: If you're an Internet user in a bad neighborhood -- as evidenced by your mail not getting through to a lot of people, who then tell you that they're blocking all mail from your ISP since there's effectively no abuse desk -- but you're unable/uninterested in operating your own secure computer in some remote facility, then you'll need to locate a provider who can offer you a suite of services like e-mail and web hosting, who does not also offer those services to spammers and script kiddies. ... It's worth pointing out that a "better neighborhood" might also have as its customers people whose content is objectionable to you, for example, it might also host a lot of web sites offering politics, or pornography, or alternative lifestyles, or alternative energy, or who knows what-all. Don't worry about this. Some of the neighborhoods on the Internet whose reputations are strongest, are the ones with the most diverse customer bases. The point is, don't let your local cable or DSL spam-haven offer you an e-mail account, or web publishing services, or anything else that they can't afford to support. As a rule of thumb, $40 per month is not enough money to pay for an abuse desk; and without a strong, well trained abuse desk, the neighborhood will be "bad". among the distinctions being blurred by the EC2/GAE model, there is no longer going to be a competitive advantage for companies with fully funded abuse desks. if i'm right AOL/COX/Comcast cannot afford to blackhole EC2/GAE or to subscribe to any IP reputation service who blackholes EC2/GAE, then the level of inbound abuse these networks will treat as inevitable is going to rise to the point where the effective difference between the IP reputation of an ISP who signs pink contracts and/or has no abuse desk vs. an ISP who keeps out the bad guys and fully funds their abuse desk will be approximately Nil. without the ability to differentiate on this basis, a new lowest common denominator will be found as "good" ISPs are driven out of the margin by "bad" ISP's. jcurran's point that amazon may be forced to police itself if it becomes home to P2P networks hosting DMCA-taggable content is interesting. this could mean that amazon will have to re-price EC2 to include some policing costs, just to protect its executives and shareholders. the devil will be in the details -- if this is the path we all go down together, then amazon will still have to control its costs, and that'll mean picking the smallest possible list of things they'll police, and i don't think SSH port knocking or botnet C&C or open proxies will make *that* list, because they can manage those underlying risks at lower cost on the back end than on the front end. so in addition to ending an era, EC2/GAE/similar are beginning a new one in which the debate about the definition of acceptable use becomes multilateral rather than just a series of bilateral or unilateral agreements and actions. that is the other "silver lining" in all this. if distributed computing is a necessary utility then it may become a public utility and so EC2/GAE could spawn an "internet public utilities commission" at the state or federal level. and while i wouldn't like to see FCC-style "morality policing" of content, i think that if big companies are going to create public nuisances for what are perfectly valid business reasons, they should either pre-regulate or expect to be post-regulated. paul

on Sun, Jun 22, 2008 at 01:24:43PM -0500, Al Iverson wrote:

I'm not going to pretend I manage inbound mail service for thousands-to-millions of users (as most of the participants of other lists like SPAM-L are fond of imagining themselves), but I know enough about how IP reputation systems work at ISPs to know that if I did manage inbound mail for such a userbase, the EC2 IPs would be blocked repeatedly and often, and there would come a point where the blocks escalate to /24s and larger, and there would come a point where the blocks are removed slower and less often.

I don't pretend to manage inbound mail service for more than dozens, but I do provide a service via enemieslist that is indirectly used by millions, and out of the over 32K rDNS naming conventions I've catalogued and classified, in terms of their dynamicity/staticity/etc., only four are related to Amazon/EC2. Now, if the entire 'Net moved to a cloud computing model, I could agree with Paul that this would be the end of IP reputation. But I'm only aware of two such services (Amazon EC2 and Media Temple's gridserver.com) in widespread use, so I haven't bothered to come up with a new classification for them, and treat them as essentially dynamic (with gridserver.com also classified as 'webhost'). I moved away from the strictly IP-based reputation model several years ago (though I still use DNSBLs as a practical tool), and instead treat classes of IPs as a set about which certain reputation-ish qualities can be asserted, which works very well in a scoring-style context. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/

Valdis.Kletnieks@vt.edu writes:

One could argue that the "botnets for rent" business model is in more widespread use than either EC2 or gridserver...

I'm unclear whether that statement needs a smiley or not...

i'd say that since EC2 won't be shut down when it's found out about, that you need a smiley. "widespread use" is too narrow a term. none of us expects white-hat e-commerce business to move into rented botnets, and rented botnets aren't all going to be in the same address space or ASN. -- Paul Vixie

IMHO, Amazon will eventually be forced to bifurcate their EC2 IP space into a section that is for "newbies" and a section for established customers. The newbie space will be widely black-listed, but will also have a lower rate of abuse complaint enforcement.

The only scalable way to deal with a system like EC2 is to provide clear demarcations of where the crap is likely to originate from.

Or, more likely, two separate companies will tackle the problem... Ala Ironport or similar. Some clusters will provide a high degree of trust and certainty of the activities of its customers, and some won't. There is no reason to believe one company will do both equally well. Deepak Jain AiNET

On Sun, Jun 22, 2008 at 12:55 PM, Andy Davidson <andy@nosignal.org> wrote:

On 22 Jun 2008, at 17:17, Paul Vixie wrote:

...

with EC2, it's game-over for the IP reputation industry,

I was discussing this on an e-commerce practitioners list earlier today, and argued basically that, from an abuse point of view, EC2 is the same as any other bad neighborhood, and that operators needing to make impact fast, will treat it as they do any other bad neighborhood.

Concur. From an address-reputation perspective EC2 is no different than, say, China. Connections from China start life much closer to my filtering threshold that connections from Europe because a far lower percentage of the connections from China are legitimate. EC2 will get the same treatment. As that starts to impact Amazon's ability to maintain and grow the service, they'll do something about it. Or let it wither. Either way, address reputation solves my problem. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

Just because something doesn't solve all your problems doesn't mean it has no value. Anything that can reduce the amount of inspection you have to do @ content, and filters out the gross cruft, buys you additional network and systems capacity, using what you have now (firewall, mail relay). This is a good thing in a real-world network, and goes straight to the bottom line in reduced opex and capex. The process of detecting and blocking bad actors, for networks that have to allow access to/from anywhere, is better than doing nothing. Marcus also likes to light hay bales on fire. Methinks for the same reason he makes inflammatory statements: It gets people talking and thinking, which is a good thing.

-----Original Message----- From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Monday, June 23, 2008 9:55 AM To: William Herrin Cc: Paul Vixie; nanog@merit.edu Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re:Intrustion attempts from Amazon EC2 IPs)

On Mon, 23 Jun 2008 11:38:16 EDT, William Herrin said:

...

Concur. From an address-reputation perspective EC2 is no different than, say, China. Connections from China start life much closer to my filtering threshold that connections from Europe because a far lower percentage of the connections from China are legitimate. EC2 will get the same treatment. As that starts to impact Amazon's ability to maintain and grow the service, they'll do something about it. Or let it wither. Either way, address reputation solves my problem.

No, it only solves your problem *if* you can compute a trustable reputation for each address. For instance, "connections from China" loses if another /12 shows up in the routing table and isn't correctly tagged as "China". And this fails the other way too - I remember a *lot* of providers were blocking a /8 or so because it was "China", and didn't know that a chunk of that /8 was in fact Australia. Similarly, you lose if EC2 deploys another /16 and you don't pick up on it.

There's a *reason* that Marcus Ranum listed "Trying to enumerate badness" as one of the 6 stupidest ideas in computer security....

From: Troy Davis <troy@yort.com> ... AWS already tracks VM instances and their internal IP allocations. They recently added "elastic IPs," which are assigned to a customer rather than a specific instance. To the rest of the world, they're static IPs.

abusers don't have specific identities. they will find out the minimum level of identity-checking they have to spoof, and spoof that. stolen credit cards, throwaway domains, free e-mail accounts, and so on. before they get disco'd they already have their next instance set up and ready to go. the game is to live in the time margin of the ISP's reaction time, so that each fake identity gets a predictable amount of time and resources before it's stopped/abandoned. this is why during my time running MAPS, i focused on fully funded abuse desks with the power to suspend or disconnect in real time, 24x7, pending management review. warning policies or management approval increased the guaranteed minimum useful lifetime of a fake hosting customer identity to the point where there was no benefit in sending that ISP complaints at all. some ISPs went to extreme lengths to tie fake identities together so as to increase the up-front costs of serial abusers, but this inevitably raised their overall costs and also their acquisition costs for non-abusive customers, and the only thing that kept those increased costs from making these ISPs noncompetitive was that their reputation would be better, and a better reputation had an offsetting benefit. given that an static IP's reputation has inertia, and it takes days or weeks or sometimes years for a "bad IP" to get its reputation cleaned up enough for it to be reused, there's a window here where the pool of IP's EC2 can churn through if it assigned them statically to potentially abusive customers may not be large enough to also accomodate the new non-abusive load during the period they want that churn-pool to cover. and they'll have clean-up costs in resetting the reputation of previously abused IP's, with a natural tendancy of IP reputation services to think that amazon, as a large company, is doing the absolute minimum work nec'y to prevent serial abuse, such that inertia for EC2 addresses is likely to be effectively higher than for non-EC2 addresses.

... Anyway, Amazon and Google are motivated and innovative, so I wouldn't write it off.

Troy

amazon and google are also large and profitable, and they know how to manage their risks and costs to the maximum benefit of their shareholders and their customers. this is a variation on "good, fast, or cheap: choose two". for something like EC2 to be a financial success, it has to scale, and the trade- offs that make scale possible also create dark corners and loopholes in which abusers can thrive. reputation systems have generally not scaled well, but they'll still be possible, based on content, domain name, digital signatures, webs of trust, that kind of thing. just not IP addresses like in the old days. paul

Jim Popovitch wrote:

there is no inverse-RBLs and MTAs that work straight forward with them.

from my exim config # Reject messages from senders listed in these DNSBLs # except for dnswl whitelust drop condition = ${if isip4{$sender_host_address}} message = blocked because $sender_host_address is \ in blacklist at $dnslist_domain: $dnslist_text !dnslists = list.dnswl.org dnslists = dialups.mail-abuse.org \ : rbl-plus.mail-abuse.org \ : qil.mail-abuse.com logwrite = REJECT because $sender_host_address listed in $dnslist_domain note list.dnswl.org randy

scg@gibbard.org (Steve Gibbard) writes:

... So yeah, if big shared services that include important stuff aren't being adequately policed, that's probably a problem for IP address reputation services. But that's not really a new problem being introduced by EC2.

this may be an argument that the process i speak of has already begun, or it may dovetail with my observation, since i know that some big ISP's have been in blackhole wars with some big freemail providers already, whereas i do not expect any blackhole wars involving EC2 or similar. it's one thing to reject connections from some segment of the eyeball population on the basis that "more ought to be done to keep abuse from coming from there" but quite another thing to reject connection from a global e-commerce network just because some shared IP's are sometimes used abusively. the interpretive choice between "IP repututation systems were already doomed" and "IP reputation services are now doomed" does not puzzle me overmuch. -- Paul Vixie

On Jun 22, 2008, at 11:17 PM, Paul Vixie wrote:

so, i'm not whining, just pointing out that this is a sea change, the end of an era.

And it's even more significant in that large enterprise customers and others will have explicitly *whitelisted* the IP blocks associated with these services. While static IPs are available for EC2 and for the other services, as you point out, it can't last in an IPv4 world. Later on, as the technologies mature and standards emerge, we'll see automagic arbitraging of jobs/loads/tasks between clouds, so things will be even more diffuse in terms of pinpointing the actual sources of undesirable traffic or other antisocial behavior (e.g., a spam engine may be resident in one cloud and making use of network resources/proxies in another cloud, that kind of thing; 'botnets in the sky', as it were). This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place. I foresee interesting times ahead. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb

When I hear "cloud services" I think "in the network" even though it appears all these cloud services perform their work at a data center as an outsourced service. Is there a vendor that makes a product that perform spam/malware filtering literally in the network, i.e. as a service provider, can I provide spam filtering for the enterprises in my customer base by adding a piece of network gear? I'm not aware of one today except those who provide enterprise-oriented gateways like SonicWall. Frank -----Original Message----- From: Roland Dobbins [mailto:rdobbins@cisco.com] Sent: Sunday, June 22, 2008 9:20 PM To: nanog@merit.edu Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs) <snip> This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place. I foresee interesting times ahead. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +66.83.266.6344 mobile History is a great teacher, but it also lies with impunity. -- John Robb

Barracuda, or you could build the exact same thing using OSS. Procmail, Spamassasin, ClamAV, and your choice of RBLs (or use karmashpere to custom roll a hybrid one).

-----Original Message----- From: Suresh Ramasubramanian [mailto:ops.lists@gmail.com] Sent: Monday, June 23, 2008 7:16 AM To: frnkblk@iname.com Cc: nanog@merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip addressreputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

...

Is there a vendor that makes a product that perform spam/malware filtering literally in the network, i.e. as a service

On Mon, Jun 23, 2008 at 6:01 PM, Frank Bulk - iNAME <frnkblk@iname.com> wrote: provider, can I

...

provide spam filtering for the enterprises in my customer base by adding a piece of network gear? I'm not aware of one today except those who provide enterprise-oriented gateways like SonicWall.

Symantec Mail Security / Turntide Mailchannels Traffic Control

--srs

-- Suresh Ramasubramanian (ops.lists@gmail.com)

On Tue, Jun 24, 2008, Suresh Ramasubramanian wrote:

Hate to point out the obvious, but ... That isnt "network gear" as such.

It is an appliance that'll require repointing of MX records

Please don't tell my test kit at home; Cisco WCCPv2 redirects TCP/25 as easy as it does TCP/80(*1). No MX rejiggery required. Adrian *1: unless you're the lucky owner of specially crafted gems like the Catalyst 3550 - WCCPv2 is limited to port 80 only ..

Frank Bulk - iNAME wrote:

When I hear "cloud services" I think "in the network" even though it appears all these cloud services perform their work at a data center as an outsourced service.

Is there a vendor that makes a product that perform spam/malware filtering literally in the network, i.e. as a service provider, can I provide spam filtering for the enterprises in my customer base by adding a piece of network gear? I'm not aware of one today except those who provide enterprise-oriented gateways like SonicWall.

dpi boxes from a number of vendors can do that sort of thing... whether they can do it fast enough to be inline with your compute cloud is another question entirely. That said the result is fairly perilous when rejecting a message involves forging packets. and of course tls supporting mta's will be opaque to the network traffic inspecting device.

Frank

-----Original Message----- From: Roland Dobbins [mailto:rdobbins@cisco.com] Sent: Sunday, June 22, 2008 9:20 PM To: nanog@merit.edu Subject: Re: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)

<snip>

This is far different from free email Google or Hotmail - these cloud services (EC2, Mosso, Slicehost, Terremark's Enterprise Cloud, Telstra's new service, AppEngine, et.al.) are where many popular new Internet applications will live, and, even more significantly, where an increasing amount large-scale enterprise computing (like banking, pharma, government, and so forth) will take place.

I foresee interesting times ahead.

----------------------------------------------------------------------- Roland Dobbins <rdobbins@cisco.com> // +66.83.266.6344 mobile

History is a great teacher, but it also lies with impunity.

-- John Robb

Frank Bulk wrote:

Thanks. Even with TLS, the destination port (either 25 or 365) is well-known, right, as is the source IP?

And 587 though that's generally your customers, who are going authenticate.

At the minimum RBLs could be used for that encrypted traffic.

Yeah, given that that point you're basically filtering by ip again, you can do that with a bgp community. That's not really smtp filtering anymore.

Frank

-----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Monday, June 23, 2008 2:20 PM To: frnkblk@iname.com Cc: nanog@merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

<snip>

dpi boxes from a number of vendors can do that sort of thing... whether they can do it fast enough to be inline with your compute cloud is another question entirely.

That said the result is fairly perilous when rejecting a message involves forging packets. and of course tls supporting mta's will be opaque to the network traffic inspecting device.

Frank Bulk - iNAME wrote:

Right, port 587 would require SMTP authentication.

I'm no routing expert, but can tens of thousands of /32s be excluded using BGP communities?

The sort of depends on how many fib entries you want to burn on not forwarding traffic... the argument in this thread however (which I more or less subcribe to) is that in the future an ip address is insufficient granularity for mail /badness filtering. Frankly it's not just computer clouds but also address pressure, a million hosts behind a /24 are going to be rather hard to pick out one at a time. ultimately the ability blackhole based on something as gross as the source ip address is going to be insufficiently fine grained for devices that must accept connections from the internet at large.

I don't know if spammers are going to be using TLS in a big way soon, though I'll admit I've not measured.

A couple years ago, when my former employer turned on tls support on the outwardly facing mta's about 10% of our incoming smtp connections immediately started using it after ehlo. That's not something I've kept track of but I imagine it's an issue.

As long TLS usage is low, examining TCP port 25 traffic would likely be effective without redirecting SMTP traffic and making it effective for all customers downstream.

Frank

-----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Monday, June 23, 2008 4:06 PM To: frnkblk@iname.com Cc: nanog@merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

Frank Bulk wrote:

...

Thanks. Even with TLS, the destination port (either 25 or 365) is well-known, right, as is the source IP?

And 587 though that's generally your customers, who are going authenticate.

...

At the minimum RBLs could be used for that encrypted traffic.

Yeah, given that that point you're basically filtering by ip again, you can do that with a bgp community. That's not really smtp filtering anymore.

...

Frank

-----Original Message----- From: Joel Jaeggli [mailto:joelja@bogus.com] Sent: Monday, June 23, 2008 2:20 PM To: frnkblk@iname.com Cc: nanog@merit.edu Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)]

<snip>

dpi boxes from a number of vendors can do that sort of thing... whether they can do it fast enough to be inline with your compute cloud is another question entirely.

That said the result is fairly perilous when rejecting a message involves forging packets. and of course tls supporting mta's will be opaque to the network traffic inspecting device.

On 6/23/08, Nathan Ward <nanog@daork.net> wrote:

Do 'normal' web hosting providers allow customer created scripts to create TCP sessions out to arbitrary things?

Doesn't PHP provide a fair amount of TCP functionality that can be used simply by uploading the code you need to your shared web hosting account? -brandon

On 23/06/2008, at 6:14 PM, Stephen Satchell wrote:

PHP, Perl, Python all provide the ability to generate Socket connections via TCP and UDP. At the Web hosting company I used to work at, they ran a "mostly open" policy when it came to outbound connections. This was particularly true of co-located-equipment and leased-equipment customers, much more so than the shared-equipment accounts.

When I monitored traffic, I found that the most common port for outgoing TCP connections was on port 80. Investigation of TCP port-22 outbound traffic showed that most of that traffic was SCP and tunneled RSYNC traffic to single locations.

We found our share of bad apples, such as the the guy who set up a tunnel between a leased server and his location in Texas, for the purpose of running a spammer Web site with the payload coming to the Web host's IP addresses instead of the spammer operators' addresses.

Of more interest to me, though, was the monitoring of traffic on our currently unallocated IP addresses; *lots* of woodpeckering on a wide variety of ports. The reason I originally set up a server that would accept packets from all currently-unused IP addresses was to minimize the ARP flooding that occurred when someone would hammer on an IP address that wasn't in use. Once that was in place, it was a trivial matter to monitor abusive traffic and add to the local access control list as necessary when requests to the network operators of the source of abusive traffic would not take steps to remove the people who were not RFC 1855-compliant.

The default server's logs proved to be an excellent way for us to detect compromised on-site dedicated servers, particularly those servers infected with mal-ware designed to "probe the immediate neighborhood" first.

Yep, darknets are a common way to detect that sort of thing, there's quite a few papers on them. I'd be pretty worried if my colo provider was limiting what I could do - but it seems silly to let your average web hosting customer (i.e. $10/mo php+mysql service) open outgoing TCP sessions to ports other than 80 and 443. I'm sure there are exceptions to the rule, and they should be exactly that - exceptions. -- Nathan Ward

eliot wrote:

Let's go back to the case and point: Amazon is claimed not to behave as a good Netizen.[*] In these circumstances we have to ask why the traditional system doesn't work. This is precisely the case when you want to ding someone's reputation. Your argument that many good applications will be running to counterbalance the bad depends on whether those running the good applications will tolerate intermittent outages because the bad applications cause the sites to get blacklisted.

my argument doesn't get that far, actually. i think there will be no outages because recipients of abuse won't feel that they can afford to toss out the good with the bad in this particular case. which is going to remind of me tom lehrer's quip, "feels like a christian scientist with appendicitis" once an EC2 customer instance gets infected with malware that then ddos's somebody.

But there's also the possibility for web reputation services to improve granularity above and beyond the IP address, but this depends on quite a number of things, such as whether SSL is used and where and how information is collected by the services.[***]

i suppose i have been too prolific here of late, since i predicted exactly that, but it's no doubt buried in some response of mine that you did not read.

And so the question boils down to this: will Amazon and its ilk adapt to the current reputation services model or will it be the other way around? I think it will be both, but more the former than the latter.

i think it will be both, and more the latter than the former. i'm basing this prediction on leverage, risks, and costs. if amazon and google and anyone else who provides large scale virtualization (where "large scale" means there is no in-person meeting to kick off the relationship, no credit check on the customer, and so on) knows that their good customers are so valuable to the rest of the world that some number of bad customers mixed in will not matter, then their rational decision will be to discover the break point and enforce that much and no more. this is how big companies get big and stay big; it's what ISP's have always done wrt their abuse desks; it's the break point i sought to move with MAPS; and the basis for that break point is in a totally different place for (server-side large-scale no-fixed-ip). paul

On Mon, Jun 23, 2008 at 7:20 PM, Patrick Giagnocavo <patrick@zill.net> wrote:

What I think would/should happen is that EC2 is never assumed to be a legitimate source of email; and any EC2 instance that sends email will instead be relaying through a non-EC2 mail server.

Mail / spam seems to be the least of ec2's problems though. This thread started off with ssh port probes. srs -- Suresh Ramasubramanian (ops.lists@gmail.com)

...

with EC2, it's game-over for the IP reputation industry

Realistically speaking, did you not expect that to be inevitable?

i didn't, no. when i unknowingly launched the IP reputation industry back in the mid 1990's, the risk i was managing was a spammer who planned to give away free T1 lines to anyone who would run a spam relay for them. everything in those days was fixed ip on wire lines. when the game changed to open relay and open proxy and then malware-botnets, i saw a great deal of pressure on the model since a given IP address could represent different endpoints at various times of the day, and each endpoint could be cleaned and reinfected many times in a month, but with short TTLs on the DNS RBL, it was still possible to keep the pressure on the infected endpoints and their ISPs, since they bore the greatest cost of their own misbehaviour, and reputation-entropy was a cheap component of the overall error rate. so, no.

As access to the internet increases, the chances of SMTP scaling to prevent spam decreases. And as IP's become more numerous and 'chuckable' (so much more so with IPv6 around the corner), the idea of a blacklist becomes ever more useless.

yes, but that was a shallow curve, whereas EC2/GAE/etc is a steep curve.

What we need is a new mail protocol.. [But people have been saying that for decades now]

several excellent, scalable replacements for smtp have been patented. all we have to do is globally agree to enrich those patent holders and our problems will be solved.