# Subscription Bombing & Signup-Form Abuse

> How mass fraudulent form signups weaponize confirmation email as a DoS against victim mailboxes, the detection signatures of an attack in progress, and the layered defenses form owners and ESPs must run.

Source: emailmarketing.net — https://emailmarketing.net/learn/esp-operations/subscription-bombing

If a web form you run, or one hosted on your platform, sends email to whatever address is typed into it, attackers can use it to flood someone else's mailbox.

Subscription bombing (also called "list bombing", "list-linking email bomb" or "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. The resulting flood of legitimate confirmation and welcome messages makes the inbox unusable.

The messages come from harmless, reputable senders, so spam filters mostly let them through: the medium is the attack. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) describes the effect as "a DDoS attack against an individual mailbox."

The attack matters from three points of view:

- **Victim or receiver**: the flood buries important mail. Attackers increasingly use it during fraud to hide notifications about bank activity, account takeovers and purchases, which gives them longer before the victim notices.
- **Form owner (a customer of an email service provider, or ESP)**: an unprotected form makes the sender an unwitting channel for the attack. It poisons the list with addresses that never asked to be there (including [spam-trap](https://emailmarketing.net/learn/reference/spam-traps) submissions), and it generates complaints and blocklistings.
- **ESP or platform**: during the August 2016 wave, Spamhaus listed the IP addresses of the largest sources of list-bomb mail, which were the sending IP addresses of ESPs. ESPs with shared pools carry blocklist risk for every customer form left unsecured. This is why signup form security is a platform policy, not a 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, which made them unambiguously "legitimate."
- **Tooling**: collected lists of vulnerable form URLs, plus scripts that submit addresses at speed. Sites such as mailbait.info combined vulnerable forms into a single action that needed no registration or payment. ProPublica reported attack tools selling for **$5 on hacking forums**. In 2016 Spamhaus predicted that the attack would become a commodity, **"Mail-bombing as a Service (MaaS)"**. By 2018, Forcepoint researchers judged that the prediction had come true: attacks are untraceable, effective and inexpensive, and can be outsourced to mercenaries on the Dark Web.
- **Distribution**: sources are spread around the world. In the case study by Forcepoint and the Anti-Phishing Working Group (APWG), a single 12-hour attack used **4,047 unique sending IPs** in **87 countries** (compared with fewer than 5 countries in normal traffic), in about 33 languages. This is deliberate camouflage, and it defeats simple blocking by IP address or by sender.
- **History of escalation**: the first documented email bombs targeted governments (Langley AFB in 1997; in 1998, the Tamil Tigers flooded Sri Lankan embassies with 800 emails a day for 2 weeks). The modern wave of list linking began in late 2015. Early instances settled personal grudges, but criminals now use the technique to defeat security processes. As the highest-profile lists deployed anti-bot measures, attackers simply moved on to less defended forms. The internet's long tail of unmaintained Joomla, Wix and WordPress forms means that relying on every form owner to fix their form will not end this class of attack.

## Canonical incidents

| Incident | Details |
|---|---|
| August 12–14, 2016 wave (Spamhaus) | Bots created mailing list subscription requests at **more than 1,000 per minute** against **100+ .gov addresses**, and the targets expanded over the following months. In Spamhaus's own account, the first attack was detected on Aug 12, and Spamhaus began listing the IP addresses 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 on Aug 19. |
| 2016 wave, numbers from ESPs | **22,000 signups at a single ESP**, targeting 3,000 different domains, sometimes at more than 100 messages per minute to a single address. One company saw **9 addresses signed up over 9,000 times in two weeks, which produced 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 | Hate groups targeted the journalist Julia Angwin and two colleagues. ProPublica's email was shut down for much of a day by the automated signup of their addresses to "every sign-up form it can find." |
| January 16, 2018 (Forcepoint and APWG case study) | A single mailbox received **6,571 messages in about 12 hours** (its baseline was 5–27 a day). There were 30 confirmations in the first 10 minutes, about 100 in the first hour, a peak of **more than 800 per hour in the third hour**, and a sharp drop to 65 in hour 12. Both the start and the end were abrupt, with no ramp. |

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

- **Single opt-in (SOI)** forms accept every submission without verification. This is the worst case: the victim's address lands on the live list, and SOI mail keeps arriving after the attack until the victim unsubscribes or blocks each sender one by one. Forcepoint observed leftover mail in foreign languages (coupons, sales announcements) that continued after the attack ended, the lasting trace of SOI signups.
- **Confirmed opt-in (COI)** keeps the address off the list, but during a bombing the **volume of confirmations is itself the weapon**. Many of the victim lists in 2016 were already COI. The benefit of COI is long-term (no further 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 calls it "the single best thing that can be done to secure a form", and Google reCAPTCHA is free and "will foil most bots." But CAPTCHA adoption is nowhere near 100%, so for recipients the ecosystem remains exploitable.
- **Spamhaus's conclusion is to use CAPTCHA and COI together** on every subscription form. CAPTCHA protects the world from your form, and COI protects your list from the consequences of the attack.
- Dynamic confirmation links based on mailto (Jakobsson and Menczer, 2003) can defeat simple scripts, but they add friction in several steps, and their adoption is still negligible.

**Adoption is the structural weakness.** None of these measures has been fully deployed since they were recommended in 2003. Small sites lack the technical means. Anti-bot plugins exist, but they are not enabled by default. And commercial incentives push the other way, because sites want unconstrained subscriber growth. Forcepoint cites MailChimp's decision in 2017 to go back to single opt-in as the default as an example of resistance influenced by commercial interests. Old, unmaintained forms remain a standing stock of threats.

## The M3AAWG recommendation (October 2017)

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

- It frames the attack (exploited since late 2015) as beyond the ability of individual senders, hosting providers or receivers to solve alone.
- **Call to action 1**: all providers that generate mail in response to web form submissions should implement the header that signals form signups (the IETF draft below), so that receivers can identify floods of mail triggered by forms.
- **Call to action 2**: all publicly exposed web forms should be protected against bulk or automated submission with standard measures that tell humans from bots, such as CAPTCHA systems of various types.
- As of the M3AAWG general meeting in October 2017, a variety of companies were emitting the header, and some receivers had built it into their protections. Its value grows with adoption.

## The M3AAWG Sender BCP defenses (August 2026)

M3AAWG's *Sender Best Common Practices* (Version 4.0, August 2026, section 4.2, "List Bombing") returns to the attack. It notes that one form is rarely abused much on its own: the harm comes from the same address being submitted to hundreds of sites at once, which is why a single company finds it hard to see that it is part of the problem. Its advice is to combine several defenses, because a form protected in several ways is harder to recruit into an attack. It lists ten, and says the list is not exhaustive: CAPTCHA, limits on which systems can submit to the backend, rate limits per IP address, watching for one address across several forms, regional limits, a hidden honeypot field, a minimum completion time, unusual field names, moving an attacked form, and the Form-Sub header. The checklists below include each of them.

## The Form-Sub header (draft-levine-mailbomb-header): an expired IETF draft

**Status: this is an Internet-Draft submitted by an individual, never adopted or published as an RFC. The latest version is -02 (2019-11-26), and it expired on 2020-05-29. As of July 2026, when this information was extracted, it is inactive.** It still matters as the mechanism M3AAWG endorsed and some senders shipped. M3AAWG still points to it: its *Sender Best Common Practices* (Version 4.0, August 2026, section 4.2) ends its list of form defenses by suggesting that senders consider emitting the header for the mailbox providers that receive the mail, and links to version -02 of the draft.

- **Purpose**: a mail submission agent (MSA) or the first mail transfer agent (MTA) adds a `Form-Sub:` header to any message generated by a web form submission. The header carries the IP address that submitted the form, optionally partly redacted. Receivers correlate the IP addresses across the incoming flood, recognize the pattern of a mail flood, and defer or reject the mail.
- **Syntax** (a list of tag=value pairs separated by semicolons; the 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`, where `fsarg` is one of `ip4=` or `ip6=` (parts can be replaced by `x` for redaction), `ip=none` when the submitting address cannot be determined, or an extension tag (unknown tags are ignored).
- The header should be included in the set of headers covered by any DKIM signature.
- **Associated enhanced status code**: `X.7.28`, meaning that the message was rejected because it was detected as part of a flood of messages carrying Form-Sub.
- **Security and privacy considerations**: IP addresses can be personally identifiable information (PII), hence partial redaction, which still allows correlation. The header discloses where the submitter is, and the status code discloses the receiver's defenses. Adversaries adapt when they learn they are being detected.
- **Known limitation** (a criticism by Forcepoint and APWG): the header is only effective if the submitting IP is identical or nearly identical across the flood. A distributed attack from a botnet or a coordinated network of submitters makes correlation on a single IP useless. It also only works if every site with a form adopts it, and the small sites least likely to deploy CAPTCHA are just as unlikely to deploy the header.

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

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

**Time and volume**
- Attacks are acute: a sharp start, peak volume within the first few hours, a sustained siege of 12–24 hours, and then a steep drop rather than a tapering one. Volume does not build up slowly.
- Recognizable patterns emerge in the **first or second hour**, so early detection is both feasible and critical.
- **Anomaly detection for each user works; aggregate detection does not.** Volume anomalies at the level of the enterprise (single-day jumps of at least 100 standard deviations (SD) above the 7-day and 30-day means) surfaced only 12 candidates, and noise from business applications (SharePoint, process logs, meeting invitations, with spikes of up to several hundred SD) drowned out real attacks. Detection for each user (**daily volume at least 10 standard deviations above the user's 7-day mean**) surfaced 32 mailboxes. Of those, 3 were genuine list-bombing victims, and they included three attacks that were previously unknown. The rest were spam or notification accounts, recognizable by identical senders and subjects. Observed victim profiles: from 0 emails a week to 3,262 an hour; from 20–30 a day to 3,806 in one hour; from under 20 a day to 1,381 in one hour.
- **Heuristic for the end of an attack**: when daily or hourly volume falls to no more than 3 SD above the mean before the attack, and stays there for 3–5 days, stand down from the defensive posture.

**Content and metadata (confirmation mail is uniform in meaning)**
- Subject phrases in the case study: **44.8% began with "Account details"** (7% of those ended with "(pending admin approval)"). Another 9% were foreign-language versions of the same phrase ("Kontoinformationen," "Détails du compte," "Szczegóły konta"). Of the rest, 11% began with "[" followed by a forum or site name, 11% began with "Welcome", and 4% contained "username and password."
- The distribution of sender local parts is characteristic: `info@`, `admin@`, `wordpress@`, `webmaster@`, `noreply@`, `support@`, `no-reply@`, `contact@`, `sales@` and `forum@` dominate. The first 30 messages of the case-study attack included 4 from `admin@` and 3 from `nobody@` within 10 minutes, which is highly unusual for an end user.
- The geographic spread of the sending MTAs (87 countries, compared with a baseline under 5) and the spread of languages (about 33 languages, 74% English) are confirming signals. The top source networks (by autonomous system number, ASN) were ordinary hosting providers (GoDaddy 653 messages, 1&1 442, Gossamer Threads 237, DreamHost 216, OVH 196, Hetzner 190, and others), that is, legitimate websites around the world. This confirms that blocking by source fails.

**Recommended defense at the point of impact**: combine anomaly detection on each user's volume with recognition of phrase patterns, and use them to trigger temporary throttling, or aggressive dropping, of mail that looks like confirmations, for the targeted mailbox only. This keeps the mailbox working and avoids draconian measures such as blocklisting large mailing list providers wholesale, disabling the targeted mailbox, or dropping all marketing mail.

## Defense checklist for form owners (ESP customers)

| Defense | Notes |
|---|---|
| CAPTCHA or reCAPTCHA on every public form | The single most effective measure (Spamhaus). Free (reCAPTCHA), and 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; without a click, no marketing mail is sent. It does not stop the flood of confirmations itself, so pair it with CAPTCHA. M3AAWG's Sender BCP (section 4.1) ranks it as the best opt-in level, says the confirmation message should be simple and free of advertising, and says a changed email address should be confirmed the same way. See [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods). |
| Hidden honeypot field | A standard complement: a form field that humans cannot see. Any submission that fills it in comes from a bot, so drop it silently. M3AAWG's *Sender Best Common Practices* (Version 4.0, August 2026, section 4.2) now lists it: for example, a visible email field and a hidden one, rejecting any submission that fills in both. |
| Minimum completion time | Record when the page loaded, or issue a key with it. Discard a submission that arrives faster than a person could fill in the form, or that has no timestamp at all (M3AAWG Sender BCP, section 4.2). |
| Unusual field names | Name fields something other than the usual `firstname` and `email`, because submission scripts look for common names (M3AAWG Sender BCP, section 4.2). |
| Restrict who can submit to your backend | Accept form submissions only from your own web servers, so that a script cannot map the form and post to your database directly (M3AAWG Sender BCP, section 4.2). |
| Move an attacked form | If a form has been attacked, change its URL, for example from `/signup` to `/signup1` (M3AAWG Sender BCP, section 4.2). |
| Limit a regional form to its region | A provider that serves only one region might show the form only to IP addresses in that region (M3AAWG Sender BCP, section 4.2). |
| Rate limiting per IP address or per session | Bots submit at machine speed (in 2016, more than 1,000 signups per minute across the fleet). Cap submissions per IP address in each time window. |
| Throttling per address | Never send more than N confirmations a day to the same address, and deduplicate repeat signups (one victim address was signed up 9,000+ times). |
| Address validation at signup | Syntax and MX checks, and filtering of typo and disposable domains. See [List Hygiene](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies). |
| Consent record keeping | Capture the signup timestamp (UTC), the channel and the submitting IP address. This is required evidence when you negotiate a delisting ([Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)). |
| Turn off what you do not need | On WordPress and similar platforms, disable open user registration if you do not use it, and install anti-bot plugins (they are not enabled by default). |
| Monitor signup velocity | Alert on an abnormal signup rate, a burst of addresses at foreign domains, or repeated identical addresses. |

## Defense checklist for ESPs and platforms

| Defense | Notes |
|---|---|
| Signup anomaly detection across the whole platform | An attack rarely uses a single customer's form. Watch the aggregate signup velocity per target address and per target domain across all customer forms (in 2016, one ESP saw 22K malicious signups across 3,000 target domains). M3AAWG's Sender BCP (section 2.7) names two signup-form checks: subscription volume per customer, to catch spikes, and one address subscribed across several accounts. Section 4.2 adds that a sender or ESP hosting several forms should watch for the same address added to different forms. |
| Require COI or make it the default; secure hosted forms | Ship signup forms protected by CAPTCHA and rate limits as the default, and require COI for risky signups. Beware the commercial pull toward SOI defaults, which is exactly what keeps this class of attack alive. |
| Emit the Form-Sub header (or a successor signal) | As the M3AAWG recommendation advises. When you advise customers, mention its limits and that the draft has expired. |
| Suppression per address during attacks | When a target address is being bombed across the platform, suppress further confirmations to it and quarantine the signups. |
| Cooperation across the industry | The 2016 cleanup worked because ESPs shared lists of bombed target addresses and attacking IP addresses (coordinated in a Slack channel hosted by Word to the Wise), 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 the forms they host themselves | Spamhaus explicitly expects ESPs to "proactively push their customers to secure their various online sign up forms". Make it an onboarding policy and a trigger for enforcement, not a suggestion. |
| Awareness of blocklist risk | Spamhaus listed source IP addresses during the 2016 wave. An unsecured customer form is a liability for the shared pool, so treat sustained form abuse like any other outbound abuse: throttle, isolate, suspend. |
| Protection for hosted mailboxes on the receiving side | If you also host mailboxes, implement the detection described above, on each user's volume and on phrases, rather than blunt instruments. |

## Related articles

- [Consent Methods](https://emailmarketing.net/learn/list-management/consent-methods)
- [List Hygiene and Sunset Policies](https://emailmarketing.net/learn/operations/list-hygiene-and-sunset-policies), including validation at signup
- [Blocklists and Spamhaus](https://emailmarketing.net/learn/reference/blocklists-and-spamhaus)
- [Spam Traps](https://emailmarketing.net/learn/reference/spam-traps), including trap poisoning through unsecured forms

---

**Sources.** The Spamhaus article was originally published on 2016-09-16 by "Lys Maltice" at spamhaus.org/news/article/734, and later moved to the resource-hub URL. It now returns 404 at both locations, and its content was 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, document M3AAWG111). The Form-Sub details come from the full text of the draft at ietf.org/archive/id/draft-levine-mailbomb-header-02.txt.