Shutting Down the Highway to Internet Hell

Do you run a mail server on your home Internet account? If you do, it's probably without your knowledge, such as in a mail worm or a zombie spambot. Few if any people running these programs intend to do so, and it's time for ISPs to close the door through which they operate.

I think there's a consensus developing among anti-spam researchers, many of them responsible for fighting spam on ISP networks, that unrestricted use of TCP port 25 must be shut down to the average Internet consumer. There are those who disagree, but their arguments sound obtuse and defeatist rather than actual justifications to not block port 25.

TCP Port 25 is one of the core interfaces of the Internet, through which Internet mail servers typically send mail to each other. It's normal for users to send data out port 25, but they do so to their own ISP's mail server, from which it is forwarded on to the appropriate location. This is the server identified as the outgoing mail server in the mail client configuration.

But if you are infected with a spam zombie—typically, a mail worm with a backdoor used by a spammer to cause your computer to send out massive amounts of spam—the mail does not go through your mail server. It probably goes directly to the server of the target domain for the spam message. The overwhelming majority of users have no need to do this and are perfectly well-served by sending all their mail through the ISP mail servers. It's also worth reiterating that the block need only be put on consumer client systems, not on higher-end services.

Of course there are users who do need access to the port, or who at least want to run their own mail server and don't intend to abuse the privilege. Or they have a need to use a different mail server than the ISPs, perhaps for reasons involving confidentiality. There are ways for ISPs to accommodate these users.

In fact, there's no reason an ISP can't make exceptions for users who want to use port 25 more openly, especially if they agree to rate limits and to configure it securely. The real problem that needs to be solved is the users who don't know they are running a mail server. Such users won't miss not being able to run one.

Alas, this level of customer service may be too much to expect from some ISPs. Hosting servers are also often far too lax in the management of mail on their networks.

But some ISPs are putting their feet down, attempting to stop the abuse. At the forefront of this effort, defying all conventional wisdom, is AOL. In the 90s, an era of very different circumstances, AOL was the single largest source of spam on the Internet, and the ISP's reputation suffered terribly from it. Now not only AOL users have high-quality spam control, but AOL is perhaps the most active ISP in terms of policing the use and abuse of mail.

Consider the rules at AOL's "Technical Standards for E-mail Delivery." AOL makes extensive use of RBL services like MAPS so that they know to block spam from open relays, spambots, systems with unsecured form-mail scripts and other spam sources. They actually use the same services to block spam that comes directly from residential ISP clients that should not be sending mail directly; in other words, if you don't block port 25 yourself, they will do it for you.

