Subscription Bombing & Signup-Form Abuse

Subscription bombing (also "list bombing", "list-linking email bomb", "mail bombing") is a denial-of-service attack against an individual mailbox: attackers script bulk submissions of a victim's email address into thousands of unprotected web signup forms — newsletter subscriptions, forum registrations, store accounts, WordPress signups — so that the resulting flood of legitimate confirmation and welcome messages renders the inbox unusable. The messages come from benign, reputable senders, so spam filters largely pass them; the medium is the attack. M3AAWG describes the effect as "a DDoS attack against an individual mailbox."

This topic matters from three chairs:

• Victim / receiver — the flood buries critical mail; attackers increasingly use it to hide bank, account-takeover, and purchase notifications during fraud, extending the window before the victim notices.
• Form owner (ESP customer) — an unprotected form makes the sender an unwitting attack conduit, poisons the list with addresses that never asked to be there (including spam-trap submissions), and generates complaints and blocklistings.
• ESP / platform — during the August 2016 wave, Spamhaus listed the IP addresses of the largest sources of list-bomb mail, i.e., ESP sending IPs. Shared-pool ESPs carry blocklist risk for every customer form left unsecured. This is why signup-form security is platform policy, not customer preference.

Attack anatomy

• Vector: any publicly exposed web form that triggers an email to the submitted address. During the 2016 wave, roughly half the flood was not mailing-list confirmations at all but account signups at WordPress sites — those messages even contained new account credentials, making them unambiguously "legitimate."
• Tooling: aggregated lists of vulnerable form URLs plus scripting that submits addresses at speed. Sites such as mailbait.info consolidated vulnerable forms into a single action needing no registration or payment. ProPublica reported attack tools selling for $5 on hacking forums. In 2016 Spamhaus predicted commoditization as "Mail-bombing as a Service (MaaS)"; by 2018 Forcepoint researchers judged that prediction realized — attacks are untraceable, effective, inexpensive, and outsourceable to Dark Web mercenaries.
• Distribution: sources are globally distributed. In the Forcepoint/APWG case study a single 12-hour attack used 4,047 unique sending IPs across 87 countries (versus fewer than 5 countries in normal traffic), in ~33 languages — deliberate camouflage that defeats simple IP or sender blocking.
• Escalation history: first documented email bombs targeted governments (Langley AFB, 1997; Tamil Tigers flooding Sri Lankan embassies with 800 emails/day for 2 weeks, 1998). The modern list-linking wave began late 2015; early instances settled personal grudges, but criminals now use it to defeat security processes. As the highest-profile lists deployed anti-bot measures, attackers simply rolled on to less-defended forms — the internet's long tail of unmaintained Joomla/Wix/WordPress forms means relying on every form owner to fix their form will not end the attack class.

Canonical incidents

Incident	Details
August 12–14, 2016 wave (Spamhaus)	Bots created mailing-list subscription requests at >1,000/minute against 100+ .gov addresses; targets then expanded over the following months. Spamhaus's own account: first attack detected Aug 12; Spamhaus began listing the IPs of the largest list-bomb sources that weekend ("not something we did happily, but it was necessary"); Spamhaus itself was hit with a small attack Aug 19.
2016 wave, ESP-side numbers	22,000 signups at a single ESP targeting 3,000 different domains, sometimes >100 messages/minute to a single address. One company saw 9 addresses signed up over 9,000 times in two weeks → 81,000 confirmation emails. Brian Krebs received a new confirmation every 2–3 seconds. Word to the Wise was attacked after publishing about the subject.
August 2017, ProPublica	Journalist Julia Angwin and two colleagues targeted by hate groups; ProPublica's email was shut down for much of a day by automated signup of their addresses into "every sign-up form it can find."
January 16, 2018 (Forcepoint/APWG case study)	Single mailbox received 6,571 messages in ~12 hours (baseline: 5–27/day). 30 confirmations in the first 10 minutes; ~100 in the first hour; peak >800/hour in the third hour; sharp drop to 65 in hour 12. Onset and conclusion both abrupt — no ramp.

Why COI and CAPTCHA are each insufficient alone (Spamhaus analysis)

• Single opt-in (SOI) forms accept all submissions without verification — the worst case: the victim's address lands on the live list, and SOI spam continues arriving after the attack until the victim unsubscribes or blocks each sender individually. (Forcepoint observed foreign-language residue mail — coupons, sales announcements — continuing after the attack ended, the lingering artifact of SOI signups.)
• Confirmed opt-in (COI) keeps the address off the list, but during a bombing the confirmation volume alone is the weapon — many of the 2016 victim lists were already COI. COI's benefit is long-term (no ongoing mail after the flood subsides), "which is little comfort to an individual experiencing real-time distress and lost emails."
• CAPTCHA stops most bots at the point of submission — Spamhaus: "the single best thing that can be done to secure a form"; Google reCAPTCHA is free and "will foil most bots." But CAPTCHA adoption is nowhere near 100%, so from the recipient's perspective the ecosystem remains exploitable.
• Spamhaus's bottom line: use CAPTCHA plus COI on every subscription form. CAPTCHA protects the world from your form; COI protects your list from the attack's fallout.
• Dynamic mailto-based confirmation links (per Jakobsson & Menczer, 2003) can defeat simple scripts but add multi-step friction and still see negligible adoption.

