Date: Mon, 23 Jun 2008 20:47:17 -0700 From: Joel Jaeggli <joelja@bogus.com> Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip address reputation industry? (Re: Intrustion attempts from Amazon EC2 IPs)] To: frnkblk@iname.com Cc: nanog@merit.edu Message-ID: <48606E45.8000100@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.
Ummm, probably not as big of a problem as you might think it is. From the point of view of an email administrator, those million hosts behind the /24 are all going to be on the Spamhaus PBL (policy block list) and it doesn't matter whether there are 10 or 10,000 or 10,000,000 hosts if the ISP has said "these are residential subscribers and they shouldn't be sending mail." Whether you believe in PBL or not, generally, it's going to be end users who are clustered behind those NATs more so than MTAs. Similarly, I don't see a huge incentive for someone to move their MTA to services like EC2--although anti-spam services 'in the cloud' like Postini are very popular, but that's a different issue. In our month-by-month anti-spam testing over the past 3 years, the number of unique email senders (MTAs, not individuals mind you) has actually dropped a bit; if you use the domain name as exposed in HELO/EHLO, it's dropped even more. While there will always be small MTAs out there handling small numbers of people, the trend has been to throttle that mail through larger systems. Sometimes this is done transparently/semi-transparently by the ISP ("you will send your mail through our SMTP server") using either a simple port 25 block or something like transparent destination NAT/WCCP. In other cases, this happens because small companies are discovering that their oh-so-exciting Exchange server is more of a pain in the ass than using commercial Gmail or whatever. SMTP is a special case in this discussion, I'll immediately admit. The number of hosts offering up web pages (assuming you want to filter for malware of some sort) is going nothing but up. Reputation services will be more challenged in that environment than in the SMTP environment.
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.
Today's number for delivery using SSL by our mail cluster is 7% of just shy of 80K messages. Goes up, goes down, but definitely non-zero.
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.
That actually turns out to be a non-problem from the SMTP point of view. A "mean" ISP could simply intercept the response to EHLO and drop out the TLS capability string. A "nice" ISP could simply make up a certificate on the fly. Since SMTP senders don't have a GUI box to click during the SMTP transaction when a certificate doesn't check out, most (read as: all configured with default settings) of them simply send anyway even if the certificate smells like week-old fish. Put it another way: I ran (accidentally) for two years with an expired certificate on one of our mail servers and didn't get a single peep about misbehaving mail. But most of this discussion has been about reputation services, and of course those operate beautifully with or without TLS in the SMTP case. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms@Opus1.COM http://www.opus1.com/jms