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.
reconnecting · 46m ago
'tirreno guy' here.
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.
Id say it’s big standard for php apps and have been for awhile. Wordpress has a similar install flow. Docker images are provided tho.
reconnecting · 34m ago
Yes, Matomo/Piwik, WordPress, and ProcessWire have more or less the same installation steps, but maybe we missed something along the way.
reconnecting · 41m ago
Can you elaborate, please?
kassner · 32m ago
composer install should be pretty much what one needs nowadays. Any installing scripts (although you really shouldn’t) can also be hooked into it.
snickerdoodle12 · 24m ago
The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software.
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
LeifCarrotson · 10m ago
> Huh, so anyone who can access my web server can access the installation script?
"Obviously", the server should not be accessible from the public Internet while you're still doing setup. I assume it should still behind a firewall and you're accessing it by VPN. Only after you're happy with all the configuration and have the security locked down tight would you publish it to the world. Right?
reconnecting · 5m ago
Honestly, I'm not sure why someone would put security analytics on a publicly accessible domain. This is an internal platform that doesn't need to be accessible through the open internet. Communication over a private network is more than enough in this case.
kstrauser · 17m ago
I'll side with you here. This gives attackers a huge window of time in which to compromise your service and configure it the way they want it configured.
This is not something specific to tirreno, as it's the usual installation process of any PHP application.
WmWsjA6B29B4nfk · 26m ago
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.
bobbiechen · 9m ago
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).
ajsnigrutin · 2m ago
Yep, and if a human is doing that, it's easy to switch over to a different email provider, until that gets banned too, then another, until you can't do anything without a gmail address anymore.
nzeid · 32m ago
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?
akerl_ · 9m ago
Who would do the manual review?
zahlman · 6m ago
PyPI's human resources are extremely strained. (The technical side also only exists thanks to Fastly's generosity.)
stavros · 17m ago
Probably because that would be too expensive for PyPI.
sysrestartusr · 4m ago
> leading to end-user confusion
not really, though. Source?
I understand the whole thing as a broad hint.
Probably by some fatso in a pink shirt, lying in his 6 figure Villa on a Florida beach and just playing baddy with his new CrewAI on one of the more crowded sub-to-super-nerdy turfs. Of course he's gonna pick a Russian domain.
Trendy
Scene_Cast2 · 1h ago
Oh hey, I was the person who reported this.
mananaysiempre · 47m ago
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.
takipsizad · 41m ago
pypi has blocked signups from outlook before.
I don't think they care about the impact it creates
dewey · 22m ago
I know a bunch of sites who do that and the problem is usually that register emails get flagged by outlook and never arrive, causing a lot of support burden. Easier to then nudge people into the direction of Gmail or other providers that don't have these issues.
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.
What is the core issue and how would you solve it?
klntsky · 8m ago
Google accounts are $0.50 on hstock. It's impossible to stop spam
lysace · 37m ago
I don't understand why this is newsworthy. Spam never ends.
perching_aix · 36m ago
Because of:
> See a previous post for a previous case of prohibiting a popular email domain provider.
lysace · 34m ago
That was outlook.com/hotmail.com. So? Incompetent/malicious/disengaged mail providers come in all shapes and forms.
perching_aix · 29m ago
The implication is that this other email host also being one of the popular ones means there'll be a more widespread user impact than when they block smaller providers. So just like with Outlook, they put out this statement on why they're doing this.
lysace · 27m ago
Ah, I see your point.
Although: I don't think the kind of developers that use low quality email providers like that follow HN.
Edit: Remember those 8+ hours back in 1999 when all Microsoft Hotmail accounts were wide open for perusal?
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.
jowea · 35m ago
And who is going to do all this vetting and with what budget?
perching_aix · 19m ago
Could force package publishers to review some number of other random published packages every so often. (Not a serious pitch.) Wouldn't create any ongoing extra cost (for them) I believe?
akerl_ · 8m ago
Do you have a serious pitch?
perching_aix · 8m ago
Not really. The people who have an actual direct stake in this can go make that happen, I'm sure they're much better positioned to do so anyhow. For me, it's a fun thing to ponder, but that's all.
akerl_ · 5m ago
It looks like they are deciding how to approach this. The article you’re commenting on is about how they identified malicious behavior and then blocked that behavior.
It seems odd to pitch suggestions for other things they ought to do but then couch it with “well I’m not being serious” in a way that deflects all actual discussion of the logistics of your suggestion.
perching_aix · 3m ago
Yeah, so I've read. Good for them, I suppose.
> in a way that deflects all actual discussion of the logistics of your suggestion
You seem to be mistaken there: I very much welcome a discussion on it. Keyword being "discussion". Just let's not expect an outcome anything more serious than "wow I sure came up with something pretty silly / vaguely interesting".
ajross · 22m ago
Right now: we are. And we're collectively paying too much for a crap product as it stands.
Debian figured this out three decades ago. Maybe look to them for inspiration.
zahlman · 4m ago
> And we're collectively paying too much for a crap product as it stands.
Last I checked, we pay $0 beyond our normal cost for bandwidth, and their end of the bandwidth is also subsidized.
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.
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
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
> Navigate to http://your-domain.example/install/index.php in a browser to launch the installation process.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
"Obviously", the server should not be accessible from the public Internet while you're still doing setup. I assume it should still behind a firewall and you're accessing it by VPN. Only after you're happy with all the configuration and have the security locked down tight would you publish it to the world. Right?
In my recent experience, you have about 3 seconds to lock down and secure a new web service: https://honeypot.net/2024/05/16/i-am-not.html
* 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).
not really, though. Source?
I understand the whole thing as a broad hint.
Probably by some fatso in a pink shirt, lying in his 6 figure Villa on a Florida beach and just playing baddy with his new CrewAI on one of the more crowded sub-to-super-nerdy turfs. Of course he's gonna pick a Russian domain.
Trendy
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...
> See a previous post for a previous case of prohibiting a popular email domain provider.
Although: I don't think the kind of developers that use low quality email providers like that follow HN.
Edit: Remember those 8+ hours back in 1999 when all Microsoft Hotmail accounts were wide open for perusal?
https://www.theregister.com/1999/08/30/massive_security_brea...
https://www.theguardian.com/world/1999/aug/31/neilmcintosh.r...
https://www.salon.com/1999/09/02/hotmail_hack/
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.
It seems odd to pitch suggestions for other things they ought to do but then couch it with “well I’m not being serious” in a way that deflects all actual discussion of the logistics of your suggestion.
> in a way that deflects all actual discussion of the logistics of your suggestion
You seem to be mistaken there: I very much welcome a discussion on it. Keyword being "discussion". Just let's not expect an outcome anything more serious than "wow I sure came up with something pretty silly / vaguely interesting".
Debian figured this out three decades ago. Maybe look to them for inspiration.
Last I checked, we pay $0 beyond our normal cost for bandwidth, and their end of the bandwidth is also subsidized.