Date: Mon, 23 Jun 2008 20:47:17 -0700
From: Joel Jaeggli <[EMAIL PROTECTED]>
Subject: Re: Cloud service [was: RE: EC2 and GAE means end of ip
address reputation industry? (Re: Intrustion attempts from Amazon
EC2
IPs)]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] http://www.opus1.com/jms
