From 77085ce7b2c0418120677fe1689256afeecc110e Mon Sep 17 00:00:00 2001 From: Andrew Marder Date: Wed, 24 Jun 2026 22:46:08 +0000 Subject: [PATCH 1/4] AI wrote first draft of ghost spam post --- src/content/post/{ghost.md => ghost/index.md} | 0 src/content/post/ghost/spam/index.md | 74 +++++++++++++++++++ 2 files changed, 74 insertions(+) rename src/content/post/{ghost.md => ghost/index.md} (100%) create mode 100644 src/content/post/ghost/spam/index.md diff --git a/src/content/post/ghost.md b/src/content/post/ghost/index.md similarity index 100% rename from src/content/post/ghost.md rename to src/content/post/ghost/index.md diff --git a/src/content/post/ghost/spam/index.md b/src/content/post/ghost/spam/index.md new file mode 100644 index 00000000..19fad30c --- /dev/null +++ b/src/content/post/ghost/spam/index.md @@ -0,0 +1,74 @@ +--- +title: "Newsletter Spam" +publishDate: "2026-06-24" +description: "A summary of newsletter bombing and fake Ghost subscriber signups — what it is, why it happens, and how to mitigate it." +--- + +Ghost newsletter signups are being abused at scale. Small blogs with almost no traffic suddenly accumulate subscribers from corporate email addresses who immediately open and click every link when a post goes out. This is not organic growth — it is automated abuse that harms both the blog owner and the people whose addresses were signed up without consent. + +## 1. What is the problem? + +There are two overlapping abuse patterns, both targeting Ghost's `/members/api/send-magic-link/` signup endpoint. Ghost rate-limits this endpoint, which helps a little, but there is no CAPTCHA or other bot challenge — and distributed bots rotating IPs can still overwhelm a single-site limit over time. + +**Newsletter bombing (list bombing).** Bots submit someone else's email address to hundreds or thousands of newsletter signup forms in minutes. The victim's inbox floods with "Confirm your subscription" emails, burying a single legitimate security alert — a password change, suspicious login, or wire transfer — that the attacker needs the victim to miss. Your blog is not the target; it is ammunition. Each signup form contributes one or two confirmation emails to someone else's catastrophe. + +**Email validation for phishing.** A separate but related pattern: bots sign up random email addresses and observe whether the address converts to a confirmed member. Attackers often try the login flow first (`No member exists`), then submit a signup for the same address. If the victim clicks the confirmation link, the attacker learns the address is active and that the owner clicks links in email — valuable intelligence for targeted phishing. Some signups never confirm; others do, because corporate email security appliances automatically visit every link in inbound mail. + +That last mechanism explains the most confusing symptom: **confirmed subscribers who never read your content but click everything instantly.** Platforms like Proofpoint, Mimecast, Barracuda, and Microsoft Safe Links pre-fetch links in email before a human sees them. A GET request to a magic-link confirmation URL looks identical to an enthusiastic new reader. Security scanners generate opens and clicks, so engagement metrics are not proof of a real person. + +The collateral damage for blog owners is real: + +- Unwanted confirmation emails sent to strangers, some of whom report them as spam +- Inflated member lists full of corporate addresses unrelated to your topic +- Damaged sender reputation and deliverability if abuse volume is high enough +- In the bombing scenario, you are unknowingly spamming victims whose inboxes you helped flood + +Ghost Explore and other public directories make it easy for bots to collect Ghost site URLs, but the underlying issue is an easily abused signup API with only partial protection — not discovery alone. + +## 2. Who is doing this / why are they doing it? + +The actors are automated bots operating at scale, not individual people interested in your writing. Traffic comes from Tor exit nodes, VPNs, residential IPs, data-center ASNs, and increasingly headless browsers that load pages like real visitors. Infrastructure rotates quickly — block one region or ASN and the same behavior reappears elsewhere the same day. + +Motivations fall into three categories: + +1. **Newsletter bombing** — hide a critical security email in a flood of subscription confirmations during account takeover or fraud. +2. **Email list building for phishing** — confirm which addresses are active and which owners click links, then target them. +3. **Sender reputation attack (secondary)** — if enough unwanted mail from your domain gets marked as spam, your newsletter deliverability can tank as collateral damage. + +The corporate email addresses appearing on your member list — law firms, airports, accounts receivable departments, Fortune 500 executives — are almost certainly **victims**, not readers. The attacker collected or guessed their addresses and used your signup form as a delivery mechanism. Blocking those domains does little; the domains belong to innocent third parties. + +## 3. How can the problem be addressed? + +There is no single platform-level fix yet. Ghost's built-in rate limiting on the magic-link endpoint is a start but not enough on its own against coordinated, IP-rotating automation. Community mitigations are layered and imperfect. What actually helps depends on whether you self-host and what infrastructure you control. + +### Stop bots before email is sent + +This is the only approach that helps both you and the bombing victim, because the harm happens at send time, not confirm time. + +- **CAPTCHA or Cloudflare Turnstile** on the signup path — a managed challenge on `/members/api/send-magic-link/` stops automated submission cold. +- **Cloudflare WAF** — block Tor exit nodes (country code `T1`); many hosts report this blocked the initial wave. +- **`verifyRequestIntegrity: true`** in Ghost config — forces callers to obtain an integrity token before hitting the magic-link endpoint, raising the cost of direct API abuse. +- **Additional rate limiting** at the reverse proxy (Traefik, Caddy, Nginx) on the signup endpoint — tighter than Ghost's defaults, e.g. a few POSTs per hour per IP. Useful when bots stay under Ghost's limit by spreading requests across addresses or timing. +- **Prevent CDN bypass** — bots may hit your origin IP directly, skipping Cloudflare entirely. Restrict ports 80/443 to Cloudflare IP ranges, use a Cloudflare Tunnel, or set `hostSettings.siteId` and require a matching `x-site-id` header injected by a Cloudflare transform rule so direct-to-origin requests fail. + +### Fix the confirmation flow + +Changing confirmation from a one-click GET magic link to a page with a button (or one-time code entered in the same browser session) prevents security scanners from auto-confirming subscriptions. This cleans up your list but **does not stop confirmation emails from being sent** in the first place — you still need a signup challenge for that. + +Ghost 6.17+ reduced information leakage on login (no longer revealing whether an email is already a member), which may discourage email-validation attacks over time if that was the primary motive. Reports suggest abuse continued after that release. + +### Operational responses + +- **Go invite-only** — ends abuse immediately at the cost of organic signups. Several affected bloggers chose this, including manually vetting subscribers via email. +- **Watch and prune** — remove suspicious members: corporate domains unrelated to your audience, zero plausible engagement, signups that cluster in time. Back up rows before bulk delete. Whitelist yourself and known real readers first — corporate-domain filters can catch your own admin address. +- **Do not trust opens/clicks as proof of humanity** — security appliances generate both. +- **Separate transactional and newsletter email** — if signup abuse tarnishes transactional SMTP reputation, keep newsletter sending on a provider whose reputation you cannot afford to lose. +- **Monitor bounces and complaints** — set up webhooks from your mail provider; Mailgun does not always alert proactively when failure rates spike. + +### What Ghost still needs + +Community consensus is that this should be a **platform concern**: stronger bot protection beyond the existing endpoint rate limit, optional manual signup approval, and one-time codes instead of magic links for signup confirmation. Until then, running an open signup form means periodically escorting fake Fortune 500 CEOs off your member list — and accepting that you may have been an unwitting participant in someone else's inbox attack. + +--- + +Sources: [Reddit r/Ghost discussion](https://www.reddit.com/r/Ghost/), [pro-it.rocks field guide to newsletter bombing](https://pro-it.rocks/why-a-fortune-500-ceo-just-subscribed-to-my-blog-about-a-40-year-old-unix-spoiler-they-did-not/), [Ghost forum — Observations about spam signups](https://forum.ghost.org/t/observations-about-spam-signups/). From d01f20212e10d02aadba761adf07f7824f691c10 Mon Sep 17 00:00:00 2001 From: Andrew Marder Date: Wed, 24 Jun 2026 22:49:38 +0000 Subject: [PATCH 2/4] AI slims down the post --- src/content/post/ghost/spam/index.md | 63 ++++++++-------------------- 1 file changed, 18 insertions(+), 45 deletions(-) diff --git a/src/content/post/ghost/spam/index.md b/src/content/post/ghost/spam/index.md index 19fad30c..48508860 100644 --- a/src/content/post/ghost/spam/index.md +++ b/src/content/post/ghost/spam/index.md @@ -4,70 +4,43 @@ publishDate: "2026-06-24" description: "A summary of newsletter bombing and fake Ghost subscriber signups — what it is, why it happens, and how to mitigate it." --- -Ghost newsletter signups are being abused at scale. Small blogs with almost no traffic suddenly accumulate subscribers from corporate email addresses who immediately open and click every link when a post goes out. This is not organic growth — it is automated abuse that harms both the blog owner and the people whose addresses were signed up without consent. +Small Ghost blogs with almost no traffic suddenly gain subscribers from corporate email addresses who instantly open and click every link when a post goes out. This is automated abuse — not organic growth — and it harms both the blog owner and the people signed up without consent. ## 1. What is the problem? -There are two overlapping abuse patterns, both targeting Ghost's `/members/api/send-magic-link/` signup endpoint. Ghost rate-limits this endpoint, which helps a little, but there is no CAPTCHA or other bot challenge — and distributed bots rotating IPs can still overwhelm a single-site limit over time. +Two overlapping patterns target Ghost's `/members/api/send-magic-link/` endpoint. Ghost rate-limits it, which helps a little, but there is no CAPTCHA — and bots rotating IPs can still abuse it at scale. -**Newsletter bombing (list bombing).** Bots submit someone else's email address to hundreds or thousands of newsletter signup forms in minutes. The victim's inbox floods with "Confirm your subscription" emails, burying a single legitimate security alert — a password change, suspicious login, or wire transfer — that the attacker needs the victim to miss. Your blog is not the target; it is ammunition. Each signup form contributes one or two confirmation emails to someone else's catastrophe. +**Newsletter bombing.** Bots sign a victim's address up to hundreds of newsletters at once, flooding their inbox with confirmation emails to bury a real security alert (password change, suspicious login, wire transfer). Your blog is ammunition, not the target. -**Email validation for phishing.** A separate but related pattern: bots sign up random email addresses and observe whether the address converts to a confirmed member. Attackers often try the login flow first (`No member exists`), then submit a signup for the same address. If the victim clicks the confirmation link, the attacker learns the address is active and that the owner clicks links in email — valuable intelligence for targeted phishing. Some signups never confirm; others do, because corporate email security appliances automatically visit every link in inbound mail. +**Email validation for phishing.** Bots sign up addresses and check whether they convert to confirmed members — often after probing the login flow first. Confirmed signups mean an active address that clicks email links: prime phishing targets. -That last mechanism explains the most confusing symptom: **confirmed subscribers who never read your content but click everything instantly.** Platforms like Proofpoint, Mimecast, Barracuda, and Microsoft Safe Links pre-fetch links in email before a human sees them. A GET request to a magic-link confirmation URL looks identical to an enthusiastic new reader. Security scanners generate opens and clicks, so engagement metrics are not proof of a real person. +The confusing symptom — **instant opens and clicks from "subscribers" who never read your content** — is often corporate email security (Proofpoint, Mimecast, Barracuda, Safe Links) pre-fetching magic-link confirmation URLs. Scanners look like engaged readers; opens and clicks are not proof of a real person. -The collateral damage for blog owners is real: - -- Unwanted confirmation emails sent to strangers, some of whom report them as spam -- Inflated member lists full of corporate addresses unrelated to your topic -- Damaged sender reputation and deliverability if abuse volume is high enough -- In the bombing scenario, you are unknowingly spamming victims whose inboxes you helped flood - -Ghost Explore and other public directories make it easy for bots to collect Ghost site URLs, but the underlying issue is an easily abused signup API with only partial protection — not discovery alone. +**Cost to you:** unwanted confirmation mail (and spam reports), inflated member lists, damaged sender reputation, and in bombing scenarios, unknowingly spamming victims. Ghost Explore makes site discovery easier, but the root issue is a signup API with only partial protection. ## 2. Who is doing this / why are they doing it? -The actors are automated bots operating at scale, not individual people interested in your writing. Traffic comes from Tor exit nodes, VPNs, residential IPs, data-center ASNs, and increasingly headless browsers that load pages like real visitors. Infrastructure rotates quickly — block one region or ASN and the same behavior reappears elsewhere the same day. - -Motivations fall into three categories: +Automated bots at scale — Tor, VPNs, residential IPs, data centers, headless browsers — with infrastructure that rotates faster than blocklists. Motives: hide fraud alerts (**newsletter bombing**), build validated phishing lists, and occasionally tank your sender reputation as collateral. -1. **Newsletter bombing** — hide a critical security email in a flood of subscription confirmations during account takeover or fraud. -2. **Email list building for phishing** — confirm which addresses are active and which owners click links, then target them. -3. **Sender reputation attack (secondary)** — if enough unwanted mail from your domain gets marked as spam, your newsletter deliverability can tank as collateral damage. - -The corporate email addresses appearing on your member list — law firms, airports, accounts receivable departments, Fortune 500 executives — are almost certainly **victims**, not readers. The attacker collected or guessed their addresses and used your signup form as a delivery mechanism. Blocking those domains does little; the domains belong to innocent third parties. +Corporate addresses on your list (law firms, airports, AR departments, executives) are almost certainly **victims**, not readers. Blocking those domains does little. ## 3. How can the problem be addressed? -There is no single platform-level fix yet. Ghost's built-in rate limiting on the magic-link endpoint is a start but not enough on its own against coordinated, IP-rotating automation. Community mitigations are layered and imperfect. What actually helps depends on whether you self-host and what infrastructure you control. - -### Stop bots before email is sent - -This is the only approach that helps both you and the bombing victim, because the harm happens at send time, not confirm time. - -- **CAPTCHA or Cloudflare Turnstile** on the signup path — a managed challenge on `/members/api/send-magic-link/` stops automated submission cold. -- **Cloudflare WAF** — block Tor exit nodes (country code `T1`); many hosts report this blocked the initial wave. -- **`verifyRequestIntegrity: true`** in Ghost config — forces callers to obtain an integrity token before hitting the magic-link endpoint, raising the cost of direct API abuse. -- **Additional rate limiting** at the reverse proxy (Traefik, Caddy, Nginx) on the signup endpoint — tighter than Ghost's defaults, e.g. a few POSTs per hour per IP. Useful when bots stay under Ghost's limit by spreading requests across addresses or timing. -- **Prevent CDN bypass** — bots may hit your origin IP directly, skipping Cloudflare entirely. Restrict ports 80/443 to Cloudflare IP ranges, use a Cloudflare Tunnel, or set `hostSettings.siteId` and require a matching `x-site-id` header injected by a Cloudflare transform rule so direct-to-origin requests fail. - -### Fix the confirmation flow - -Changing confirmation from a one-click GET magic link to a page with a button (or one-time code entered in the same browser session) prevents security scanners from auto-confirming subscriptions. This cleans up your list but **does not stop confirmation emails from being sent** in the first place — you still need a signup challenge for that. +No single fix exists. Ghost's built-in rate limit is a start; community mitigations are layered and imperfect. -Ghost 6.17+ reduced information leakage on login (no longer revealing whether an email is already a member), which may discourage email-validation attacks over time if that was the primary motive. Reports suggest abuse continued after that release. +**Stop bots before email is sent** — the only approach that also protects bombing victims (harm happens at send time): -### Operational responses +- CAPTCHA or Cloudflare Turnstile on the signup path +- Cloudflare WAF blocking Tor (`T1`) +- `verifyRequestIntegrity: true` in Ghost config +- Tighter rate limits at your reverse proxy (Traefik, Caddy, Nginx) +- Prevent CDN bypass: restrict origin to Cloudflare IPs, use a Tunnel, or set `hostSettings.siteId` with an `x-site-id` header via Cloudflare transform rules -- **Go invite-only** — ends abuse immediately at the cost of organic signups. Several affected bloggers chose this, including manually vetting subscribers via email. -- **Watch and prune** — remove suspicious members: corporate domains unrelated to your audience, zero plausible engagement, signups that cluster in time. Back up rows before bulk delete. Whitelist yourself and known real readers first — corporate-domain filters can catch your own admin address. -- **Do not trust opens/clicks as proof of humanity** — security appliances generate both. -- **Separate transactional and newsletter email** — if signup abuse tarnishes transactional SMTP reputation, keep newsletter sending on a provider whose reputation you cannot afford to lose. -- **Monitor bounces and complaints** — set up webhooks from your mail provider; Mailgun does not always alert proactively when failure rates spike. +**Fix confirmation flow:** replace one-click GET magic links with a confirm button or one-time code — stops scanners auto-confirming, but does not prevent emails from being sent. Ghost 6.17+ stopped leaking whether an email is already a member on login; abuse has continued regardless. -### What Ghost still needs +**Operational:** go invite-only; prune suspicious members (back up first, whitelist yourself); don't trust engagement metrics; separate transactional and newsletter SMTP; monitor bounces/complaints via webhooks. -Community consensus is that this should be a **platform concern**: stronger bot protection beyond the existing endpoint rate limit, optional manual signup approval, and one-time codes instead of magic links for signup confirmation. Until then, running an open signup form means periodically escorting fake Fortune 500 CEOs off your member list — and accepting that you may have been an unwitting participant in someone else's inbox attack. +Ghost still needs stronger platform-level bot protection, optional manual approval, and signup one-time codes. Until then, expect to periodically remove fake Fortune 500 CEOs from your list. --- From 00ad3851326edbebe2f5eada80532630d8b32fe0 Mon Sep 17 00:00:00 2001 From: Andrew Marder Date: Wed, 1 Jul 2026 10:05:31 +0000 Subject: [PATCH 3/4] Cleaned up the post a bit --- src/content/post/ghost/spam/index.md | 32 ++++++++++++++-------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/src/content/post/ghost/spam/index.md b/src/content/post/ghost/spam/index.md index 48508860..e1dcd7b4 100644 --- a/src/content/post/ghost/spam/index.md +++ b/src/content/post/ghost/spam/index.md @@ -1,30 +1,24 @@ --- -title: "Newsletter Spam" +title: "Ghost Spam Signups Suck" publishDate: "2026-06-24" description: "A summary of newsletter bombing and fake Ghost subscriber signups — what it is, why it happens, and how to mitigate it." --- -Small Ghost blogs with almost no traffic suddenly gain subscribers from corporate email addresses who instantly open and click every link when a post goes out. This is automated abuse — not organic growth — and it harms both the blog owner and the people signed up without consent. +Small Ghost blogs start gaining subscribers with corporate email addresses who instantly open and click every link when a post goes out. This is automated abuse — not organic growth — and it harms both the blog owner and the people signed up without consent. -## 1. What is the problem? +## the problem Two overlapping patterns target Ghost's `/members/api/send-magic-link/` endpoint. Ghost rate-limits it, which helps a little, but there is no CAPTCHA — and bots rotating IPs can still abuse it at scale. **Newsletter bombing.** Bots sign a victim's address up to hundreds of newsletters at once, flooding their inbox with confirmation emails to bury a real security alert (password change, suspicious login, wire transfer). Your blog is ammunition, not the target. -**Email validation for phishing.** Bots sign up addresses and check whether they convert to confirmed members — often after probing the login flow first. Confirmed signups mean an active address that clicks email links: prime phishing targets. +**Email validation for phishing.** Bots sign up addresses and check whether they convert to confirmed members — often after probing the login flow first. Confirmed signups mean an active address: prime phishing targets. The confusing symptom — **instant opens and clicks from "subscribers" who never read your content** — is often corporate email security (Proofpoint, Mimecast, Barracuda, Safe Links) pre-fetching magic-link confirmation URLs. Scanners look like engaged readers; opens and clicks are not proof of a real person. -**Cost to you:** unwanted confirmation mail (and spam reports), inflated member lists, damaged sender reputation, and in bombing scenarios, unknowingly spamming victims. Ghost Explore makes site discovery easier, but the root issue is a signup API with only partial protection. +**Cost to you:** inflated member lists, damaged sender reputation, and unknowingly spamming victims. Ghost Explore makes site discovery easier, but the root issue is a signup API with minimal protections. -## 2. Who is doing this / why are they doing it? - -Automated bots at scale — Tor, VPNs, residential IPs, data centers, headless browsers — with infrastructure that rotates faster than blocklists. Motives: hide fraud alerts (**newsletter bombing**), build validated phishing lists, and occasionally tank your sender reputation as collateral. - -Corporate addresses on your list (law firms, airports, AR departments, executives) are almost certainly **victims**, not readers. Blocking those domains does little. - -## 3. How can the problem be addressed? +## partial solutions No single fix exists. Ghost's built-in rate limit is a start; community mitigations are layered and imperfect. @@ -38,10 +32,16 @@ No single fix exists. Ghost's built-in rate limit is a start; community mitigati **Fix confirmation flow:** replace one-click GET magic links with a confirm button or one-time code — stops scanners auto-confirming, but does not prevent emails from being sent. Ghost 6.17+ stopped leaking whether an email is already a member on login; abuse has continued regardless. -**Operational:** go invite-only; prune suspicious members (back up first, whitelist yourself); don't trust engagement metrics; separate transactional and newsletter SMTP; monitor bounces/complaints via webhooks. +**Operational:** go invite-only; prune suspicious members; don't trust engagement metrics; separate transactional and newsletter SMTP; monitor bounces/complaints via webhooks. -Ghost still needs stronger platform-level bot protection, optional manual approval, and signup one-time codes. Until then, expect to periodically remove fake Fortune 500 CEOs from your list. +Ghost still needs stronger platform-level bot protection, optional manual approval, and signup one-time codes. Until then, expect to periodically remove corporate emails from your list. ---- +## my approach + +My newsletter is super small. I decided to take the nuclear option and go invite-only. When someone submits their email address to subscribe on my site, I get notified, I contact them manually to confirm that they do in fact want to subscribe, and then I personally add them to the subscriber list. This approach makes sense for me right now, because I didn't want to spend time playing a game of layered whack-a-mole. + +## references -Sources: [Reddit r/Ghost discussion](https://www.reddit.com/r/Ghost/), [pro-it.rocks field guide to newsletter bombing](https://pro-it.rocks/why-a-fortune-500-ceo-just-subscribed-to-my-blog-about-a-40-year-old-unix-spoiler-they-did-not/), [Ghost forum — Observations about spam signups](https://forum.ghost.org/t/observations-about-spam-signups/). +- [Magic Pages: How to stop spam signups on your Ghost membership site](https://www.magicpages.co/blog/how-to-stop-spam-signups-on-your-ghost-membership-site/) +- [Discussion on Reddit](https://www.reddit.com/r/Ghost/comments/1u99o59/fake_subscribers/) +- [Discussion on Ghost Forum](https://forum.ghost.org/t/observations-about-spam-signups/61475) From 3c939b0a2c2764a5a8f9893cd1c2503aabb967dc Mon Sep 17 00:00:00 2001 From: Andrew Marder Date: Wed, 1 Jul 2026 10:26:38 +0000 Subject: [PATCH 4/4] Small tweaks --- src/content/post/ghost/spam/index.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/content/post/ghost/spam/index.md b/src/content/post/ghost/spam/index.md index e1dcd7b4..5b757783 100644 --- a/src/content/post/ghost/spam/index.md +++ b/src/content/post/ghost/spam/index.md @@ -1,20 +1,20 @@ --- title: "Ghost Spam Signups Suck" -publishDate: "2026-06-24" -description: "A summary of newsletter bombing and fake Ghost subscriber signups — what it is, why it happens, and how to mitigate it." +publishDate: "2026-07-01" +description: "A summary of newsletter bombing and fake Ghost subscriber signups - what it is, why it happens, and how to mitigate it." --- -Small Ghost blogs start gaining subscribers with corporate email addresses who instantly open and click every link when a post goes out. This is automated abuse — not organic growth — and it harms both the blog owner and the people signed up without consent. +Is your Ghost newsletter picking up subscribers with corporate email addresses that instantly trigger opens and clicks on every link when a post goes out? This is automated abuse - not organic growth - and it harms both you and the people signed up without consent. ## the problem -Two overlapping patterns target Ghost's `/members/api/send-magic-link/` endpoint. Ghost rate-limits it, which helps a little, but there is no CAPTCHA — and bots rotating IPs can still abuse it at scale. +Two overlapping patterns target Ghost's `/members/api/send-magic-link/` endpoint. Ghost rate-limits it, which helps a little, but there is no CAPTCHA - and bots rotating IPs can still abuse it at scale. **Newsletter bombing.** Bots sign a victim's address up to hundreds of newsletters at once, flooding their inbox with confirmation emails to bury a real security alert (password change, suspicious login, wire transfer). Your blog is ammunition, not the target. -**Email validation for phishing.** Bots sign up addresses and check whether they convert to confirmed members — often after probing the login flow first. Confirmed signups mean an active address: prime phishing targets. +**Email validation for phishing.** Bots sign up email addresses and check whether they convert to confirmed members - often after probing the login flow first. Confirmed signups mean an active address: prime phishing targets. -The confusing symptom — **instant opens and clicks from "subscribers" who never read your content** — is often corporate email security (Proofpoint, Mimecast, Barracuda, Safe Links) pre-fetching magic-link confirmation URLs. Scanners look like engaged readers; opens and clicks are not proof of a real person. +The confusing symptom - **instant opens and clicks from "subscribers" who never read your content** - is often corporate email security (Proofpoint, Mimecast, Barracuda, Safe Links) pre-fetching magic-link confirmation URLs. Scanners look like engaged readers; opens and clicks are not proof of a real person. **Cost to you:** inflated member lists, damaged sender reputation, and unknowingly spamming victims. Ghost Explore makes site discovery easier, but the root issue is a signup API with minimal protections. @@ -22,7 +22,7 @@ The confusing symptom — **instant opens and clicks from "subscribers" who neve No single fix exists. Ghost's built-in rate limit is a start; community mitigations are layered and imperfect. -**Stop bots before email is sent** — the only approach that also protects bombing victims (harm happens at send time): +**Stop bots before email is sent** - the only approach that also protects bombing victims (harm happens at send time): - CAPTCHA or Cloudflare Turnstile on the signup path - Cloudflare WAF blocking Tor (`T1`) @@ -30,7 +30,7 @@ No single fix exists. Ghost's built-in rate limit is a start; community mitigati - Tighter rate limits at your reverse proxy (Traefik, Caddy, Nginx) - Prevent CDN bypass: restrict origin to Cloudflare IPs, use a Tunnel, or set `hostSettings.siteId` with an `x-site-id` header via Cloudflare transform rules -**Fix confirmation flow:** replace one-click GET magic links with a confirm button or one-time code — stops scanners auto-confirming, but does not prevent emails from being sent. Ghost 6.17+ stopped leaking whether an email is already a member on login; abuse has continued regardless. +**Fix confirmation flow:** replace one-click GET magic links with a confirm button or one-time code - stops scanners auto-confirming, but does not prevent emails from being sent. Ghost 6.17+ stopped leaking whether an email is already a member on login; abuse has continued regardless. **Operational:** go invite-only; prune suspicious members; don't trust engagement metrics; separate transactional and newsletter SMTP; monitor bounces/complaints via webhooks. @@ -38,7 +38,7 @@ Ghost still needs stronger platform-level bot protection, optional manual approv ## my approach -My newsletter is super small. I decided to take the nuclear option and go invite-only. When someone submits their email address to subscribe on my site, I get notified, I contact them manually to confirm that they do in fact want to subscribe, and then I personally add them to the subscriber list. This approach makes sense for me right now, because I didn't want to spend time playing a game of layered whack-a-mole. +My newsletter is super small. I decided to take the nuclear option and go invite-only. When someone submits their email on my site, I get notified, reach out to confirm they actually want to subscribe, and add them to the list manually. That works for me now - I didn't want to spend time playing layered whack-a-mole. ## references