The spit is hitting the fan these days over the impending standards for SMTP authentication. Im a big fan of it, but many are arguing against it—some constructively and some not.
One of the main dismissive put-downs against authentication, especially with respect to zombied PCs, is that spammers and worms will simply switch to using the users authenticated ISP account to send spam.
There are a number of reasons why Im not so worried about this. One of them is that ISPs, at least consumer ISPs, will need to begin limiting the number of e-mail messages sent by users. This is one of those policies that will leave 99-something percent of all users unaffected but generate extreme rage among the others.
Hard limits are not a good way to implement changes like this. What is needed is what we call “rate limiting”—limiting the amount of mail users can send over some period of time. When you do this, you implicitly limit the total amount of mail they can send and, as a practical matter, can make high-volume spamming impractical.
As I noted in a recent column, many ISPs are monitoring the use of port 25, the SMTP port, on their clients connections. They dont talk about specifics, but Im sure ISPs that exercise this route look not just at the volume but at headers and perhaps for evidence that the system is being remotely controlled.
Blocking actual use of the ISP mail servers is another matter. I spoke to a couple of ISPs that do monitor their mail servers looking for abuse. Clearly, there are some things users can do that would block most acceptable usage policies, such as sending viruses or pornography, but it basically seems to me that they are keeping their policies vague.
I think the time has come to be more specific. Set a rate limit for outbound mail for consumer accounts. There are systems available to enforce it. And it would be yet another sign to users whose computers have been taken over that they need to clean them out.
Its the future of mail worms, and in fact the only future for mail worms. Theyre going to have to authenticate someday, so they will either need to use open relays or scam the user out of their own SMTP AUTH credentials. SMTP AUTH is the authentication scheme for end-user SMTP server access. Most ISPs require that you provide a username and password to send as well as to retrieve mail, and eventually all of them will.
Ive read stories about worms attempting to send mail on authenticated SMTP servers by guessing weak passwords. Simply by scraping e-mail addresses, you can guess the usernames (foo is the username for [email protected]).
If the system doesnt force you to choose a strong password, many users will try “foo” or “password” or “asdf” or “comcast” or something else really easy. Weak SMTP AUTH credentials are an understudied problem and will come to the forefront in the next year or two for this reason.
I checked with a couple of network security scanners, and neither of them look for weak SMTP AUTH credentials. With an open scanner such as Nessus, it should be possible to write a plug-in that does the test.
Rate limiting isnt a new idea for stopping spam. Microsofts famous Penny Black project, which attempts to make the sender pay for sending an e-mail by solving a computational problem that takes a fixed amount of time, is a roundabout way of implementing rate limiting.
Why not just rate limit? The Penny Black argument would be—I guess—that a recipient can rate limit the sender rather than relying on infrastructure-based rate limiting. Personally, I think theres a much better chance of major changes happening on the server end than on the client end.
Time to wake up and smell the limits. Consumer broadband accounts that provide happy hunting grounds for zombie programs will need to be restricted in their freedom to e-mail willy-nilly. Its too bad, but its not going to affect the overwhelming majority of users who have no need to send mail other than through their ISPs mail servers, and no need to send even 100 messages a day, let alone thousands.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer