The problem is not as much actual open relays (which are now rare and almost universlly blocked) but open proxies

We have come up with some terms to clarify types of open proxies: *Naturally occurring* open proxy/relay: System on which the owner has intentionally installed a mail or proxy server but has left it mis-configured such that anyone can relay through it. *Synthetic* open proxy/relay: System on which miscreant has dropped (through virus, worm, infected download, etc.) a mail or proxy server on owners system, thus enabling open relaying. By open, I mean *anyone* who discovers the ports the proxy is listening on can utilize it. *Synthetic* protected proxy/relay: Same as above, but proxy contains some sort of authentication mechanism limiting who can use the proxy...e.g. JUST the spammers....this obviously defeats open proxy testing. Others also refer to Synthetic proxies as "hijacked proxies" or "ProxyBots". Some other comments on this approach: First, I definitely agree that current RBL approaches to spam are not very effective due to the dynamic nature of Synthetic open proxies. Though I can't prove it, I suspect that as much as 90% of current spam is transmitted through such proxies...and that the majority of these proxies are installed on compromised consumer Internet connections (cable, dsl, and yes, dialup!). Current RBLs DO discover all types of proxies, however, it a matter of how much time elapses between when a given IP begins to relay spam and when it is detected and blacklisted. I suspect that the current detection delay is measured in at least HOURS and perhaps even DAYS. Furthermore, many consumer connections utilize dynamic IPs (e.g. DHCP, PPPoE, and PPP )...I suspect that sometimes an infected system has changed IP addresses several times before the first IP that relayed spam from is even listed! And don't discount dialup connections, 28.8Kbps is plenty of bandwidth to spam through when you have 10,000 of such systems in your ProxyBot army...and the fact that the relay's IP will change after each dialup connection means you'll never be RBLed for very long. DHCP, though technically dynamic addressing is far less of a problem as IP address do NOT typically change very often...remember DHCP leases are renewed automatically by the client when the lease is 50% to expiration. Many DHCP clients also cache their previously leased IP (e.g. Windows) and explicitly request the same IP even across lease expirations...depending on the service provider, DHCP clients often maintain the same IP for months at a time (aka "sticky IP"). Some PPPoE gateways also maintain username to IP caches so sticky IPs can also result in that scenario as well. I agree that strategy of not accepting mail from a given IP until it has been open proxy tested would likely be effective in stopping proxy spam. Unfortunately this approach is also highly irresponsible...and spammers would quickly migrate the proxy approach to defeat open proxy testing. In order for such scanning to be effective you would need to perform two stages scans against 65,000 ports (if you limit to TCP only). First you have to find all open ports (65,000 probes * 3 for retries), then you'd need to do at least a HTTP, SOCKS V4 and SOCKS V5 (65,000 * 3 types * 3 for retries =585000 probes) proxy test against each of those ports. That's about 13MB of traffic just for the TCP scanning phase. Although a lot of the scanning would be directed at consumer Internet users (who probably wouldn't even notice), a significant amount would be directed at bona-fide mail servers. The administrators of the latter will likely NOT appreciate this and they WILL complain. Frankly, I think the complaints are justified...if someone did that level of scanning into my network (on a daily basis no less) I'd be obligated to investigate, potentially wasting hours of time until I find out the intent behind it. Despite the activity having good intentions, bottom line is has wasted my time...now multiply that time by the 1000s of network and security administrators that would do the same. Even if such an approach was initially effective it would ultimately fail. Spammers would simply migrate to authenticated proxies, proxying via UDP (which can almost impossible to scan for), or proxying using custom protocols thus defeating SOCKS and HTTP relaying tests. Personally, I think the better approach to fighting proxy spam is to identify the spammers that are *upstream* from the proxies and then get one or more of them thrown in jail, not for spamming, but for violating federal or state computer intrusion laws. Spammers are currently using open proxies because they are free and anonomous, until you make them non-anonomous AND costly (jail) there's nothing will stop them. This is not as hard as it sounds...if you are an ISP you have hijacked proxies on your network. The RBLs can tell you which IPs are hijacked proxies, all you need do is capture Netflow data and examine the upstream IPs pummeling the hijacked proxy on it's SOCKS and/or HTTP proxy port. The results of such analysis is extremely enlightening...these spammers have NOT moved off-shore, they are NOT using multiple levels of proxy chaining and obfuscation, they are spamming DIRECTLY from their web hosting and corporate offices in North America, and as is often the case, South Florida. The other approach is to identify the "master" servers that are controlling these ProxyBot networks (most hijacked proxies "call home" to the master to report their IP and current proxy port info). In the last few months I have reverse-engineered several proxyBots and identified quite a few master servers....some hosted at US-based web hosting companies. If you take out a master server, you take out 1000s or 10s of 1000s of proxies. What amazes me is that master servers that I identified back in Oct 2003 are STILL operational today. This suggests to me that almost no one is pursuing this approach. I suspect the problem is one of a lack of coordination within service provider organizations. They all want to stop spam, but they seem more focused on preventing it from coming in vs. stopping it from going out from their own customers. Sorry, but if you can't even stop it from being sent from you own subscribers you're not going to find any solutions to the more difficult problem of blocking inbound spam. An effective fight requires a combination of Netflow data (from network engineering/ops), spam complaints (from Abuse dept), spam proxy code (from customers system), and forensic examination (by security researchers or in-house security teams). Apply this approach across several large SP networks and I guarantee it will become clear where the majority of spam is really being transmitted from... Regards, Lawrence Baldwin Chief Forensics Officer myNetWatchman.com Atlanta, GA +1.678.624.0924