This is the first time I've heard of slopsquatting, but it does seem like a major and easily exploitable risk.
However, blocking an email domain will dissuade only the lowest effort attacker. If the abusers think slopsquatting is effective, they'll easily be able to find (or create) an alternative email provider to facilitate it.
And assuming that the attacks will persist, sometimes it's better to let them keep using these massive red flags like an inbox.ru email so that it remains a reliable way to separate the the fraudulent from legitimate activity.
Of course this is true. It's the worst reason to denigrate a proactive measure. Speeders buy radar detectors. Wife beaters buy their wife long sleeves. This complaint is levied all the time by everyone which makes it low effort and not useful.
It’s funny they are talking about low hundreds of emails. This is what a single properly instructed human can create with any provider in a few hours, no bots needed.
Agreed, I thought it was going to be something automated, but 250 accounts in 7 hours seems pretty manual. That does make it harder to stop.
* 2025-06-09 first user account created, verified, 2FA set up, API Token provisioned
* 2025-06-11 46 more user accounts created over the course of 3 hours
* 2025-06-24 207 more user accounts created over the course of 4 hours
I do run https://bademails.org , powered by the same disposable-email-domains project, and I'll be the first to say that it only cuts out the laziest of attempts. Anyone even slightly serious has cheap alternatives (25 to 100+ accounts for $1 on popular email hosts).
The whole model is broken. The NPM/PyPI idea (vscode extensions got in similar trouble recently) of "we're just a host, anyone who wants to can publish software through us for anyone in the world to use with a single metaphorical click" is just asking for this kind of abuse.
There has to be a level of community validation for anything automatically installable. The rest of the world needs to have started out by pulling and building/installing it by hand and attesting to its usefulness, before a second level (e.g. Linux distro packagers) decide that it's good software worth supplying and supporting.
Otherwise, at best the registries end up playing whack-a-mole with trickery like this. At worst we all end up pulling zero days.
I don't think the model is broken; a latent assumption within the model has always been that you vet your packages before installing them.
The bigger problem is that people want to have their cake and eat it too: they want someone else to do the vetting for them, and to receive that added value for no additional cost. But that was never offered in the first place; people have just sort of assumed it as open source indices became bigger and more important.
Has anyone tried calculating pagerank numbers for such packages, since so many of them depend on other packages, and most of these repositories report install counts?
This is easy to game, and in some ways has been pre-gamed. So it wouldn't really be a measure of validation, but would be interesting to see.
You can use open-source security analytics (1) to detect fraudulent accounts instead of blocking domain names. Blocking domains only shows your system is fragile and will likely just shift the attackers to use other domains.
Feel free to contact us if you need assistance with setup.
Blocking providers makes sense since they can talk to the human that is doing the abuse. It's their customer after all
Like with IP ranges that send a lot of spam/abuse, it's the provider's space in the end. If the sender has no identification (e.g. User-Agent string is common for http bots) and the IP space owner doesn't take reasonable steps, the consequence is (imo) not to guess who may be human and who may be a bot, but to block the IP address(es) that the abuse is coming from. I remember our household being blocked once when I, as a teenager, bothered a domain squatter who was trying to sell a normal domain for an extortionary price. Doing a load of lookups on their system, I couldn't have brought it down from an ADSL line but apparently it was an unusual enough traffic spike to get their attention, as was my goal, and I promptly learned from the consequences. We got unblocked some hours after my parent emailed the ISP saying it wouldn't happen again (and it hasn't)
You don't have to look very far on HN to see the constant misclassifications of people as bots now that all the blocking has gotten seven times more aggressive in an attempt to gatekeep content and, in some cases, protect from poorly written bots that are taking it out on your website for some reason (I haven't had the latter category visit my website yet, but iirc curl/Daniel mentioned a huge outbound traffic volume to one scraper)
I have to say that I don't understand the approach. On one hand, addresses @inbox.ru are administered by Mail.Ru, the largest Russian free email host (although I have the impression that its usage is declining), so quite a few (arguably unwise) real people might be using them (I’ve actually got one that I haven’t touched in a decade). On the other, the process for getting an address @inbox.ru is identical to getting one @mail.ru and IIRC a couple of other alternative domains, but only this specific one is getting banned.
Do you have special access or such thing can be tracked from outside somehow? Could be a fun project to detect this kind of abusive behavior automatically
That disposable-email-domain project is a good one. Over 10 years ago I did a dumb thing and pointed some of my domains MX's to Mailinator before I used them for real email with Fastmail and now the domains are flagged all over the place as disposable even though they haven't been used that way in ages.
This project has an allowlist you can submit a PR to so it doesn't get sucked back in every time people submit outdated lists of free email provider domains.
I've sent dozens of PR's to de-list my domains on various projects across Github and it's like fighting the sea, but the groups making opensource software to use these lists are at least very apologetic and merge the PR's quickly.
However, the biggest ASSHOLES are Riot Games. I've reached out to and they will not ban new user registrations on my domains. I eventually just had to block all the new account registration emails for League of Legends I was getting in my catch-all. The maintainer of the tool people were using to make new accounts was very responsive and apologetic (quickly merged my PR) but it doesn't stop people who used the old versions of it from continuing.
Mike is doing an incredible job of finding ways to make it harder for attackers to abuse PyPI (see the PyPI quarantine project). At Safety (previously PyUp) we've been tracking a significant increase in malicious packages that compromise you as soon as you install them. We've extended our open-source CLI tool with a "Firewall" capability that aims to protect against some of these kinds of attacks (typosquatting, slopsquatting) while not requiring any changes to the tooling you use (e.g. pip, uv, poetry).
You can check it out with: pip install safety && safety init
I don't understand how a mere account signup is the bar for publishing packages. Why not queue the first few publishes on new accounts for manual review?
Mail.ru is more than real, there is just a trend to move away from passwords because they are not secure when used by ordinary people and can be stolen with a keylogger. So Russian services move to SMS codes, mobile apps or government services for authorization. Also it is a legal requirement to implement a system that doesn't allow anonymous registration, not linked to real identity.
I'm really not following -- why does the ban specifically focus on a single domain instead of attempting to solve the core issue? Do the maintainers not know that accounts for any big email provider (gmail, outlook, you name it) can be bought or created for very, very cheap. Which is obviously what the attackers will now do after this ban.
The blog post references [0] which makes it seem like the maintainers do, in fact, just ban any email providers that attackers use instead of trying to solve the issue.
[+] [-] nerevarthelame|7 months ago|reply
However, blocking an email domain will dissuade only the lowest effort attacker. If the abusers think slopsquatting is effective, they'll easily be able to find (or create) an alternative email provider to facilitate it.
And assuming that the attacks will persist, sometimes it's better to let them keep using these massive red flags like an inbox.ru email so that it remains a reliable way to separate the the fraudulent from legitimate activity.
[+] [-] halJordan|7 months ago|reply
[+] [-] WmWsjA6B29B4nfk|7 months ago|reply
[+] [-] bobbiechen|7 months ago|reply
* 2025-06-09 first user account created, verified, 2FA set up, API Token provisioned
* 2025-06-11 46 more user accounts created over the course of 3 hours
* 2025-06-24 207 more user accounts created over the course of 4 hours
I do run https://bademails.org , powered by the same disposable-email-domains project, and I'll be the first to say that it only cuts out the laziest of attempts. Anyone even slightly serious has cheap alternatives (25 to 100+ accounts for $1 on popular email hosts).
[+] [-] ajross|7 months ago|reply
There has to be a level of community validation for anything automatically installable. The rest of the world needs to have started out by pulling and building/installing it by hand and attesting to its usefulness, before a second level (e.g. Linux distro packagers) decide that it's good software worth supplying and supporting.
Otherwise, at best the registries end up playing whack-a-mole with trickery like this. At worst we all end up pulling zero days.
[+] [-] woodruffw|7 months ago|reply
The bigger problem is that people want to have their cake and eat it too: they want someone else to do the vetting for them, and to receive that added value for no additional cost. But that was never offered in the first place; people have just sort of assumed it as open source indices became bigger and more important.
[+] [-] jowea|7 months ago|reply
[+] [-] extraduder_ire|7 months ago|reply
This is easy to game, and in some ways has been pre-gamed. So it wouldn't really be a measure of validation, but would be interesting to see.
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] reconnecting|7 months ago|reply
You can use open-source security analytics (1) to detect fraudulent accounts instead of blocking domain names. Blocking domains only shows your system is fragile and will likely just shift the attackers to use other domains.
Feel free to contact us if you need assistance with setup.
(1) https://github.com/tirrenotechnologies/tirreno
[+] [-] lucb1e|7 months ago|reply
Like with IP ranges that send a lot of spam/abuse, it's the provider's space in the end. If the sender has no identification (e.g. User-Agent string is common for http bots) and the IP space owner doesn't take reasonable steps, the consequence is (imo) not to guess who may be human and who may be a bot, but to block the IP address(es) that the abuse is coming from. I remember our household being blocked once when I, as a teenager, bothered a domain squatter who was trying to sell a normal domain for an extortionary price. Doing a load of lookups on their system, I couldn't have brought it down from an ADSL line but apparently it was an unusual enough traffic spike to get their attention, as was my goal, and I promptly learned from the consequences. We got unblocked some hours after my parent emailed the ISP saying it wouldn't happen again (and it hasn't)
You don't have to look very far on HN to see the constant misclassifications of people as bots now that all the blocking has gotten seven times more aggressive in an attempt to gatekeep content and, in some cases, protect from poorly written bots that are taking it out on your website for some reason (I haven't had the latter category visit my website yet, but iirc curl/Daniel mentioned a huge outbound traffic volume to one scraper)
[+] [-] PokemonNoGo|7 months ago|reply
[+] [-] reconnecting|7 months ago|reply
[+] [-] Scene_Cast2|7 months ago|reply
[+] [-] mananaysiempre|7 months ago|reply
[+] [-] f311a|7 months ago|reply
[+] [-] miketheman|7 months ago|reply
[+] [-] joecool1029|7 months ago|reply
This project has an allowlist you can submit a PR to so it doesn't get sucked back in every time people submit outdated lists of free email provider domains.
I've sent dozens of PR's to de-list my domains on various projects across Github and it's like fighting the sea, but the groups making opensource software to use these lists are at least very apologetic and merge the PR's quickly.
However, the biggest ASSHOLES are Riot Games. I've reached out to and they will not ban new user registrations on my domains. I eventually just had to block all the new account registration emails for League of Legends I was getting in my catch-all. The maintainer of the tool people were using to make new accounts was very responsive and apologetic (quickly merged my PR) but it doesn't stop people who used the old versions of it from continuing.
[+] [-] klntsky|7 months ago|reply
[+] [-] OldfieldFund|7 months ago|reply
[+] [-] Nickste|7 months ago|reply
You can check it out with: pip install safety && safety init
[+] [-] nzeid|7 months ago|reply
[+] [-] zahlman|7 months ago|reply
[+] [-] akerl_|7 months ago|reply
[+] [-] Sohcahtoa82|7 months ago|reply
Any time you introduce humans manually reviewing things, the attackers win instantly by just spamming it with garbage.
[+] [-] stavros|7 months ago|reply
[+] [-] lysace|7 months ago|reply
[+] [-] perching_aix|7 months ago|reply
> See a previous post for a previous case of prohibiting a popular email domain provider.
[+] [-] reconnecting|7 months ago|reply
[+] [-] unknown|7 months ago|reply
[deleted]
[+] [-] ynbl_|7 months ago|reply
> Please enter the phone number you'll use to sign in to Mail instead of a password. This is more secure.
[+] [-] codedokode|7 months ago|reply
[+] [-] Tiberium|7 months ago|reply
The blog post references [0] which makes it seem like the maintainers do, in fact, just ban any email providers that attackers use instead of trying to solve the issue.
[0] https://blog.pypi.org/posts/2024-06-16-prohibiting-msn-email...
[+] [-] snickerdoodle12|7 months ago|reply
[+] [-] sysrestartusr|7 months ago|reply
[deleted]