Recently we suffered a different kind of subscription bombing: a hacker using our 'change credit card' form to 'clean' a list of thousands credit cards to see which ones would go through and approve transactions.
He ran the attack from midnight to 7AM, so there were no humans watching.
IPs were rotated on every single request, so no rate limiter caught it.
We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.
We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.
Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.
We never thought this could bite us this way.
Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.
Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.
This is a big deal. Payment processors can ban you for allowing this to happen.
Being used to validate stolen card numbers has long been a problem; we've had to put in a number of defenses to fight our way off whatever list of "easy sites" these folks maintain. I hadn't thought about the "change card" path though...another bit of time spent away from what our business is really supposed to be doing...
We solved this by introducing a silent block. If the system notices unusual behavior (too many payment attempts per user, for example), it no longer sends the payment attempt to the provider. Instead, it idles for a second or two and then just fails with a generic “payment declined.” Most attackers don’t notice they’re being blocked and just assume all credit cards are bad.
Well, what you can do is notify the card issuer about those cards that went through, so they can mark them as stolen. That surely will make the hacker really happy, and discourage them of doing it again :)
I was attacked in this way a couple of months back. I use a different email address for each account (of the pattern product@example.com), and use a separate address for Git commits (like git@example.com). It was this second one that was attacked and I ended up with some 500 emails within 12 hours. Fortunately, since I don't expect anyone to actually email me on the Git address, I just put up a filter to send them all to a separate folder to go over at my leisure.
After 12 hours, the pace of emails came to a halt, and then I started receiving emails to made up addresses of a American political nature on the same domain (I have wildcard alias enabled), suggesting that someone was perhaps trying to vent some frustration. This only lasted for about half an hour before the attacker seems to have given up and stopped.
Strangely, I didn't receive any email during the attack which the attacker might have been trying to hide. Which has left me confused at to the purpose of this attack in the first place.
It's a problem, but I really dislike the solution. Putting a website with known security issues behind Cloudflare's Turnstile is comparable to enforcing code signing—works until it doesn't, and in the meantime, helps centralize power around a single legal entitiy while pissing legitimate users off.
The Internet was carefully designed to withstand a nuclear war and this approach, being adopted en masse, is slowly turning it into a shadow of its former self. And despite the us-east1 and multiple Cloudflare outages of last year, we continue to stay blind to this or even rationalize it as a good thing, because that way if we're down, then so are our competitors...
I wouldn't call this "known security issues", it's an inherent problem with any signup or forgot password page.
Also, I doubt this is going to be pissing users off since they added Turnstile in invisible mode, and selectively to certain pages in the auth flow. Already signed in users will not be affected, even if the service is down. This is way different from sites like Reddit who use their site-wide bot protection, which creates those interstitial captcha pages.
> I wouldn't call this "known security issues", it's an inherent problem with any signup or forgot password page.
It's not inherent, though! Easy, definite fix: Reverse the communication relation. If the user has to open their mail app anyway, you could simply require them to send an email to you, instead of vice versa. This would solve the problem completely. (If spoofing the sender could be done reliably, the service wouldn't be involved in the first place.)
Now, it would slightly increase friction and lower convenience. That's why it's not done. It's inherently incompatible with dark patterns, data collection and questionable new user acquisition, but this too could be solved through standards and integration - without making Cloudflare de facto infrastructure necessity!
Possible convenient, better solutions: Have the browser send this mail, either by passing a template to the mail app, integrating SMTP into the browser/addon, or instate a novel authentication protocol, which in fact may remove the human interaction completely.
As if 2FA security was the main motivation for asking for email, and/or phone anyway. Companies want user IDs, if possible UIDs, as soon as possible to increase user data value and gain marketing opportunities. I once had a "welcome mail" after typing in the address, before sending the form. Yeah...
'Inherent' has an absoluteness, which I disproved. Relying on email, is inherently troublesome, I agree.
But as I said, it's not about what's technically, or ethically mandated, but what's ensuring users won't get annoyed (getting bombed with mails is bad PR). Companies collect all these IDs for their (future) shareholders first and foremost. Asking for email doesn't alert people. Phone number would be more alarming, but that's still becoming the norm. They would ask for a picture of your passport too, but ... oh, wait!
Casually integrating Cloudflare into everything (incl. TLS termination lol), only makes data collection incentives greater. Let's not give in by declaring Cloudflare a fundamental necessity. Or do, but don't complaint about your disowned life as cattle.
Cloudflare has a stranglehold on the internet, but its marketshare is much lower than the incumbant email giants. Aprroximately 70-90% of all email goes through Google & Microsoft. You're trading one benevolant toll keeper for another... except those two give you no recourse should you end up on a sh*tlist or don't meet their unspecified and forever changing criteria for being a recognised mail provider.
Cloudflare is an excellent solution for many things. The internet was designed to withstand a nuclear war, but it also wasn’t designed for the level of hostility that goes on on the internet these days.
But cloudflare is also just difficult, I’m on Starlink (because where I am my only other option is Hughes net), and my browser of choice is Safari. No vpn, and only boring ad blockers.
I routinely blocked by Cloudflare from viewing things and occasionally, I am blocked from buying things. Just this weekend, it was $100 worth of athletic wear. I just keep clicking the box and it never lets me complete the purchase. After the 7th or 10th time I go and find another vendor that would actually sell to me. I was more annoyed than usual because the website already had my credit card at this point – but as this article proves there are reasons to block an order even with a credit card.
You have to think hard about the problem and apply individual solutions. Cloudflare didn’t work for the author anyway. Even if they had more intrusive settings enabled it would have just added captchas, which wouldn’t likely have stopped this particular attacker (and you can do on your own easily anyway).
In this case I assume the reason the attacker used the change credit card form was because the only other way to add a credit card is when signing up, which charges your card the subscription fee (a much larger amount than $1).
So the solution is don’t show the change card option to customers who don’t already have an active (valid) card on file.
A more generic solution is site wide rate limiting for anything that allows someone to charge very small amounts to a credit card.
Or better yet don’t have any way to charge very small amounts to cards. Do a $150 hold instead of $1 when checking a new card
As far as cloudflare centralization goes though, you’re not going to solve this problem by appealing to individual developers to be smarter and do more work. It’s going to take regulation. It’s a resiliency and national security issue, we don’t want a single company to function as the internet gatekeeper. But I’ve said the same about Google for years.
None of your solutions seem useful in this case, especially a $150 hold. Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.
You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes. Combine that with other (useful) mitigations. Maybe getting an alert that in the past few hours or days even, 90% of card change attempts have failed for a cluster of users.
>None of your solutions seem useful in this case, especially a $150 hold.
Attackers are going after small charges. That's the reason they're going after these guys in the first place.
>Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.
And then you give a solution that is 10x as complicated, high maintenance, and easy to mess up.
>You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes.
This is essentially a much more complex superset of rate limiting.
Since they updated the flow to only ever push 1 email to unverified users, I would say that's as patched as it can realistically be before you bring in the captchas.
As a newsletter company, we've dealt with this for over a decade now since we do the right thing and do double opt-in which involves sending the subscriber an email on signup.
Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs, so many legitimate users appear to come from low reputation IPs.
Turnstile is a reasonable solution in its normal form, though the 'invisible' option still lets a lot of them through. Another thing that works, surprisingly, is looking for "webdriver" usage. Despite being easy to strip out webdriver fingerprints, we find that the majority of automated attempts do not bother to do this. Adding more steps, honeypots (with an immediate short term IP ban), etc. also have an impact. It becomes a game of piling up numerous defences in a sort of "Swiss cheese model".
That's a fun cobra effect. Age verification ("intended" to make children safer online, if you take the most charitable view) forces more and more people to use VPNs, which overall degrades the value of IP reputation as a signal, forcing providers to accept less reputable IPs because real customers come from them, which means that providers are more vulnerable to attacks that can be used to target children.
The point isn't protection from attacks that target children, it's gatekeeping content to keep it away from children. Providers are more vulnerable to attacks, overall, because of that gatekeeping, because of ht inevitable use of tools like VPNs and proxies to bypass the mechanisms being used. This sort of anti-anonymity is specifically and precisely targeted at decreasing the security of individuals, subjecting them to surveillance and control by the state. It has nothing to do with "protecting the children" and never did.
The four horsemen of the infocalypse are always about power grabs, they're never about actually protecting citizens, or children, or securing a country or region.
One thing I have never understood in this current age is how in the world so many companies, including ones that handle confidential data like banks, don’t require a user to verify their email address after it’s entered. I have an unfortunately very generic email address that’s easy to mistype, and I am almost every day receiving order receipts for expensive vacation hotels, bank transfer or wire transfer confirmations, a very long list of things that I should not be receiving simply because the companies sending those emails never had the user verify if they entered the right email address. They are legitimate emails, they are often addressed to someone with the same first name as me but a different last name, so that person simply typed the wrong email address accidentally.
It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.
I work the email security company xorlab[0], where my colleagues and I did a thorough analysis of real subscription/email bombing waves that we saw at our customers[1].
Here are some interesting additional information from the attacks we analyzed:
* Email bombing as a service is a thing, where you can buy 10,000 credits for $10 and easily bomb target inboxes with over 2000 emails per hour.
* Most all email bombing attacks starts in the morning, between 8-10.
I absolutely refuse to use BigTech gatekeepers or useless CAPTCHAS (any sufficiently advanced bot can get around any CAPTCHA anyway). We solved this at our startup by running names through a simple LLM filter - if the name is gibberish like Px2846skxojw just block the signup. Worked surprisingly well. Of course this is easy to get around if the bot knows what you’re doing. But bots look for easy targets, as long as there are enough vibe coded crap targets on the internet they’re not going to bother with circumventing a carefully designed app.
This happened to me several years ago. I got signed up to probably 700 newsletters overnight. In the middle of all of the sign ups there was activity on my airbnb account where my notification settings were changed. when i checked my airbnb i noticed that someone had created a fake listing under my account and disabled booking notifications for it. a real multi-layer scam where the hacker would be making money off a fake listing on someone else's account who would probably never even realize it.
Well written piece on an attack vector I'd never thought too hard about before. Thanks for elaborating on why sending an email or two to a random person helps an attacker achieve their goal. A lot of similar articles skip over details like that.
> that meant each victim received three emails from us in under a minute:
> Verify your email address
> Welcome to Suga
> Reset your password
> Three emails they never asked for, from a product they may never have heard of. We were just one of potentially hundreds of sites being hit at the same time.
@homelessdino
Why would you send welcome and reset to some victim that DID NOT verify?
I had my email stolen in such an attack, i still get random "you abandoned your cart!" Emails now and then, but luckily (?) they got my credit card at the same time and i cancelled it within minutes. So it's a little annoyance, but it doesn't really make sense to me that the flood works. At least not with American credit cards that are routinely flagging my own trips to microcenter lol
Editing to add: almost 100% of these emails came from the same e-commerce product, I'll have to look up which. But every site i got an email from was running the same off the shelf template.
Oh, that actually explains a lot. I used to offer a 7-day free trial for one of my apps that you could sign up for with an email, and the vast majority of the licenses were never used. The app wasn't even downloaded that many times.
I stopped offering the trial since I figured it was not useful for a relatively cheap (19 EUR) app that has a 30-day money-back guarantee anyway. (It can also be used for 15 mins without a license, but requires a restart after that.)
> The goal [...] to flood the victim’s inbox with so much noise that they can’t find the emails that actually matter.
> While the victim is drowning [...] the attacker is doing something else.
In the past months some personal mail accounts on a mail server I administer were victim of something that looked similar to what's described here.
Hundreds of mails apparently originating from various (legit-looking) random public web services, support requests, issue trackers, web contact forms etc. For example, a good part of them was from Virginia Department of Motor Vehicles (as in something like "thank you for filing a document #123 with us").
To make things even weirder, they were not sent directly to the address, but according to message headers were bounced through Google Groups (each time I checked the relevant group was already deleted). So as far as I can tell it was not the mail address hosted on my server that was being entered into those websites.
No phishing links, no attached malware, no short advertisements snuck into a text field etc. Just a huge amount of automated replies from "noreply@" legit entities.
I've seen several of these attacks and spent some time investigating them. To my knowledge these were not associated with any other malicious activity, like the author of the article mentions. If anything they were just a denial-of-service attack on a mail box (as in, making the human user trawl through garbage, the mail volume was far from saturating the server itself). What exactly would be a motivation for that I can't tell, except making the life of a small mail server admin even harder than it already is.
Mitigating this is kind of pointless, because so many sites are vulnerable to this.
I got subscription bombed from about a dozen .gov sites a while back. Healthcare.gov, Social Security Administration, WTC Health Program, FDA, National Institute of Mental Health, Medicare.gov.
It's very easy for attackers to do this. Putting in effort to solve this for one site, and expecting any impact, is like trying to empty the ocean with a teaspoon.
I had this happen to me at the weekend. Someone bought a train ticket using my debit card and then (I assume) in an attempt to hide the copy of the ticket that was emailed to me, I was subscription bombed at the same time.
Oh that’s interesting. I think that matches perfectly with an experience I had with a micro saas I run. I first thought people discovered it organically because it started with just a few signups throughout the weekend, then eventually escalated to multiple an hour. None of the accounts were active but email addresses didn’t look too odd and they weren’t bouncing. I eventually added a captcha that seems to have been effective, but that was a surprising experience because there is nothing you can use that saas for anything nefarious as far as I’m aware
So that explains the handful of random sign-ups I am getting on Communick. The pattern fits exactly what I am seeing as well (3-4 signups in an hour, weird usernames and gmail/hotmail addresses with lots of "." that are usually ignored. At least on my case the mitigation comes with my obsession in not collecting any unnecessary data. Email address are optional and only used if you are already a paying subscriber.
Maybe I should just remove it from the sign-up form altogether and use it as a honeypot.
I don't really understand the captcha hate, it's table stakes for any public-facing form. You need to pick a point on the "Ease of signup" vs. "Security" curve, and email signup + captcha seems to be the sweet spot.
I haven't seen any proof that the big ones (Google, CF) can be easily and automatically bypassed, and would love to learn more if someone has evidence to the contrary.
The attack doesn't work on hey mail, since new senders have to be accepted before they go the inbox. Presumably Google or whatever is already whitelisted and just goes through
I'm not sure this is on the email address form providing service's side to combat. This is an inherent issue to email. Email should evolve finally, or disappear.
The irony is that the services most vulnerable to this are the ones that collect the most email/data in the first place. Minimal data collection is the best mitigation.
Could ask new users to send an email on a generated temp adress before sending the confirm e-mail.
I do think e-mail should be not only opt-in, but also optional!
I has gone down recently (or they switched to other sites), but it was coming from EU VPN addresses at first before they got lazy and used mostly Russian IPs.
> If a bot creates an account with someone else’s email, the victim gets one email, if they ignore it that’s the end of it. The welcome email and everything after it only fires once the user verifies.
As a user, I would prefer no welcome email at all.
Interesting, until it turned into an ad for Cloudflare, it spreads like plague on the internet, slowing everyday down, forcing JS and trying to pull every single datapoint from your browser. Is this really the _only_ solution?
We experienced a similar thing; Thousands of new accounts were being created over a short period, but it was Amazon SES sending us a warning about complaint numbers that woke us up to it.
We added a captcha and used a disposable email checking service to get rid of it.
Honestly just don't send anything past the verification email until the address is confirmed. A lot of the other fixes here are working around what's really just auth libraries trusting the address on signup. Feels like that's the thing worth fixing first.
181 comments
He ran the attack from midnight to 7AM, so there were no humans watching.
IPs were rotated on every single request, so no rate limiter caught it.
We had Cloudflare Turnstile installed in both the sign up form and in all credit card forms. All requests were validated by Turnstile.
We were running with the 'invisble' setting, and switched back to the 'recommended' setting after the incident, so I don't know if this less strict setting was to blame.
Just like OP, our website - to avoid the extra hassle on users - did not require e-mail validation, specially because we send very few e-mails.
We never thought this could bite us this way.
Every CC he tried was charged $1 as confirmation that the CC was valid, and then immediately refunded, erroring out if the CC did not approve this $1 transaction, and that's what he used. 10% of the ~2k requests went through.
Simply adding confirmation e-mail won't cut it: the hacker used - even tough he did not need it - disposable e-mail addresses services.
This is a big deal. Payment processors can ban you for allowing this to happen.
After 12 hours, the pace of emails came to a halt, and then I started receiving emails to made up addresses of a American political nature on the same domain (I have wildcard alias enabled), suggesting that someone was perhaps trying to vent some frustration. This only lasted for about half an hour before the attacker seems to have given up and stopped.
Strangely, I didn't receive any email during the attack which the attacker might have been trying to hide. Which has left me confused at to the purpose of this attack in the first place.
The Internet was carefully designed to withstand a nuclear war and this approach, being adopted en masse, is slowly turning it into a shadow of its former self. And despite the us-east1 and multiple Cloudflare outages of last year, we continue to stay blind to this or even rationalize it as a good thing, because that way if we're down, then so are our competitors...
Also, I doubt this is going to be pissing users off since they added Turnstile in invisible mode, and selectively to certain pages in the auth flow. Already signed in users will not be affected, even if the service is down. This is way different from sites like Reddit who use their site-wide bot protection, which creates those interstitial captcha pages.
> I wouldn't call this "known security issues", it's an inherent problem with any signup or forgot password page.
It's not inherent, though! Easy, definite fix: Reverse the communication relation. If the user has to open their mail app anyway, you could simply require them to send an email to you, instead of vice versa. This would solve the problem completely. (If spoofing the sender could be done reliably, the service wouldn't be involved in the first place.)
Now, it would slightly increase friction and lower convenience. That's why it's not done. It's inherently incompatible with dark patterns, data collection and questionable new user acquisition, but this too could be solved through standards and integration - without making Cloudflare de facto infrastructure necessity!
Possible convenient, better solutions: Have the browser send this mail, either by passing a template to the mail app, integrating SMTP into the browser/addon, or instate a novel authentication protocol, which in fact may remove the human interaction completely.
As if 2FA security was the main motivation for asking for email, and/or phone anyway. Companies want user IDs, if possible UIDs, as soon as possible to increase user data value and gain marketing opportunities. I once had a "welcome mail" after typing in the address, before sending the form. Yeah...
But as I said, it's not about what's technically, or ethically mandated, but what's ensuring users won't get annoyed (getting bombed with mails is bad PR). Companies collect all these IDs for their (future) shareholders first and foremost. Asking for email doesn't alert people. Phone number would be more alarming, but that's still becoming the norm. They would ask for a picture of your passport too, but ... oh, wait!
Casually integrating Cloudflare into everything (incl. TLS termination lol), only makes data collection incentives greater. Let's not give in by declaring Cloudflare a fundamental necessity. Or do, but don't complaint about your disowned life as cattle.
Cloudflare is an excellent solution for many things. The internet was designed to withstand a nuclear war, but it also wasn’t designed for the level of hostility that goes on on the internet these days.
I routinely blocked by Cloudflare from viewing things and occasionally, I am blocked from buying things. Just this weekend, it was $100 worth of athletic wear. I just keep clicking the box and it never lets me complete the purchase. After the 7th or 10th time I go and find another vendor that would actually sell to me. I was more annoyed than usual because the website already had my credit card at this point – but as this article proves there are reasons to block an order even with a credit card.
And these people weren't validating the email address on signup. To "reduce friction" i guess.
In this case I assume the reason the attacker used the change credit card form was because the only other way to add a credit card is when signing up, which charges your card the subscription fee (a much larger amount than $1).
So the solution is don’t show the change card option to customers who don’t already have an active (valid) card on file.
A more generic solution is site wide rate limiting for anything that allows someone to charge very small amounts to a credit card.
Or better yet don’t have any way to charge very small amounts to cards. Do a $150 hold instead of $1 when checking a new card
As far as cloudflare centralization goes though, you’re not going to solve this problem by appealing to individual developers to be smarter and do more work. It’s going to take regulation. It’s a resiliency and national security issue, we don’t want a single company to function as the internet gatekeeper. But I’ve said the same about Google for years.
You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes. Combine that with other (useful) mitigations. Maybe getting an alert that in the past few hours or days even, 90% of card change attempts have failed for a cluster of users.
>None of your solutions seem useful in this case, especially a $150 hold.
Attackers are going after small charges. That's the reason they're going after these guys in the first place.
>Site-wide rate limiting for payment processing? Too complicated, high-maintenance, and easy to mess up.
And then you give a solution that is 10x as complicated, high maintenance, and easy to mess up.
>You can't block 100% of these attempts, but you can block a large class of them by checking basic info for the attempted card changes like they all have different names and zip codes.
This is essentially a much more complex superset of rate limiting.
Until a few years ago, IP reputation was a good defence against this. The bad traffic almost entirely came from IP addresses in certain countries or from datacenter IPs we could block. Nowadays, that doesn't work due to the prevalence of VPNs, so many legitimate users appear to come from low reputation IPs.
Turnstile is a reasonable solution in its normal form, though the 'invisible' option still lets a lot of them through. Another thing that works, surprisingly, is looking for "webdriver" usage. Despite being easy to strip out webdriver fingerprints, we find that the majority of automated attempts do not bother to do this. Adding more steps, honeypots (with an immediate short term IP ban), etc. also have an impact. It becomes a game of piling up numerous defences in a sort of "Swiss cheese model".
The four horsemen of the infocalypse are always about power grabs, they're never about actually protecting citizens, or children, or securing a country or region.
It’s bonkers to me that there’s any developers out there working for these companies that never thought to implement simple email verification.
Here are some interesting additional information from the attacks we analyzed:
* Email bombing as a service is a thing, where you can buy 10,000 credits for $10 and easily bomb target inboxes with over 2000 emails per hour.
* Most all email bombing attacks starts in the morning, between 8-10.
* Most common day of attack is Friday
[0] https://www.xorlab.com/en/
[1] https://www.xorlab.com/en/blog/from-chaos-to-control-insight...
My conclusion is to move from WordPress software as fast as possible, every WordPress site I manage gets bombarded by bots.
> that meant each victim received three emails from us in under a minute:
> Verify your email address > Welcome to Suga > Reset your password > Three emails they never asked for, from a product they may never have heard of. We were just one of potentially hundreds of sites being hit at the same time.
@homelessdino
Why would you send welcome and reset to some victim that DID NOT verify?
Editing to add: almost 100% of these emails came from the same e-commerce product, I'll have to look up which. But every site i got an email from was running the same off the shelf template.
I stopped offering the trial since I figured it was not useful for a relatively cheap (19 EUR) app that has a 30-day money-back guarantee anyway. (It can also be used for 15 mins without a license, but requires a restart after that.)
> The goal [...] to flood the victim’s inbox with so much noise that they can’t find the emails that actually matter.
> While the victim is drowning [...] the attacker is doing something else.
In the past months some personal mail accounts on a mail server I administer were victim of something that looked similar to what's described here.
Hundreds of mails apparently originating from various (legit-looking) random public web services, support requests, issue trackers, web contact forms etc. For example, a good part of them was from Virginia Department of Motor Vehicles (as in something like "thank you for filing a document #123 with us").
To make things even weirder, they were not sent directly to the address, but according to message headers were bounced through Google Groups (each time I checked the relevant group was already deleted). So as far as I can tell it was not the mail address hosted on my server that was being entered into those websites.
No phishing links, no attached malware, no short advertisements snuck into a text field etc. Just a huge amount of automated replies from "noreply@" legit entities.
I've seen several of these attacks and spent some time investigating them. To my knowledge these were not associated with any other malicious activity, like the author of the article mentions. If anything they were just a denial-of-service attack on a mail box (as in, making the human user trawl through garbage, the mail volume was far from saturating the server itself). What exactly would be a motivation for that I can't tell, except making the life of a small mail server admin even harder than it already is.
I got subscription bombed from about a dozen .gov sites a while back. Healthcare.gov, Social Security Administration, WTC Health Program, FDA, National Institute of Mental Health, Medicare.gov.
It's very easy for attackers to do this. Putting in effort to solve this for one site, and expecting any impact, is like trying to empty the ocean with a teaspoon.
Now, every mofo just wants a grant to ---- innocent kids in school.
Maybe I should just remove it from the sign-up form altogether and use it as a honeypot.
I haven't seen any proof that the big ones (Google, CF) can be easily and automatically bypassed, and would love to learn more if someone has evidence to the contrary.
What’s the alternative, though?
What if each service generates a link to a uuid url where all new message will be displayed? The user can rss subscribe to that.
So the user doesn’t receives anything.
> If a bot creates an account with someone else’s email, the victim gets one email, if they ignore it that’s the end of it. The welcome email and everything after it only fires once the user verifies.
As a user, I would prefer no welcome email at all.
We added a captcha and used a disposable email checking service to get rid of it.
Author, why can you not use your own words?
I am not sure what you meant to say, vs what is LLM garbage I could have prompted myself.