The ISP goes further—much further. If the sending system does not have a PTR record (a reverse DNS), it is rejected. If a message contains a hex-encoded URL (like http://%73%70%61%6d/), it is rejected. If more than 10 percent of the sending system's messages to AOL bounce, AOL may reject mail from it in general. If a server rejects 10 percent or more of the bounce messages sent to it, AOL may reject further connections from the server. There are other, similar rules.

All of this is intended to use AOL's size and clout to make other e-mail administrators set up and administer their systems properly. In many cases, the reverse DNS requirement, for example, the administrator finds out that he or she doesn't have a reverse DNS because AOL blocks the mail, and the end result is an improvement for everyone. Mail servers should have a reverse DNS if they have nothing to hide.

Perhaps not everyone can do everything AOL does. It does, after all, have a proprietary internal mail system. But there's a lot we can learn from its example. Carl Hutzler, until recently in charge of AOL's anti-spam efforts (he has now moved on to a position in engineering and development of AOL's e-mail), has been evangelizing this ethic of responsibility by mail admins, especially at ISPs.

Hutzler warns of the lazy approach of relying on filters, as so many ISPs do. It's the easy way out. But anyone with a little experience knows that filters don't even come close to solving the problem, although they can be a useful part of the solution. I've seen messages with overtly pornographic subject lines and bodies make it through three different Bayesian filters. Spammers know how to play with the content of the message to trick filters.

But the technique that generates the most controversy is when an ISP blocks port 25, as SBC recently began to do.

As one prominent researcher put it, blocking port 25 begins the process of shifting the cost burden for spam from the end user to the ISP and others whose sloppiness in administration is responsible for the unchecked proliferation of spam, and these same people are in a position, through responsible system administration, to choke off most of the abuse. He also argued that the cost benefits of fixing their systems are enough incentive to do it.

Check out eWEEK.com's Security Center 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 Seltzer's Weblog.

The depressing counterargument is that many of these systems have excess capacity enough to handle the abuse and that laziness is its own reward. When this is the case, there's no choice but for other ISPs to start blocking the offending ISP, as AOL has done many a time.

This is another point on which a consensus is emerging: that ISPs don't take action to stop spammers on their networks until there is a gun to their heads, generally in the sense that their customers are prevented from sending mail. This is where the major RBLs like Spamhaus and MAPS can play a big role. They have a bad reputation among some, and I've personally been among the collateral damage from an RBL block. But it was my hosting service's fault that my server got on the block because they didn't do anything about the spammer on the same address that I had. Enough of us called and screamed, and something was done about it.

Not every little domain has the clout to block a major ISP. The little guy ends up hurting and angering his customers, but the big ISP won't even notice. But when one major ISP, or a service like MAPS, blocks a major ISP, it gets their attention. The corollary to this is that when you block someone, you need to be responsive when they fix the problem.

The fact that ISPs have no reason to not let users opt out of the system is what cinches it for me. One researcher suggested to me that it was much easier for ISPs just to block a whole range of addresses than to have to put up a system for tracking who was to be blocked and who shouldn't, but this is basically just arguing laziness as an excuse. Besides, the SBC system supports letting users request an opt-out. Why can SBC do it and others can't?

The same researcher was concerned that the opt-out system would be taken over by spammers who would opt-out their zombie systems. But it's not hard to imagine well-designed authentication systems that mail back a message to the customer and require them to connect back.

And as for the added cost to the ISP for this, I'd suggest that they might just save a lot of money by eliminating spammers and mail worms from their networks, but even if you think this is a costly solution, let them charge for the opt-out. Doesn't bother me.

Those who argue against ISPs blocking port 25 generally claim that the downsides are high and that spammers will a) evade the blocks and b) easily move to other techniques for sending spam. Joe St. Sauver has made a well-written case for this position. I admire some of his points, but I still disagree with him, and I think half his problem is that he can't see the point through all his defeatism. Namely, even if spammers were to move to other avenues, it's still worth closing port 25 to stop them from using it.

Getting right to what I feel is the main point, that port 25 blocks will be ineffective because spammers will move to other methods to spread spam, St Sauver brushes aside or ignores counterarguments. He cites recent stories that spammers are beginning to use the ISP mail server instead of sending out spam directly from the client system. There are two counterarguments.

If the ISP requires SMTP AUTH (where you must provide a username and password for the outgoing SMTP mail server as well as the incoming POP3 server), then it will not be a simple matter for the worm to send mail. However, since there are programs available that can read the cached SMTP AUTH credentials from popular mail client programs (click here for one that's sold commercially),

it's not hard to see spam zombies doing the same in the future. They might also do it by monitoring port 25 usage to look for the authentication sequence.

In fact, my own ISP, Speakeasy.net, is very lenient about these things. Speakeasy does not require SMTP AUTH for connections made on their internal network (it does for roaming users), but it says that it monitors mail servers carefully and maintains a number of honeypots on active lookout for malware on its networks.

I spoke to Speakeasy founder and Chairman Michael Apgar, and he insists that a system exhibiting wormlike behavior will not live for long on Speakeasy's network. Within hours the user will be contacted, and if he or she doesn't fix the problem quickly, the plug will be pulled. But Speakeasy is not a conventional ISP; while it's happy to sell to anyone, it has a technically more capable audience who pay more for more open services.

Apgar is quick to agree that mainstream consumer ISPs should be locking down abusable services, and that port 25 is the biggest problem.

Even if the zombie successfully is able to send spam through the ISP mail server, we're still better off than before. The ISP can tell, just by looking at mail server logs, who is spamming from its network. ISPs have a cost interest in fixing the situation and arguably are more responsible for doing so since their own servers were involved. Put simply, forcing the spammer onto the ISP mail server facilitates the elimination of zombies. It also gives the ISP the opportunity to rate-limit mail in general, which will not likely affect regular users, but will seriously cut into spammers' ability to spread the message.

I have a similar reaction to St. Sauver's speculation that zombies, blocked in their ability to send spam, will instead be used for even worse things like denial-of-service attacks. This is not hard to imagine, but while much of the world puts up with systems sending spam, they would feel different about a DOS army. And I can't see that the market for DOS armies scales in the same way that the spam market does. It's just not as big a threat.

He also points out that spammers could still evade blocks on port 25 at the network periphery by spamming inside the network—e.g., to other customers of the same ISP on their subnet. Of course, they will only be able to do so if the recipient mail server is on the same subnet, and this is highly unlikely on a large consumer ISP network.

While most of his writing is laboriously pessimistic, St. Sauver does have interesting constructive criticism. He urges those who would fight spam to focus not on the spam leaving the network but on the traffic coming in to the spambot. He asserts (this is counter to my understanding) that spambots don't typically construct the e-mails they send out programmatically but pass on what they receive from the outside. Whether this is true or not is beside the valid point he makes that it should be possible to look for the command/control coming into the network from spammers. While these commands come in on nonstandard ports, they are known (they have to be, or spammers couldn't find them either).

