Thursday, June 19, 2008

Backscatter (or bounce) Spam, didn't we already solve this?

Today I heard yet another email administrator complaining about waves of backscatter spam frustrating him and his users- and his complaint was that users were complaining about it instead of just deleting it.

I have two problems with the situation-

First, as IT personnel, it is our job to deliver results so the business or organization can do its job.  Complaining about users complaining about something which annoys and distracts them (and is potentially malicious) is a sign of forgetting why IT exists.

Second, this is yet another issue which was largely solved years ago, and yet still exists.  Those users are complaining about about something annoying, distracting, potentially malicious and preventable.

A little background for those unfamiliar with backscatter:

Suppose "Bob" (it is always Bob, isn't it?) wants to spam Dave and improve his chances of successfully getting his message delivered- if he could make his message both appear legitimate and appear to be coming from a known, trusted mail server, Bob would have a good chance at getting the spam delivered.  If Bob sends his spam message to an invalid email address at a known and reliable email domain and spoofs the sender address to be Dave's email address:

  • the message is sent to the legitimate mail server
  • the email is rejected by the mail server
  • a bounce message is sent to the address in the "sender" field
  • Dave gets the email, which appears valid because
    • it is an real bounce message
    • it is coming from a valid mail server

How to stop it? The first mail server can reject mail (without a bounce message) from mail that fails SPF, reverse DNS, and blacklist checks.  And the real answer- the receiving mail server (or mail gateway) can implement Bounce Address Tag Validation (BATV).  Mail servers and gateways which have implemented BATV "tag" all outbound email with a timestamp and token identifying the message as coming from that server.  When bounce messages are received, they are checked for the appropriate tag, if there is no tag the message is dropped.

BATV works very well and rarely causes problems when exchanging email with properly configured, RFC-compliant mail servers.  Problem solved (at least mostly solved).

Full disclosure: my employer's products implement BATV.  But, many Open Source and some competing commercial systems also implement BATV- click here for here a list.

So now can focus on solving problems not already solved?