Backscatter and BATV

Backscatter is bounce traffic (DSNs, and by extension autoresponders and challenge messages) delivered to people who never sent the original message. Spammers and viruses forge real addresses into MAIL FROM; when the spam is undeliverable, the bounce goes to the forgery victim. At campaign scale, an innocent domain can receive a flood of misdirected NDRs — and the systems emitting those bounces get blocklisted as backscatter sources. An ESP sits on both sides: its MTAs must not generate backscatter, and its return-path domains absorb forged-bounce floods.

The cause: accept-then-bounce

A bounce is only misdirected if it is generated after the SMTP transaction ended. The doctrine:

• Reject at SMTP time (5xx during the transaction) whenever possible. A rejection is returned inside the live connection to the actual submitting host; no new message is created, so a forged MAIL FROM receives nothing. Unknown recipient, policy, size, and content verdicts you can reach before DATA completes should all be synchronous rejections.
• Accept-then-bounce — returning 250, then later generating a DSN to MAIL FROM — creates a new message aimed at an unverified address. For forged mail, that DSN is backscatter. Common culprits: gateways/store-and-forward relays that accept for backend servers without knowing the valid recipient list ("accept all, bounce later"), post-acceptance spam/AV filters configured to "notify sender", and challenge–response systems.
• Corollaries: do recipient validation at the edge (real-time callforward to the backend, or a synced recipient list); if you must quarantine post-acceptance spam, discard or quarantine — never bounce it; never auto-respond to mail that fails authentication; and DSNs you do legitimately generate always use MAIL FROM:<> (see DSNs).

Backscatter blocklisting (Backscatterer.org / UCEPROTECT)

• Zone: ips.backscatterer.org. Lists IPs observed sending misdirected bounces, misdirected autoresponders, and sender callouts (SAV — "sender address verification" probes are treated as abuse too).
• It is explicitly not a spam list ("It's a Backscatterer list!!!"). Recommended use is SAFE MODE: query it only when MAIL FROM is <> or postmaster — i.e., only to filter bounce-shaped traffic — because listed IPs also emit plenty of legitimate mail. (Sites that query it for all mail cause the collateral damage the operators warn against.)
• Historically, listings age out on their own after a period without new detections (roughly four weeks), with a paid "express delisting" option — a controversial practice; provenance note: expiry/fee specifics were not on the fetched usage page and are stated here from the operator's widely documented policy, so verify current terms before advising a delisting spend. The operational fix is always the same: find and stop the accept-then-bounce or callout behavior, then let the listing expire.
• Practical impact of a listing is limited (few large providers use the zone, and only in safe mode), but it is a reliable symptom that your infrastructure is misconfigured.

BATV: Bounce Address Tag Validation

BATV lets a domain distinguish bounces to mail it actually sent from bounces to forgeries, by signing its own MAIL FROM local-parts. Specified in draft-levine-smtp-batv-01 (Levine, Crocker, Silberman, Finch; 2008-05-13, expired 2008-11-14 — never published as an RFC, but deployed in numerous MTAs and appliances since).

Meta-syntax and the prvs= scheme

Tagged local-part form:

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

The defined scheme is prvs ("private signature" / 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)

• HMAC input: K DDD <original MAIL FROM address>, keyed with a secret shared by the domain's outbound signers and inbound validators.
• Outbound MTAs rewrite MAIL FROM:<jsmith@example.com> to the tagged form at the ADMD boundary (never re-tag other domains' addresses). Message header From: is untouched — BATV operates on the envelope only.
• Inbound MTAs, on mail addressed to a prvs= local-part (which in practice means bounce-shaped traffic), verify the HMAC and the day-count window — the draft mandates a 7-day lifetime to accommodate delayed bounces. Valid → strip the tag (everything through the second =) and deliver to loc-core. Invalid or absent tag on a bounce → reject at SMTP time.
• The meta-syntax allows other schemes, including public-key "public tagging" verifiable by third parties; only prvs was ever defined/deployed.

What BATV buys an ESP

• Kills forged-bounce floods: an untagged or badly tagged DSN to your return-path domain is provably not a response to your mail — reject it. This protects bounce-processing pipelines from poisoning (fake bounces suppressing good addresses) and from volume floods.
• Weak replay protection only (by design — the draft says so): the 6-hex-digit truncated HMAC and 7-day window stop guessing, not determined replay of a recently harvested tagged address; no protection against content substitution; protection exists only at the delivery domain (private key), not along the path.

Operational problems (from the draft's deployment considerations)

Problem	Detail
Greylisting	Retried deliveries must present the same tagged MAIL FROM; tag must be computed per message, not per attempt, or greylisting defers forever.
Mailing lists	Lists that identify subscribers/posters by envelope sender see a different address whenever the day-count rolls — subscription and posting checks fail.
Challenge–response & whitelists	Sender-address whitelists and C/R systems treat each tag variant as a new sender — repeated challenges, broken allowlisting.
Duplicate detection / sorting	Systems keying on envelope sender treat variants as distinct addresses.
Split administration	If inbound and outbound MX are run by different parties (common in hosting), sharing the HMAC key is awkward; the draft's fallback (signing at the MUA) is impractical.
Address length	Tag adds 15 characters to the local-part; risks hitting the 64-octet local-part limit on already-long addresses.
Third-party senders	Anyone legitimately sending "from" your domain (an ESP, a partner) without your key produces untagged mail whose bounces you now reject — BATV must cover all legitimate origination points or exclude those streams.

BATV vs. VERP — complementary, and largely converged

An ESP already using VERP (per-recipient encoded return paths, e.g. bounce-c123-user=example.com@bounces.esp.com) gets most of BATV's benefit if the VERP token includes an HMAC: any inbound "bounce" whose local-part doesn't decode to a real outbound send is rejected or dropped. This — signed/validated VERP — is what most large ESPs actually run instead of literal prvs= tagging: it validates bounces against outbound sends, identifies the exact recipient/campaign, and avoids BATV's list/whitelist breakage because the return-path domain is a dedicated bounce domain no human corresponds with.

Modern posture

1. Never emit backscatter: reject at SMTP time; discard post-acceptance spam; no SAV callouts; DSNs from <> only.
2. Validate inbound bounces against your own outbound: signed VERP (or BATV where the domain's mail all flows through one ADMD); anything unverifiable at a bounce address is dropped before it reaches suppression logic.
3. Authentication reduces the forgery supply: widespread DMARC enforcement means less forged mail gets accepted in the first place, so less backscatter is generated toward enforcing domains.
4. The structural fix is in progress: DKIM2 routes DSNs hop-by-hop back along an authenticated chain of custody, making misdirected bounces impossible for participating mail — one of its explicit design goals. Draft-stage; do not rely on it yet.
5. If listed on ips.backscatterer.org: audit for accept-then-bounce paths and callouts, fix the source, then wait out the listing; treat it as a config smoke alarm rather than a deliverability emergency.

Related

• Delivery Status Notifications — the null-sender rule and VERP parsing
• Blocklists & Spamhaus — DNSBL mechanics generally
• DKIM2 — authenticated bounce routing (in-progress)