Why a Fortune-500 CEO Just Subscribed to My Blog About a 40-Year-Old Unix (Spoiler: They Did Not)
The world is most influential executives suddenly subscribed to my niche tech blog. None of them had heard of me. A field guide to newsletter bombing, the magic link that clicks itself, and why your blog is the ammunition, not the target.
Or: A Field Guide to Newsletter Bombing, the Magic Link That Clicks Itself, and the Day a Fortune-500 CEO "Subscribed" to My Blog About a 40-Year-Old Unix.
One morning I opened my members list and found that the most influential people in global business had, apparently, developed a burning interest in my niche technical blog. Law-firm partners. Property-management executives. An airport. A company that makes bathtubs. A CEO whose actual job is running an energy company had, it seemed, signed up to read my thoughts on self-hosting.
My first reaction was the one every blogger secretly wants: finally, the suits have noticed me.
My second reaction, about four seconds later, was the correct one: none of these people have ever heard of me, and something is very wrong.
You are not the target. You are the ammunition.
What I was looking at is called newsletter bombing (or subscription bombing, or list bombing — the security industry can never agree on a name for anything). And the most important thing to understand about it is that your blog is not the victim. You're a tool.
Here's the shape of it. Somewhere out there is a real person — let's say a manager at one of those corporations. Someone has just done something nasty to one of their accounts: changed a password, authorized a transfer, logged in from a country they've never visited. That person is about to receive one email that matters enormously — "your password was changed," "we noticed a new sign-in," "your order has shipped."
The attacker's problem is that this one email is easy to spot. So they make it impossible to spot. They take the victim's address and feed it into a bot that signs it up to hundreds or thousands of newsletters in the span of a few minutes. The inbox detonates. Five hundred "Welcome! Confirm your subscription!" emails pour in, and the one real warning drowns in the flood, unread, until it's far too late.
My blog — and probably yours — is just one of the hundreds of little signup forms that bot visited. Each of us contributes one or two confirmation emails to someone else's catastrophe. We're not being attacked. We're being used, like a phone booth in an old heist movie.
There's a second motive too, less common but nastier: if enough of these unwanted emails get marked as spam, the sender's reputation tanks, and eventually the mail provider blocks everything you send. Bomb a blog hard enough and you don't just hide one email — you take the blog's whole newsletter offline. Collateral damage as a feature.

The part that breaks everyone's brain: the magic link clicks itself
Here is the question that made me stare at the ceiling for a while. My blog uses confirmation links. To become a subscriber, you have to click a link in an email. So how are bots clicking my confirmation links? Bots don't have inboxes.
They don't. The email security appliances do.
Big organizations — the exact law firms and airports and corporations filling my list — run their inbound mail through heavyweight security platforms. The brand names are familiar to anyone who's worked in enterprise IT: Proofpoint, Mimecast, Barracuda, Microsoft's Safe Links. These systems have a feature that sounds wonderful in a sales deck: before a human ever sees an email, the platform pre-fetches every link inside it and checks where it goes. Phishing? Malware? Better to find out by visiting the link in a sandbox first.
You can see where this is going. The bot signs up the victim's corporate address. My blog dutifully emails a confirmation link to that address. The corporation's security platform receives the email and, being diligent, visits the confirmation link to make sure it's safe — and in doing so, confirms the subscription. To my blog, an automated security scan and an enthusiastic new reader look exactly the same: a GET request to the magic link. Click registered. Welcome aboard, Mr. CEO.
This is, when you think about it, a small design tragedy. There is an old, boring rule of the web that says a GET request should be safe — it should fetch things, not change things. Confirming a subscription changes things. It should arguably never have been a one-click GET in the first place. But it is, almost everywhere, and so the security scanners that exist to protect these executives are the very thing volunteering them for a thousand newsletters.
You can tell the scanners apart from humans, by the way, once you know what to look for. A real reader opens an email and maybe clicks a link or two. A security appliance opens nothing and clicks everything — every link in every newsletter, over and over. When you find a "subscriber" with zero opens and ninety clicks, you are not looking at a fan. You are looking at a robot doing its job a little too well.
Cleaning up the mess
So you've identified the impostors. Now you'd like them gone, ideally without nuking the handful of real humans who actually read your stuff. A few hard-won notes from doing this myself:
The database is more forgiving than you'd fear. Modern Ghost wires its member tables together with proper foreign keys and cascading deletes, so removing a member tidies up most of the related records automatically. You don't need to hand-delete a dozen child tables; you mostly need to remove the member and let the database do the housekeeping. (A couple of stats tables aren't wired in and need a manual sweep, but they're harmless either way.)
Write down what you delete, before you delete it. Bulk-removing members from a production database is the kind of operation that feels great right up until you realize your filter was slightly too greedy. Copy the doomed rows into a backup table first. It costs nothing and it converts "irreversible mistake" into "mild inconvenience."
Your filter will betray you at least once. I built a tidy rule — corporate domain, no engagement, signed up out of nowhere — ran it, and cheerfully deleted my own admin address, which happened to match every criterion. That's what the backup is for. Whitelist yourself, your family, and anyone who's clearly a real reader before you pull the trigger.
Opens are not proof of life. The most counterintuitive lesson: a "subscriber" who has opened and clicked dozens of times can still be a bot, because the email security scanner generates those opens and clicks. Don't treat engagement as innocence. Treat plausibility as innocence — does this person look like someone who'd read a blog about your actual subject? A working sysadmin with a university address, sure. A bathtub manufacturer's accounts-receivable department? Come on.

