Session log — Newsletter bot protection

← All session logs

Session log — Newsletter bot protection

18 June 2026, morning · s2l.online · Hasmukh with Claude · auto-published from the local journal entry. A polished narrative version can be requested in any future Claude session.

Summary

Hasmukh's daily activity digest showed bot sign-ups arriving on the newsletter form (gibberish names, padded-Gmail addresses — the same actor that had hit the sign-up page and created fake accounts). He asked me to review the newsletter form and add a guard rail if needed. It badly needed one: the list held 38 subscribers but only 4 were real people (Hasmukh on two addresses, Kenn, and Naren Gajjar); the other 34 were bots. The form has a hidden trap, but the bots stepped around it, and the email-confirmation step that would stop them was switched off, so every bot landed straight on the active list.

Hasmukh first asked for the same visible "I am human" tick as the sign-up page. On building it I found that would be fragile here: the newsletter form belongs to a bundled plugin that processes the sign-up in its early load step and exits, so a separate guard cannot reliably intercept it, and editing the bundled plugin would be wiped by a future update (the same failure that had knocked out the sign-up tick). I flagged this and recommended email confirmation instead, which is a clean built-in setting that cannot be wiped. Hasmukh agreed.

Decisions

  • Guard the newsletter with double opt-in (email confirmation), not the Cloudflare tick, because the bundled plugin cannot host the tick update-safely.
  • Deliberately did NOT switch on the per-IP or per-domain rate limits: S2L's audience is mostly on mobile carrier connections (many people share one address) and heavily on gmail, so those caps would wrongly block real sign-ups. Email confirmation plus the existing hidden trap stop the bots with no false positives.
  • Remove the 34 bot subscribers, keep the 4 real ones, back up first.

Changes made

  • Backed up the newsletter settings, then switched on email confirmation and wrote a friendly confirmation email (with the confirm link). New sign-ups now stay pending until they click the link; bots cannot, so they never join the list.
  • Backed up and removed the 34 bot subscribers (and their list/tracking rows), leaving the 4 genuine subscribers. No leftover data.
  • Saved an internal reference note on the newsletter guard and why the tick was not used here.

Follow-ups

  • Hasmukh can test by signing up with a spare email — he should get a "please confirm" email, and only appear on the list after clicking the link.
  • If bot sign-ups ever ramp up sharply, revisit (e.g. a higher per-domain cap, or the visible tick via a custom form), but email confirmation should hold.
  • Backups (server): /root/backups/EP_Newsletter.20260618-102333.json and deleted-newsletter-bots-20260618-102333.{txt,sql}.