I overheard someone bitching about SPEWS blocking Telewest the other day, about how SPEWS had gone too far (seriously, are people really using SPEWS?) treating innocent users as spammers blah blah blah. The BBC story has quote from the ISP, Telewest, about why they’ve apparently been so slack about stemming the tide of spam coming from PCs infected with hidden spammer-controlled mail-engines:
“We are currently contacting affected customers to help them clean their PCs which, as you can imagine, is a time-consuming task,” it said.
Which, while it needs to be done, is exactly the wrong way to fix this. They may as well have added “and once we’ve contacted all 16,000 of the infected users we imagine nobody on our network will ever be infected with a virus or trojan ever again.”
The proper solution I’ve long supported is blocking outgoing port 25 from dynamically allocated addresses.
Now, in theory, all receiving servers could just refuse to accept mail from these addresses. Unfortunately there’s no simple way to do this. MAPS had an RBL for this purpose the dial-up user list, the “DUL”, I’ve no idea if this still publically usable, or if it’s still maintained. Regional IP registries don’t seem to record this information in a way that’s publically queryable. You might encode it into DNS in some way, but given the pathetic level of reverse DNS deployment by many providers I wouldn’t expect that to be done.
You have to stop the spam from leaving your network. You have to block it, not at the application layer – but at the network layer. Any solution that requires effort on the side of the receiver is already broken.
Today, it seems that blocking port 25 is what the US Federal Trade Commission is advising ISPs to do as part of Operation Spam Zombies.
- block port 25 except for the outbound SMTP requirements of authenticated users of mail servers designed for client traffic. Explore implementing Authenticated SMTP on port 587 for clients who must operate outgoing mail servers.
However, the advice about port 587 seems a little confused to my mind.
The solution for “clients who must operate outgoing mail servers”, presumably those who need to send direct-to-MX mail (operators of mailing list servers, for example), is for those customers to be allocated static IP addresses, with correct and useful reverse DNS records. Just putting machines on static addresses doesn’t make them less susceptible to trojans, of course.
But it does allow for some level of “reputation” heuristics, if only to allow others to adjust their filters and back/whitelists.
Port 587, specified in RFC2476 (back in 1998), concerns how clients submit to an authenticated relay. Not necessarily operating a outgoing mail server from within the ISP’s ranges (which I take to mean a machine that performs direct-to-MX SMTP delivery).
The concept has two major benefits – firstly by separating submission and relay/delivery it should simplify the configurations and operation of mail servers and also firewall configurations. At the client end it allows you to configure the mail software on a network roaming laptop to use the same outgoing mail server without having to worry about port 25 blocking.
And note that in some circumstances it is a requirement that people relay mail though a specific, external, mail server. Some regulations require that all business mail be auditable, and usually this means using the mail server to store a copy.
If you’re already running a mail server that requires SMTP Authentication then you should make it available on port 587 as well as (or instead of) port 25. So in terms of advice – it’s not the network providing ISPs that need to be talked to – it’s the third party providers of mail relaying services, it’s the providers of mail server software, and it’s the providers of mail client software.
The second group isn’t too much of a problem. Sendmail certainly supports port 587 though its MSA (Mail Submission Agent). And, since the only real difference in protocol terms between port 25 and port 587 is that port 587 traffic must require SMTP Auth, you can get away with running another server on the other port (if that’s possible) or, as a hack, just redirect port 587 traffic to port 25 on the same address.
It’s the client software that I’d expect to be problematic. Despite being a Standards Track RFC for six-and-a-half years, I’ve never really encountered much support in mail clients.
At best, I’ve seen clients that allow you to change the port number from a default of 25 – but nothing that acknowledges the “official” status of 587. Just as a test I’ve checked the configuration of Evolution, and it makes no reference to using alternative ports at all (although you can apparently suffix “:587″ to the host name for the same effect.
Ultimately, I guess you could set up some thing locally that listens on localhost port 25 and relays on to the remote server with SMTP Auth.
If blocking port 25 is going to work on a larger scale, people need to be submitting bug reports for the software that they’re using right now.