Adoption is the structural weakness. None of these measures has achieved full deployment since being recommended in 2003. Small-footprint sites lack the technical wherewithal; anti-bot plugins exist but are not defaults; and commercial incentives push the other way — sites want unconstrained subscriber growth (Forcepoint cites MailChimp's 2017 decision to revert to single opt-in as the default as an example of commercially-influenced resistance). Old, unmaintained forms remain a standing threat inventory.

The M3AAWG recommendation (October 2017)

M3AAWG Recommendation on Web Form Signup Attacks (reference URL: m3aawg.org/WebFormAttacks) is a short position paper. Key points:

• Frames the attack (exploited since late 2015) as beyond the ability of individual senders, hosters, or receivers to solve alone.
• Call to action 1: all providers that generate mail in response to web form submissions should implement the form-signup signaling header (the IETF draft below) so receivers can identify floods of form-triggered mail.
• Call to action 2: all publicly exposed web forms should be protected against bulk/automated submission with standard human-vs-bot measures, i.e., CAPTCHA systems of various types.
• As of the October 2017 M3AAWG general meeting, a variety of companies were emitting the header and some receivers had incorporated it into protections; value scales with adoption.

The Form-Sub header (draft-levine-mailbomb-header) — expired IETF draft

Status: this is an individual-submission Internet-Draft, never adopted or published as an RFC. Latest version -02 (2019-11-26); expired 2020-05-29. As of this article's extraction (July 2026) it is inactive. It still matters as the mechanism M3AAWG endorsed and some senders shipped.

• Purpose: an MSA or initial MTA adds a Form-Sub: header to any message generated by a web form submission, carrying the (optionally partially redacted) IP address that submitted the form. Receivers correlate the IPs across the incoming flood, recognize the mail-flood pattern, and defer or reject.
• Syntax (semicolon-separated tag=value list; first tag must be the version):

Form-Sub: v=1; ip4=198.51.x.x
Form-Sub: v=1; ip6=2001:db8:x:x:x:x:x:x
Form-Sub: v=1; ip=none

ABNF sketch: fields =/ "Form-Sub:" FWS "v=1" *(FWS ";" FWS fsarg) CRLF with fsarg one of ip4=/ip6= (parts replaceable by x for redaction), ip=none when the submitting address cannot be determined, or extension tags (unknown tags ignored).

• The header should be included in the set of headers covered by any DKIM signature.
• Associated enhanced status code: X.7.28 — message rejected because it was detected as part of a mail flood of Form-Sub-bearing messages.
• Security/privacy considerations: IPs can be PII (hence partial redaction, which still allows correlation); the header discloses submitter origin and the status code discloses receiver defenses; adversaries adapt when they learn they are being detected.
• Known limitation (Forcepoint/APWG critique): efficacy is predicated on the submitting IP being (near-)identical across the flood. A distributed attack from a botnet or coordinated network of submitters obviates single-IP correlation. It also only works if all form-bearing sites adopt it — the small sites least likely to deploy CAPTCHA are equally unlikely to deploy the header.

Detection signatures of an attack in progress (APWG/Forcepoint research)

Houle & Pandey (Forcepoint Security Labs), A Layered Approach to Defending Against List-Linking Email Bombs, APWG eCrime 2018. They analyzed three months of email for 3,000 medium/large enterprises (10.7M messages) and validated detection heuristics that an ESP abuse desk or receiving system can reuse:

Time and volume

• Attacks are acute: sharp onset, volume apex within the first few hours, sustained 12–24-hour siege, then a precipitous (not tapering) drop. No slow incrementation.
• Recognizable patterns emerge in the first or second hour — early detection is feasible and critical.
• Per-user anomaly detection works; aggregate does not. Enterprise-level volume anomalies (≥100 SD single-day jumps over 7/30-day means) surfaced only 12 candidates, and business-app noise (Sharepoint, process logs, meeting invites — spikes up to several hundred SD) drowned real attacks. Per-user detection (daily volume ≥10 standard deviations above the user's 7-day mean) surfaced 32 mailboxes, of which 3 were genuine list-bombing victims (the rest were spam/notification accounts distinguishable by identical senders/subjects) — including three attacks previously unknown. Observed victim profiles: 0 emails/week → 3,262/hour; 20–30/day → 3,806 in one hour; <20/day → 1,381 in one hour.
• Attack-end heuristic: daily/hourly volume dropping to ≤3 SD above the pre-attack mean and staying there 3–5 days ⇒ stand down from defensive posture.

Content and metadata (confirmation mail is semantically uniform)

• Subject phrases in the case study: 44.8% began "Account details" (7% of those ending "(pending admin approval)"); +9% foreign-language variants of the same phrase ("Kontoinformationen," "Détails du compte," "Szczegóły konta"); 11% began "[" + forum/site name; 11% began "Welcome"; 4% contained "username and password."
• Sender localpart distribution is characteristic: info@, admin@, wordpress@, webmaster@, noreply@, support@, no-reply@, contact@, sales@, forum@ dominate. First 30 messages of the case-study attack included 4 from admin@ and 3 from nobody@ within 10 minutes — highly unusual for an end user.
• Geographic spread of sending MTAs (87 countries vs <5 baseline) and language spread (~33 languages, 74% English) are confirming signals. Top source ASNs were ordinary hosting providers (GoDaddy 653 msgs, 1&1 442, Gossamer Threads 237, DreamHost 216, OVH 196, Hetzner 190…), i.e., legitimate web properties worldwide — reinforcing that source blocking fails.

Recommended defense at the point of impact: layered per-user volume anomaly detection + phrasal pattern recognition, driving temporary throttling/aggressive dropping of confirmation-shaped mail for the targeted mailbox only — keeping the mailbox functional and avoiding draconian measures (blocklisting large mailing-list providers wholesale, disabling the target mailbox, dropping all marketing mail).

Defense checklist — form owner (ESP customer)

Defense	Notes
CAPTCHA / reCAPTCHA on every public form	The single most effective measure (Spamhaus). Free (reCAPTCHA); foils most bots. Applies to any form that triggers email — subscription, account creation, contact, comment.
Confirmed opt-in (COI)	Keeps bombed addresses off the live list; no click → no marketing mail. Does not stop the confirmation flood itself — pair with CAPTCHA. See Consent Methods.
Hidden honeypot field	Standard complement: a form field invisible to humans; any submission that fills it is a bot — drop silently. (Industry-standard practice; not from the primary sources above.)
Per-IP / per-session rate limiting	Bots submit at machine speed (2016: >1,000 signups/minute fleet-wide). Cap submissions per IP per time window.
Per-address throttling	Never send more than N confirmations to the same address per day; dedupe repeat signups (one victim address was signed up 9,000+ times).
Address validation at signup	Syntax + MX checks, typo/disposable-domain filtering — see List Hygiene.
Consent recordkeeping	Capture signup timestamp (UTC), channel, and submitting IP — required evidence when negotiating delisting (Blocklists & Spamhaus).
Turn off what you don't need	WordPress and similar platforms: disable open user registration if unused; install anti-bot plugins (they are not defaults).
Monitor signup velocity	Alert on abnormal signup rate, burst of foreign-domain addresses, or repeated identical addresses.

Defense checklist — ESP / platform

Defense	Notes
Fleet-wide signup anomaly detection	An attack rarely uses one customer's form; watch aggregate signup velocity per target address and per target domain across all customer forms (2016: one ESP saw 22K malicious signups across 3,000 target domains).
Mandate or default COI; secure hosted forms	Ship CAPTCHA-protected, rate-limited signup forms as the default; require COI for risky signups. Beware the commercial pull toward SOI defaults — that pull is exactly what keeps the attack class alive.
Emit the Form-Sub header (or successor signaling)	Per the M3AAWG recommendation; caveat its limits and its expired-draft status when advising.
Per-address suppression during attacks	When a target address is being bombed fleet-wide, suppress further confirmations to it and quarantine the signups.
Cross-industry cooperation	The 2016 cleanup worked because ESPs shared lists of bombed target addresses and attacking IPs (a Word to the Wise-hosted Slack channel coordinated it) and Spamhaus called the cleanup "quick and efficient in most cases." Maintain those channels and your blocklist relationships before you need them.
Push customers to secure self-hosted forms	Spamhaus explicitly expects ESPs to "proactively push their customers to secure their various online sign up forms" — make it onboarding policy and an enforcement trigger, not a suggestion.
Blocklist-risk awareness	Spamhaus listed source IPs during the 2016 wave. An unsecured customer form is a shared-pool liability; treat sustained form abuse like any other outbound abuse: throttle, isolate, suspend.
Receiver-side protection for hosted mailboxes	If you also host mailboxes, implement the per-user volume + phrasal detection above rather than blunt instruments.

Related articles

• Consent Methods — COI vs SOI risk profiles and consent recordkeeping.
• List Hygiene & Sunset Policies — signup-time validation.
• Blocklists & Spamhaus — what a listing means and how delisting works.
• Spam Traps — trap poisoning via unsecured forms.

---

Provenance: the Spamhaus article (originally published 2016-09-16 by "Lys Maltice" at spamhaus.org/news/article/734, later moved to the resource-hub URL) now 404s at both locations; content extracted from the Internet Archive capture of 2024-01-18. The M3AAWG recommendation was retrieved as the official PDF behind m3aawg.org/WebFormAttacks (October 2017, doc M3AAWG111). The Form-Sub details come from the full draft text at ietf.org/archive/id/draft-levine-mailbomb-header-02.txt.