How are people handling spam signups?

[JamesChevalier]

I've got a double opt-in list, and twice now I've had someone script a continuous signup loop that results in tons of "Confirm subscription" emails being sent and bouncing back. The only way I can figure out how to mitigate the issue is to turn off my listmonk server.
I purposefully have everything configured in a way that lets my user base reply to any email & have their response go into my inbox - this also causes the bounce back messages to show up in my inbox. My product is fairly niche, and I appreciate being able to provide that direct line of communication. If I had a 'noreply' un-monitored email, I probably wouldn't know the issue was happening until I received my bill... 😓

The first attack used what seemed to be a valid email address, which was disabled/throttled by the email service. The second attack used an invalid user on a valid domain, which resulted in bounce-back errors and ultimately a temporary IP ban. Both attacks didn't use any variation in the email address being subscribed.
So, for this particular issue, it seems like everything would be mitigated if listmonk only sent one "Confirm subscription" per email. From what I recall (I had to turn the server off, so I cannot confirm), only a single subscriber record is created but it seems like each signup results in that "Confirm subscription" email sending.
The obvious next step in this attack is to vary the email address for each subscription call, which seems like it would require a more detailed/nuanced rate limit.

Did I overlook a feature of listmonk that handles this issue for me?

[knadh]

I think the only way to mitigate bots hammering the open subscription form with random signups is to turn CAPTCHA on in Settings -> Security. Even IP ratelimits in a proxy like Nginx in front of listmonk aren't effective because of the large pool of IPs used in attacks. It's unfortunate.

listmonk uses hCaptcha currently, but in the next version, I'm planning to incorporate a self-contained system.

[JamesChevalier]

Thanks, that all makes sense.

Ultimately, since I don't use the public signup page in listmonk (I have a custom form in my site that POSTs out to listmonk), I was able to just disable that feature. My signup form is only shown to logged in users, and enabling captcha broke it since that endpoint would be expecting a successful captcha.

[JamesChevalier]

I have Enable public subscription page disabled, but I'm still seeing spam signups. I can't enable Enable CAPTCHA because I have a custom form in my site for newsletter signups (only shown to logged in users). While Enable CAPTCHA is enabled, it breaks my form submission.

Maybe my implementation of a form with a POST request to https://my_domain/subscription/form to sign people up is incorrect. Perhaps I should be using the POST /api/subscribers API endpoint instead. I'll rework that now...

I'm thinking that two updates would be very helpful (but they're definitely not without their caveats):

• If Enable public subscription page disabled, disallow all signups through that path
  • Perhaps this is more complicated than it seems, since it seems like it would affect all signups through that /subscription/form endpoint ... or maybe it isn't & I've been doing it wrong ...
  • This can currently be accomplished by enabling Enable CAPTCHA since custom built form submissions to the /subscription/form endpoint wouldn't include that CAPTCHA value
• If a subscriber already exists, skip sending the double opt-in email
  • This is probably more nuanced than I'm giving it space for here e.g. someone signs up for a newsletter and accidentally deletes the opt-in email and tries to sign up again