[thaumaturgy]

Mainly forms -- login forms, comment forms, signup forms. Bots use Tor pretty heavily because it's anonymous and hard to block them without blocking the entire network. Login form abuse is mildly irritating but not a huge deal if you have other measures in place. Comment spam is annoying but there are some options that deal with it pretty well.

But the signup spam was a headache. I didn't want to just blackhole Tor traffic, and tried to reduce the abuse with other tools, including some custom stuff. The final straw was a customer's small business site that had a MailChimp or Constant Contact signup form. Those vendors want you to embed their code by default to render the form, so you have less control over the form itself. There were workarounds, but they all sucked.

Tor bots would sign up email addresses through this newsletter form, and then I'd have to go through and manually scrub them before newsletters went out, or the service would penalize my client for too many bounces/unsubscribes/complaints. Very nearly 100% of the abuse on that particular form came from Tor IPs.

I do not want to spend my limited time on this Earth manually sorting out bots from humans because of one particular network. Blackholing Tor made that problem disappear immediately.

VPNs are dime-a-dozen now, cheap VPSs are available from lots of vendors, there's Wireguard, there's ssh, a clever person could even set up Apache or nginx as a forward proxy with ssl from LetsEncrypt. Tor is well over 90% abusive traffic (https://blog.cloudflare.com/the-trouble-with-tor/). This is a Tor problem, not a me problem. There are better alternatives available.

[mjevans]

I think the workflow is the issue with http(s)-based email list sign-ups.

Solution: Require sign-ups by email, so the end account must actively send your mailserver a registration message. This also turns an open-loop control system into a closed loop control system, which is inherently easier to secure / keep safe.

[gregmac]

How would this be better? It's trivially easy to spoof email addresses. Someone could sign you up easily, for example.

It's also easy to send "from" an addresses that passes SPIF/DKIM but bounces inbound mail -- not sure what reason someone would have for this other than hurting the service reputation or acting as a DoS of sorts, but it can be done.

[3np]

> It's trivially easy to spoof email addresses. Someone could sign you up easily, for example.

Proper DMARC configuration is table stakes to send e-mail, which makes that anything but trivial.

[viraptor]

But neither the newsletter host nor the email user has any input into how dmarc/dkim/spf are implemented. Only the user's email provider does. And if that's a small business domain, it's likely not very strict with the rules.

[namibj]

I thought DMARC/DKIM was necessary for delivering to Gmail for years now; in any case, there should be few who can't use a backup email to subscribe, as your newsletter won't be the only thing that has these anti-spoof requirements.

[viraptor]

Not necessary. Just very highly recommended. I can still deliver my cron emails from a rando host successfully.

[Schroedingersat]

> Mainly forms -- login forms, comment forms, signup forms. Bots use Tor pretty heavily because it's anonymous and hard to block them without blocking the entire network. Login form abuse is mildly irritating but not a huge deal if you have other measures in place. Comment spam is annoying but there are some options that deal with it pretty well.

Then put the form behind your monopolistic internet gatekeeper. There's no reason for a GET to redirect to a sysiphean captcha treadmill.