My first thought was that someone was running a dictionary attack against the domain, trying many different addresses to see which might be valid. Then I noticed that they seemed to be coming from <> — in other words, they were bounce notices.

Great. A Joe Job.

I enabled a catch-all temporarily. That did cause the server to slow down, as it was now actually processing the quadruple load instead of kicking back 3/4 of it with a “User unknown” error. (I hadn’t thought to disable spam scanning on the domain first.) In the 30 seconds before I turned it off again, it picked up 25 non-delivery notices. And those are just the ones that got past the spam filter.

As it turned out, they were just random junk. Some spammer had picked the domain and was using it to forge random From: addresses, and we were getting the bounces. In the old days they made up the whole address, but it’s easy to check whether a domain exists. So now they pick some real domain and make up a fake address. That’s harder to detect unless the domain in question uses some sort of verification system like SPF or DKIM.

So it wasn’t a Joe Job: no one was trying to besmirch the site’s reputation. It still meant extra traffic to the mail server, though.

This problem is called backscatter, and it exists for two reasons:

1. The sender address on an email message is easy to forge, like writing a fake address on an envelope.
2. Many mail systems will accept a message first, then process it. If it then decides to reject it, it can’t respond to the actual sender, only to the one listed in the message—and in the case of spam, it’s usually forged (see #1).

I don’t send any mail using the domain. The only reason it even has mail pointed anywhere is so that I can receive mail sent to the webmaster for the Alternative Browser Alliance. I suppose I could set up a -all (no servers are authorized) SPF record, and hope some recipients decide not to send bounces. But I’m not sure how much it would actually accomplish.

Anyway, the two lessons to take away from this are:

• Reject messages to bad recipients in the initial SMTP transaction. It’ll protect your server from backscatter (and dictionary attacks), because you won’t have to queue and process all the extra junk.
• Don’t generate bounce messages after the fact based on something as easily forged as the supposed sender. Otherwise, you’ll be contributing to backscatter.

1. Spammers send mail directly to victims.
2. Server admins block by source, victims complain and try to get spammers kicked off their networks.
3. Spammers relay through third-party servers to disguise their origin.
4. Server admins shut close relays, and block mail from open relays.
5. Spammers relay through trojaned zombies straight to victims.
6. Network admins block outgoing mail traffic except through their servers.
7. Spammers relay through zombies’ ISPs’ mail servers.
8. ????

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.