Backscatter and BATV

If your domain is receiving bounces for mail it never sent, or your own servers have been listed for sending such bounces, you are dealing with backscatter. As an ESP you face it from both sides: your MTAs must not generate it, and your return-path domains receive floods of it.

Backscatter is bounce traffic delivered to people who never sent the original message. It includes delivery status notifications (DSNs) and, by extension, autoresponders and challenge messages. Spammers and viruses forge real addresses into MAIL FROM. When the spam cannot be delivered, the bounce goes to the person whose address was forged. At the scale of a spam campaign, an innocent domain can receive a flood of misdirected non-delivery reports (NDRs), and the systems that send those bounces get blocklisted as sources of backscatter.

The cause: accept-then-bounce

A bounce is only misdirected if it is generated after the SMTP transaction has ended. The accepted practice follows from that:

• Reject during the SMTP transaction (with a 5xx) whenever you can. A rejection goes back over the live connection to the host that actually submitted the message. No new message is created, so a forged MAIL FROM address receives nothing. Any verdict you can reach before DATA completes, whether on an unknown recipient, policy, size or content, should be a rejection within the session.
• Accept-then-bounce means returning 250 and later generating a DSN to the MAIL FROM address. That creates a new message aimed at an address nobody has verified, and for forged mail that DSN is backscatter. The usual causes are gateways and store-and-forward relays that accept mail for backend servers without knowing the list of valid recipients ("accept all, bounce later"), spam and antivirus filters that run after acceptance and are set to "notify sender", and challenge-response systems.
• Several rules follow. Validate recipients at the edge (with a real-time check against the backend, or a synchronized list of recipients). If you must deal with spam after acceptance, discard or quarantine it, and never bounce it. Never send an automatic reply to mail that fails authentication. Any DSN you legitimately generate always uses MAIL FROM:<> (see DSNs).

Blocklisting for backscatter (Backscatterer.org and UCEPROTECT)

• The zone is ips.backscatterer.org. It lists IP addresses seen sending misdirected bounces, misdirected autoresponders, and sender callouts. Probes for sender address verification (SAV) are treated as abuse too.
• It is explicitly not a spam list ("It's a Backscatterer list!!!"). The recommended use is SAFE MODE: query it only when MAIL FROM is <> or postmaster, that is, only to filter traffic that looks like bounces, because listed IP addresses also send plenty of legitimate mail. Sites that query it for all mail cause the collateral damage its operators warn against.
• Historically, listings expire on their own after a period with no new detections (roughly four weeks), and a paid "express delisting" option exists, which is a controversial practice. The details of expiry and fees were not on the usage page consulted as a source. They are given here from the operator's widely documented policy, so verify the current terms before you advise anyone to pay for delisting. The fix is always the same: find and stop the accept-then-bounce or callout behavior, then let the listing expire.
• A listing has limited practical impact, since few large providers use the zone, and only in safe mode. It is still a reliable sign that your infrastructure is misconfigured.

BATV: Bounce Address Tag Validation

BATV lets a domain tell bounces of mail it really sent apart from bounces of forgeries, by signing the local parts of its own MAIL FROM addresses. It is specified in draft-levine-smtp-batv-01 (Levine, Crocker, Silberman, Finch; 2008-05-13, expired 2008-11-14). The draft was never published as an RFC, but many MTAs and appliances have implemented it since.

Meta-syntax and the prvs= scheme

The form of a tagged local part:

local-part = tag-type "=" tag-val "=" loc-core

The one defined scheme is prvs ("private signature", with a simple private key):

prvs=KDDDSSSSSS=jsmith@example.com
        │ │  └── SSSSSS: first 3 bytes (6 hex digits) of an HMAC-SHA1
        │ └───── DDD: low 3 digits of days-since-1970 (expiry anchor)
        └─────── K: single key-number digit (rotation)

• The HMAC input is K DDD <original MAIL FROM address>, keyed with a secret that the domain's outbound signers and inbound validators share.
• Outbound MTAs rewrite MAIL FROM:<jsmith@example.com> to the tagged form at the boundary of the administrative management domain (ADMD). They never tag the addresses of other domains. The From: header of the message is not touched: BATV works on the envelope only.
• Inbound MTAs, for mail addressed to a prvs= local part (in practice, traffic that looks like bounces), verify the HMAC and check that the day count is within the window. The draft requires a 7-day lifetime, to allow for delayed bounces. If the tag is valid, the MTA strips it (everything up to and including the second =) and delivers to loc-core. If a bounce has an invalid tag or none, the MTA rejects it during the SMTP session.
• The meta-syntax allows other schemes, including "public tagging" with public keys that third parties could verify. Only prvs was ever defined and deployed.

What BATV gives an ESP

• It stops floods of forged bounces. A DSN to your return-path domain with no tag, or a bad tag, is provably not a response to your mail, so you can reject it. This protects bounce processing from poisoning (fake bounces that suppress good addresses) and from floods of volume.
• It gives only weak protection against replay, by design, as the draft itself says. The HMAC is cut to 6 hexadecimal digits and the window is 7 days, which stops guessing but not a determined replay of a tagged address harvested recently. It does not protect against a change of content, and the protection exists only at the delivery domain (because the key is private), not along the path.

Operational problems (from the draft's deployment considerations)

BATV and VERP: complementary, and largely converged

An ESP that already uses VERP (a return path encoded for each recipient, for example bounce-c123-user=example.com@bounces.esp.com) gets most of the benefit of BATV if the VERP token includes an HMAC. Any inbound "bounce" whose local part does not decode to a real outbound send is rejected or dropped.

This approach, signed and validated VERP, is what most large ESPs actually run instead of literal prvs= tagging. It validates bounces against outbound sends and identifies the exact recipient and campaign. It also avoids the problems BATV causes with lists and whitelists, because the return-path domain is a dedicated bounce domain that no person corresponds with.

Current practice

1. Never send backscatter. Reject during the SMTP session, discard spam found after acceptance, make no SAV callouts, and send DSNs only from <>.
2. Validate inbound bounces against your own outbound mail, with signed VERP (or BATV where all of the domain's mail flows through one ADMD). Drop anything at a bounce address that cannot be verified before it reaches your suppression logic.
3. Authentication reduces the supply of forgeries. As more domains enforce DMARC, less forged mail is accepted in the first place, so less backscatter is generated toward those domains.
4. The structural fix is under development. DKIM2 routes DSNs back hop by hop along an authenticated chain of custody, which makes misdirected bounces impossible for mail that takes part. This is one of its explicit design goals. It is still at the draft stage, so do not rely on it yet.
5. If you are listed on ips.backscatterer.org, audit for accept-then-bounce paths and callouts, fix the source, then wait for the listing to expire. Treat the listing as a warning about your configuration rather than as a deliverability emergency.

Related articles

• Delivery Status Notifications, including the null-sender rule and parsing VERP
• Blocklists & Spamhaus
• DKIM2, on authenticated bounce routing