Backscatter

Backscatter is the flood of automated replies — bounce messages, out-of-office notices, virus warnings — that arrives at an address which was forged as the sender of mail it never sent.

The victim is not the recipient of the spam. The victim is whoever’s address the spammer put in the envelope sender, because every bounce generated along the way is delivered there.

How does backscatter happen?

The mechanism is a mail server that accepts a message first and only afterwards discovers it cannot deliver it:

1. A spammer sends a message to nonexistent@example.net with a forged envelope sender of you@your-domain.example.
2. The receiving server accepts the message during the SMTP session without checking whether the recipient exists.
3. Delivery fails afterwards, so the server generates a non-delivery report as it is required to do.
4. That report goes to the envelope sender — your address.

Repeat across millions of messages and a mailbox becomes unusable. The root cause is step 2, and it has a name: accept-then-bounce.

What does backscatter look like?

It looks like an ordinary bounce for a message you have no record of sending:

From: Mail Delivery System <MAILER-DAEMON@mx.example.net>
To: <you@your-domain.example>
Subject: Undelivered Mail Returned to Sender
Auto-Submitted: auto-replied

This is the mail system at host mx.example.net.

I'm sorry to have to inform you that your message could not be
delivered to one or more recipients.

<nonexistent@example.net>: host mx.example.net said:
    550 5.1.1 <nonexistent@example.net>: Recipient address rejected:
    User unknown in local recipient table

Reporting-MTA: dns; mx.example.net
Final-Recipient: rfc822; nonexistent@example.net
Action: failed
Status: 5.1.1

Three signs distinguish it from a genuine bounce:

• The quoted original message is one you never sent, often addressed to someone you have never heard of.
• The Received: headers of the returned message show it originating from an IP address that is not yours.
• Volume. Genuine bounces trickle; backscatter arrives in waves of hundreds or thousands within a short period.

What should you do when you receive backscatter?

There is no way to stop other people’s servers from bouncing to you, so the response is filtering and, if the volume is sustained, damage control:

• Verify the returned message’s origin before assuming a compromise. If the Received: chain does not include your servers, nothing of yours has been breached — your domain has merely been forged.
• Publish SPF, and a DMARC policy. These do not stop the bounces directly, but they let receiving servers reject the forged mail before it is accepted, which removes the bounce at the source over time.
• Filter bounces against a list of messages you actually sent. Bounce address tag validation (BATV) does this by signing the envelope sender, so bounces for messages you never sent can be discarded automatically.
• Do not disable your postmaster@ or abuse@ mailboxes to escape the flood. Losing those channels costs you more than the backscatter does; see abuse desk.

How do you avoid emitting backscatter?

This matters more than receiving it, because a server that generates backscatter is itself sending unsolicited mail to innocent third parties — and gets listed for it.

• Reject unknown recipients during the SMTP session, at RCPT TO, with a 550. If the message is never accepted, no bounce is ever generated: the rejection is the sending server’s problem to report, not yours.
• Never accept-then-bounce for spam or virus verdicts. If a content scanner decides a message is spam after acceptance, discard or quarantine it. Bouncing it sends a notification to a sender who is almost certainly forged.
• Suppress auto-replies to bulk mail. Out-of-office responders should honour Auto-Submitted:, Precedence: bulk and List-* headers, and must never reply to a null envelope sender (<>).
• Check your relay configuration. A server accepting mail for domains it does not host will bounce all of it, to forged senders, at volume.

Backscatter and blacklisting

Backscatterer.org and comparable services list IP addresses observed sending bounces and auto-replies to addresses that never sent anything. Because the traffic they list is generated by ordinary misconfiguration rather than by malice, well-run servers do end up on it — usually because of an accept-then-bounce configuration or an over-eager auto-responder.

The fix is always configuration rather than a delisting request: reject at RCPT TO, stop bouncing spam verdicts, and the source of the listing disappears. See IP blacklisting for how listings and delisting generally work.