NDR spam

One problem with spam today is that a substantial minority of it is generated by nominally legit gateways and anti-spam products who are merely responding to spam.

When Alice sends spam to Bob, she uses Joe's identity. Bob's server figures out that it is spam, and sends the response to Joe. Hence we get a Joe job.

Some of our clients wake up one day to find one of their users is getting hammered by a pile of NDR spam. We have rules and technology to deal with it, but they're still messages that most of the time we should never have had to bother with, and exhaust our client's bandwidth.

The nature of SMTP lends itself to a store-and-forward protocol. Sending a message through 10 servers isn't much different than sending it through 1. So by the time an anti-spam gateway gets a hold of the message, it may already have gone through several hops.

When the anti-spam gateway decides a message is spam, it has a few options. Broadly:

1. Tell the recipient.


2. Tell the sender.


3. Just drop it on the floor.

Each choice has some merits and drawbacks.

Tell the recipient. It can modify the subject or body, or quarantine the message and periodically give the recipient a summary of blocked messages. A drawback is that the recipient still has some work to do, and a large spam attack can still consume internal resources.

Tell the sender. This can give legit senders an option to realize that their contact with the recipient has failed. It can also save the recipient with having to deal with the message at all. Sometimes there is the feeling of smugness at making the spammer deal with the bounceback, but this is misplaced. I'll get to that below when I talk about the significant drawbacks of this choice.

Just drop it on the floor. If you've got a "50% off Generic VAIGRA Spam" mail, you don't really need to tell anyone about it. Put a bullet in its head and move on. A drawback is that, once this procedure is automated, now no one knows that the message never got to its intended recipient. Dropping the messages into a log file that an administrator can later search through is a less bad alternative.

Let's go back to telling the sender. The naïve approach is to send them a mail indicating what went wrong. However, in the case of spam, the sender is always forged, sometimes to a non-routable address, but sometimes to an innocent victim. This lets a spammer use your anti-spam gateway as a reflector -- you've become like an open relay, almost certain to end up on an RBL.

Blindly bouncing back to the sender acerbates the problem of spam for every one. Some other anti-spam products have taken a stand against ever doing it, but it's still done more than it should.

There are a few steps that can be taken to make bouncebacks less likely to hit innocent victims. As a first step, only connect back to the IP address that connected to you. But this can make some legit senders unable to receive the bouncebacks if they don't have the same outgoing as incoming server. Similarly, the message may have already been stored-and-forwarded through another SMTP server.

You can get broader on this approach by only sending bouncebacks to IP addresses that are allowed to send mail for that domain, such as DomainKeys or Sender Policy Framework. This is slightly more likely to hit an innocent victim, but legit senders are much more likely to get their feedback. These frameworks aren't universally used, though.

(And for heaven's sake, if the reason your anti-spam gateway is rejecting the mail is because SPF doesn't match, you should already know not to send a blind bounceback.)

You can get better, though. The SMTP transaction allows for failure messages. If you can tell that a message is spam before the sender finishes talking to your gateway or SMTP server, you can provide direct feedback to the sender.

A few caveats with that, though: you don't know which SMTP server is the one talking to you. In this day and age, for a legit sender, it's quite likely that you're being talked to either by the sender or the sender's ISP, which will manage to get a message back to the user about the error. Usually.

Another issue is that scanning during the SMTP transaction requires more network resources. It's one thing to listen for incoming messages and write them to disk. It's another to do live scanning while keeping SMTP connections open. Our boxes tend to have more CPU and RAM than our competitors', but you can still end up in a situation where your gateway is so busy scanning messages that it doesn't have time to listen to new connections, or in dire circumstances even exhausts all of your incoming ports. Sometimes you also can get some better spam scoring if you wait just a little bit for the message to show up in honeypots.

No spam method is perfect, and each solution has its own niche. But vendors and administrators need to take steps to avoid making the spam problem worse for other people.