eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
The Answer
: Port 587″>
The real answer for most people is port 587. It turns out that this port has always been there and under the applicable standard is actually the preferred port:
Most, and probably almost all mail server software supports authenticated submission on port 587. Any that dont are non-compliant and you should complain.
Its essential that if you add port 587 support it enforces authentication; otherwise youre just trading off port 25 vulnerability for port 587 vulnerability.
On the assumption that most of the situations wherein external access is a problem involve hosted domains, I asked several of the largest hosting services whether they support port 587 access for external users to hosted mail domains.
Remember, just because their servers support it doesnt mean the hosting service opens the port on the firewall and enables it on the mail server.
Here are the answers I got or didnt get (“yes” means they support port 587 for external users):
- 1and1: yes
- Interland: yes (not just a fallback; their docs tell users to use 587)
- ThePlanet: “The Planets mail service does not currently advertise a submission service on TCP 587 by default, and weve never received a request to do so.”
- EV1: No response
- Yahoo! Domains: No response (but I think the mail is managed by SBC, which supports port 587 on its own accounts
- GoDaddy: No response
- Verio: “As a business ISP, Verio does not block port 25 mail for its customers, but in many cases does enable alternate ports so that customers may continue using their servers for mail. The majority of server plans at Verio supports port 587—some by default. Our dedicated hosting customers can enable or disable as they require.”
So its a mixed response. I think its cheesy for a major ISP not to support it, but I suspect ThePlanet is right that there isnt a lot of clamor for it. There should be, and users need to know that there is a relatively easy answer for the “problem” of ISPs blocking their port 25 access.
Its inevitable that malware writers will work around authentication solutions by cracking cached credentials, but this still leaves the ISP in a powerful position, since it will see the spam going through its servers and will be in a position to easily block the user and force them to remediate.
Users like me who have good protection against spam and viruses can easily overlook them, but they are still a major problem.
Its frustrating that there is so much opposition to solutions to them, even if the solutions are far less disruptive than the problems. The answer could be within our reach.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.