Finally, for all their claims that easy alternatives exist to port 25, they haven't come up with any. The first port usually listed is TCP 587, but like many of the potential alternatives, it's an authenticated port, so it's not blindly open for spamming use.

In the end, the biggest factor in whether ISPs will play hardball with spammers is whether they want to have to go to the problem of taking out the garbage and keeping their place clean. Some ISPs have complained to me about others who don't seem to care if their networks are used to send out billions of spam messages and mail worms. They don't even look at their own log files!

But the day is coming when these ISPs won't be able to coast through their own laziness and sloppiness. The use of RBLs like MAPS and other blocks of known spammer systems is an increasingly important technique, and if worms really do move to using the ISP mail server, then ISPs who don't do anything about it will find themselves blocked completely by the clean ISPs that are sick and tired of taking abuse.

I don't expect everyone to clean up their act, but think we're moving to an era of unofficial quality standards, of black and white lists, where ISPs will "protect" their customers from the red-light districts of the Internet. It's not perfect, but it's better than what we've got now.

Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.

So your saying that I can not forge a mail header to come from a false address if I ay... find an open relay?

An open/promiscous relay allows you to send email through a system; it doesn't allow you to forge the mailing headers on the relay.

And, there is no point in even trying since it is the open relay that is blacklisted and not the prior hop...

Without prior mgmt agreement, this is probably grounds for termination, and I'm rather fond of being paid :)

I've had a few people wanting to use 3rd party email for business work in the past, but with the current HIPAA and SOX regs, the auditors will back me up on telling them they need to quit that. I realize not everyone operates in that environment, or under those circumstances.

HIPAA is specific to health privacy issues and SOX (Sarbanes-Oxley) only covers audits of publicly held companies....

Sending HIPAA data via email should be done via PGP or a CERT, but there is nothing limiting the originating IP.

Auditors frequently misunderstand technical topics and react with a shotgun approach.

SOX is really concerned more about accountability than confidentiality and, because of that, encrypted email is actually a bad thing here. Corporations would be required to hold private keys of officers for up to 7 years in order to comply with this...

The only place where SOX might apply is if a corporate officer were emailing confidential, audit related information from an external location... which means they're probably on shakey grounds anyway.

In order to comply with SOX, corporate officers would have to surrender their private keys and those would have to be kept in a secure location for 7 years to permit auditors to read all related email. Note that this is true for internal and external email.

We also have FDIC regs involving privacy of client information involved. At any rate, you're right in that they do tend to take a shotgun approach. In their defense, some of these emails do involve audit information and things like contract negotions, and managers tend to treat all email the same. If they use hotmail to send work email from home, they will generally send anything over it they would send through the internal email system at work.

My problem with this is that it would be a major PITA for anyone who operates his own sever (for mailing lists or whatever). Instead of blocking port 25, I'd rather have my ISP use the Open Relay Database and other blacklists to block traffic coming from known zombie or spambot servers.

Bingo. All of the spam that I get to my spam-bucket comes in to my ISP's POP server and I pick it up using fetchmail. Any spam sent to my mail server gets blocked, because I use the blacklists. I don't know why the ISPs won't.

.. when you infect millions of desktop PC's an RBL is no longer going to work.

Yeah, they do. combined.njabl.org has a blacklist of DHCP addresses which is pretty darn complete.

Given the fact most high speed nets are DHCP you could find yourself blocked because the guy before you was a bot.

