A brief history:
- Spammers send mail directly to victims.
- Server admins block by source, victims complain and try to get spammers kicked off their networks.
- Spammers relay through third-party servers to disguise their origin.
- Server admins shut close relays, and block mail from open relays.
- Spammers relay through trojaned zombies straight to victims.
- Network admins block outgoing mail traffic except through their servers.
- Spammers relay through zombies’ ISPs’ mail servers.
- ????
We’re in the early stages of step 6, with broadband ISPs starting to block outgoing direct-to-MX mail traffic. The obvious response by spammers is, of course, to get their virus-writing partners to add code that extracts settings from the infected system’s mail program, and send through the ISP just like the actual user would.
At this point the problem changes. To use a car metaphor, first spammers drove their own cars, then they stole trucks, and now they’re stealing your car while you’re at work and driving it off-road. Soon they’ll be stealing your car, but keeping to city streets and using a fake drivers’ license with your name on it. So blocking by source and authentication won’t be enough.
The next step will probably be dynamic blocks on outgoing mail based on some sort of traffic analysis. This would be things like temporarily blocking mail from client IPs that send out viruses, and notifying the customer. Perhaps using statistical analysis like credit card fraud protection. (Hmm, this customer normally sends 10-15 emails a day, but seems to have sent 1000 in the past hour.)
We may be reaching the limits of blocking by source—or at least blocking by immediate source. If some sort of sender verification (SPF or DomainKeys) really takes off, it may be possible to extend it further.
