Sober Analysis of Mail Worms and Spam

Opinion: It's faded a bit from our focus because of a lack of developments, but mail worms and spam are still huge problems. There are things we can do.

Most of us got some of that weird German nationalist spam recently. The spam barrage was performed through a new bot network created by a new mail worm, a variant of Sober.

It had been some time since a major outbreak of any of these mail worms and a very long time since a major new family of mail worms was released. In the meantime the tools to block them have improved and protections against them in Windows and e-mail clients have become more mature, diminishing the number of potential targets for them.

But it doesnt take many systems to generate a storm of spam. I tried to find out from anti-virus vendors and analysts how many systems were involved in the spam wave, but got no answers. This is par for the course, and thinking conspiratorially, its better for them if we think there are many such systems out there.

If Im right and it doesnt really take tens of thousands of systems to produce a spam wave like this, then another way to approach it is to stop the spam, which should be an uncontroversial goal. Ive already been all over the best way to do that: shutting down unauthenticated use of port 25, the standard unauthenticated SMTP port.

I havent seen the actual data, but conventional wisdom among analysts holds that the vast majority of systems actually infected with mail worms and sending out the spam from them are on consumer broadband systems. If those users ISPs were to block unauthenticated SMTP, the worms could not send mail—at least not easily, and not as such worms are currently written.

To quickly summarize, the ISP would have to require that all outbound mail from customers go through their own server, e.g. mail.consumerisp.com, and probably require SMTP AUTH, meaning that the user has to provide a username and password to the SMTP server.

The only way around this for a worm would be to crack the users cached credentials and use the server, which is certainly possible, but still leaves the ISP in an excellent position to detect the abuse and shut it down, assuming they care. See the previous column for much more on this.

But a bit of follow-up is warranted: The most common objection to this technique is that it would prevent users from using outside SMTP services, and many of these concerns are reasonable.

For instance, if I own a hosted domain and want some or all of my mail to be sent through that domain, even though it is not the same provider as my ISP, port 25 blocking is a problem. Likewise if I want to send mail using the SMTP server for my business.

There are several solutions to this, one of which has the potential for general application. The first, best, and most difficult one is to use a VPN. This gives you a secure channel into a network that has proper access to the SMTP server. But VPNs have their own connectivity problems and are difficult to set up in the best of circumstances.

Another solution is to provide Web mail for the other system you want to access.

In other words, your business or hosted domain could provide Web mail access that uses port 80 instead of port 25.

The problem with this is that Web mail can be limiting and, in any event, is probably not the users preferred mail program. Why shouldnt they be able to use their preferred program?

Next page: The answer: port 587.