Skip to content
Thoughtful, detailed coverage of everything Apple for 34 years
and the TidBITS Content Network for Apple professionals

Major ISPs Coordinate Spam, Spoofing Policies

Last week may be a watershed in the efforts to suppress spam through efforts to eliminate the many illegitimate methods by which spammers send and relay their email.

Earlier in the week, several major Internet service providers (ISPs) agreed to some basic tenets on how to manage their own networks and their customers’ networks to avoid helping to perpetuate or tolerate spam. Late in the week, Microsoft and the developers of the Sender Policy Framework announced a merged version of their two anti-spoofing proposals that would give domain owners more control over which servers could process their outbound email.

Model for ISPs to Fight Spam In-House and Inbound — Some of the largest U.S.-based ISPs issued a model policy document that codifies best practices in shutting down spammers that use ISP resources, whether hijacking their customers’ computers (turning them into zombies) or using open relays to send their spam. The document was authored by the Anti-Spam Technical Alliance (ASTA), which includes America Online, EarthLink, Microsoft, and Yahoo among their members. You can download the document from any of the members’ sites.

< jun04/06-22ASTAPR.asp>

< 23779c05-d409-46ce-b9d6-c24908789d8b/ ASTA%20Statement%20of%20Intent.pdf>

This document doesn’t change the basic methods by which spammers send or deliver their wares, but it does define a high standard of performance that should be essentially the law for peer-to-peer email exchange: if your ISP doesn’t conform to the document, then they’re not participating fully in the necessary struggle against spam. If the majority of ISPs made sure they implemented every recommendation, spam wouldn’t go away, but the volume would be severely reduced.

Here’s a summary of the recommendations in one paragraph:

Shut down open relays. Monitor well-known unintentional scripts that forward email to arbitrary recipients. Make sure proxies work in internal networks only. Discover if local machines are compromised and sending spam, and figure out how to remove them from the network through notification or by shutting down the connection. Use authenticated SMTP. Change passwords on customer routers, like DSL modems. Install reasonable limits on inbound and outbound email for standard accounts. Don’t allow instant account access for new registrations. Turn off open Web redirectors. Improve complaint reporting and handling.

The only part of these proposals that might raise fears are the limits on inbound and outbound email. The proposal recommends limits like 150 unique recipients per hour and 500 per day. Many people would find these restrictive. This would unnecessary limit many users’ ability to conduct business, and would require storing unique addresses, which could potentially violate an ISP’s safe harbor against illegal content, too.

Spoofing, Revised — A second section of the ASTA document deals with the prevention of email spoofing or forgery, which also received a boost last week. As I wrote in "SPF Protection for Email" in TidBITS-722, a proposal known as Sender Policy Framework would allow domain holders to state, via their domain name service (DNS) records, which mail servers on the Internet were legitimate to send email that includes their return address.



As noted in that article, Microsoft had a competing proposal known as Caller ID that used a similar but distinct approach. SPF looks at some basic information in the handshake that happens when one mail server talks to another; Caller ID looks at the body of the message, requiring more server load to figure out whether a message is valid or not.

Last Thursday, the developers of SPF merged their proposal with Caller ID into something called Sender ID, which was then submitted to the Internet Engineering Task Force (IETF), a body whose proposals are typically turned into implemented realities. Sender ID will combine the best of both proposals and will subsume support for the SPF format.

< spam_senderid.mspx>

Version 3.0 of Spam Assassin, which just became an officially supported project of the Apache Foundation – the folks who brought us the Apache Web server, among other server software – is about to be released with support for using Sender ID records as one of the factors in scoring incoming email as spam vs "ham."

Will Spam Slow Down? It’s easy to be cynical and look at both announcements as more thumbs in the dike. The water level is rising and Dutch boys and duct tape won’t cut it, right?

I’m slightly more optimistic. The lengthy list of best practices in the ASTA document do include some of the most egregious ISP failures. It’s unclear if ISPs are unaware of these techniques or just choose not to devote resources to them. If the ASTA document provokes ISPs to identify zombies more aggressively and shut down their capability to send email out (i.e., block TCP/IP port 25) while the ISP notifies the customer, that alone could reduce spam significantly.

The only downside of these recommendations and proposals is that they could lead to what is essentially a whitelisted Internet: instead of blocking bad email, bad sites, and bad actors, only "good" actors would be allowed to deliver email, for instance. "Good" is always a hard quality to define, and there are reasons to allow ambiguity – not over spam, but over identity for reasons of privacy, sovereignty, and diversity.

Still, because these measures require unilateral participation by large numbers of ISPs to succeed, it’s probably better to view them as more of the Internet spirit that allows decentralized information exchange.

Subscribe today so you don’t miss any TidBITS articles!

Every week you’ll get tech tips, in-depth reviews, and insightful news analysis for discerning Apple users. For over 33 years, we’ve published professional, member-supported tech journalism that makes you smarter.

Registration confirmation will be emailed to you.

This site is protected by reCAPTCHA. The Google Privacy Policy and Terms of Service apply.