The uncomfortable truth: there's no good front door
Here's where I have to be honest about the platform. Ghost, at least at the time of writing, ships with no CAPTCHA and no bot protection on its signup form whatsoever. None. The subscribe button is wide open, and the bots know it. This isn't a secret — self-hosters have been complaining about it for ages — but it's still a little startling to discover that the only thing standing between your newsletter and the entire internet's worth of automated abuse is good manners.
So what can you actually do?
The intuition a lot of people have — make the confirmation link land on a page where you have to click a real button — is genuinely correct as a principle. It restores the "GET is safe" rule: a security scanner can fetch the page, but it won't press the button, so it can't confirm. That would clean up your list and protect your reputation. The catch is that it does nothing for the actual victim, because the confirmation email still gets sent the moment the bot submits the form. The flood happens at send time, not at confirm time. To spare the victim, you have to stop the bot before anything is mailed — and that means a challenge on the signup itself.

In practice, the levers that exist today are:
- Put a challenge in front of the signup endpoint. If you're behind Cloudflare, a managed challenge or Turnstile on the members signup path is the cleanest fix that money doesn't have to buy. It stops the automated submission cold, which means no email is ever sent — the only option that helps you and the stranger whose inbox is under attack.
- Go invite-only if your newsletter isn't the point of your site. It ends the abuse instantly, at the cost of ending organic signups too. A blunt instrument, but a reliable one.
- Watch and prune. If you can't or won't do either, at least keep an eye on the list and sweep periodically. Low-volume bombing is annoying but survivable as long as you don't let the junk pile up and quietly poison your deliverability.
None of these are satisfying. The satisfying fix — a platform that simply doesn't let robots mash the subscribe button ten thousand times — isn't on the menu yet. Until it is, running a newsletter on an open signup form means accepting that, periodically, the titans of global industry will appear to take a sudden, fleeting interest in whatever obscure thing you write about, and then you will have to politely escort them back out.
You're welcome, by the way. Wherever you are, Mr. CEO. I hope you found the real email in time.

Support This Blog — Because Heroes Deserve Recognition!
Whether it's a one-time tip or a subscription, your support keeps this blog alive and kicking. Thank you for being awesome!
Tip OnceYou read this far.
Subscribe to get the next field guide before the bots find your inbox — no spam, no bombing, just questionable self-hosting decisions delivered straight to you.
Subscribe