Not a problem. You use the "smart host" part of sendmail to send all outgoing mail to your ISP's SMTP server.

2) Spam that can be traced often comes from unwitting people whos PC's are infected, you will be hammering them

Actually, I don't see a problem ith this, but it should be handled at the ISP level. Anyone who wants to handle their own mail. (As I have from time to time, though not at the moment), should be able to turn that option on, with the default being deny. Also, if your computer is a spam or DOS bot, it deserves to be shut down. When the customer calls in to the helpdesk, they ask if they are running a mailserver. If customer says "no", you tell them their computer has been hacked and that they need to reload, or, better yet, migrate to a less hackable system like Linux, or OSX.

If granny's computer is sending out spam, shut her down until she fixes it.

So what does this do? It enables an email server to immediately verify that an email message originated from an authenticated source; if not, it dumps the email immediately. Problem solved.

I don't see where this helps anything. You're creating a lot of new infrastructure that someone will have to pay for.

And you're ignoring the fact that lots of overseas ISPs exist solely for spammers... wannado.fr and hinet.net for examples... and they would be willing to pay the price to get into the "network". Then they'd have to be blacklisted -- just as they are now.

And on top of that, you've come up with a nice little way of tracking e-mail addresses and number of e-mails sent, which just might come in handy to the government someday.

Except that on an RBL of DHCP I could very well end up the IP that is on the RBL. The effect on people who use legit mail servers on DHCP ranges is the same..

ALL addresses in the residential DHCP subnets are in the blacklist. Yours is. Mine is. The effect of this is that we can't send outgoing mail directly to someone using the blacklist.

So we send outgoing mail through the ISP's mail server, which will NOT be on a residential subnet. That's okay.

I'm primarily concerned with incoming mail to my mail server. If RR blocks port 25 inbound, I'm sunk, because that's the only way in. Outbound isn't a problem.

I don’t smoke.
But I understand now. So states can shake down there residents.
Credit card co. will no longer do cigarette transactions over the net.
If they can do this Why not stop co. that use SPAM from using credit cards to get money.
If you ask me SPAMERS are a lot more annoying than smokers.

In their defense, some of these emails do involve audit information and things like contract negotions, and managers tend to treat all email the same.

If the possibility exists, then the auditors are correct because it removes the potential and appearance of /for non-compliance... and methinks the feds will probably want to use SOX on someone before the next election to say they're doing something constructive :)

The real problem is the people who order products advertised in spam. These are the people who make the whole game so profitable. If nobody ordered from spam, it would not be worth sending.

While it presents obvious problems, I would love to see "fake" spam (can spam be "real"?), so that when the user clicks on it and tries to order he gets a warning about stupidity. He also would have his name posted on a Fools Hall of (Sh)Fame website. Employers could check what employees tried to buy fake degrees. Businesses could check which customers tried to buy fake ID. Guys could check on which buddy tried to buy Vi4gr4 or p3n15 enlargement products.

After enough people had been humiliated in this fashion, perhaps the message would get out. Do not respond to unsolicited e-mail offers. It is a loser’s game.

I don't see where this helps anything. You're creating a lot of new infrastructure that someone will have to pay for.

Why? OSS devs aren't capable of producing this architecture?

And you're ignoring the fact that lots of overseas ISPs exist solely for spammers... wannado.fr and hinet.net for examples... and they would be willing to pay the price to get into the "network". Then they'd have to be blacklisted -- just as they are now.

It doesn't matter whether they "get into the network". All mail senders would have to pay for their specific volume of mail. So those that send more would pay more -- and it would naturally put a stop to this kind of abuse.

And on top of that, you've come up with a nice little way of tracking e-mail addresses and number of e-mails sent, which just might come in handy to the government someday.

The government can already do that now (ie. Carnivore). So this doesn't introduce significantly better capability for law enforcement -- other than better traceability.

PKI (public key infrastructure) is intended to encrypt / authenticate email from / to *individuals* not systems and very few places have it running on anything other than a rudimentary basis due to the cost and complexity involved. The large players could implement Certs for their mail relays, but given the difficulty most locations have with simply running a virus scan on an infected PC, this would also create lots of delivery issues.

Good points. I agree that PKI is not easy to deploy -- particularly in mixed environments; however, in my view, that problem is the lesser of two evils.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.