PyPI Prohibits inbox.ru email domain registrations

https://blog.pypi.org/posts/2025-06-15-prohibiting-inbox-ru-emails/

by miketheman • 1 year ago

131 105 1 year ago

blog.pypi.org

Oh hey, I was the person who reported this.

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.

takipsizad2• 1 year ago

pypi has blocked signups from outlook before. I don't think they care about the impact it creates

miketheman2• 1 year ago

Thank you!

f311a• 1 year ago

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

miketheman2• 1 year ago

Sadly the majority of this data is not externally visible.

ajross6• 1 year ago

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.

jowea3• 1 year ago

And who is going to do all this vetting and with what budget?

ajross6• 1 year 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.

perching_aix5• 1 year 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?

em-bee5• 1 year ago

not reviewing submissions is a big problem. i know i can trust linux distributions because package submissions are being reviewed. and especially becoming a submitter is an involved process.

if anyone can just sign up then how can i trust that? being maintained by the PSF they should be able to come up with the funding to support a proper process with enough manpower to review submissions. seems rubygems suffers from the same problem, and the issues with npm are also well known.

this is one of those examples where initially these services were created with the assumption that submitters can be trusted, and developers/maintainers work without financial support. linux distributions managed to build a reliable review process, so i hope these repositories will eventually be able to as well.

woodruffw9• 1 year ago

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.

ajross6• 1 year ago

a latent assumption within the model has always been that you vet your packages before installing them

That is precisely the broken part. There are thousands of packages in my local python venv. No, I didn't "vet" them, are you serious? And I'm a reasonably expert consumer of the form!

codedokode4• 1 year ago

That's actually what Linux distributions provide free of charge: a list of verified packages. However, a sustainable solution would be a commercial vendor (like Kaspersky for example) providing a safe feed of packages on a paid basis.

andrewaylett• 1 year ago

There's a whole industry full of people who will charge you for them to do at least a smidge of vetting. And it's not entirely snake oil: finding and publishing vulnerabilities is good advertising.

I might find the likes of Snyk somewhat annoying when I'm required to have them audit projects at work (they aren't as good as Renovate or even Dependabot at raising version bumps, and most of the alerts are false positives for our environment) but I mostly appreciate that they exist.

extraduder_ire• 1 year ago

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.

nerevarthelame• 1 year ago

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.

halJordan• 1 year ago

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.

genidoi• 1 year ago

The problem with using random real world situations as analogies for niches within Software Engineering is that they're not only (almost) ways wrong, but always misrepresentative of the situation in it's entirety

reconnecting9• 1 year 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.

(1) https://github.com/tirrenotechnologies/tirreno

PokemonNoGo2• 1 year ago

Odd installation steps.

reconnecting9• 1 year ago

Can you elaborate, please?

pests• 1 year ago

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.

theamk• 1 year ago

Totally normal for PHP software, and that's a primary reason of why PHP apps have such a bad security reputation. Note:

- The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want.

- The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options.

Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place.

Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)

lucb1e7• 1 year ago

Care to elaborate? They seem bog-standard to me

lucb1e7• 1 year ago

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)

reconnecting9• 1 year ago

I like the part about leaving the neighborhood blocked from internet access. Did neighbours find out that it was because of you?

However, email accounts could be stolen, and this makes the email provider a victim as well.

This particular case sounds very simple, and I'm quite confident that if we dig further, it's highly possible that all accounts use some pattern that would be easy to identify and block without hurting legitimate users.

reconnecting9• 1 year ago

Sent a letter to security@.

lysace3• 1 year ago

I don't understand why this is newsworthy. Spam never ends.

perching_aix5• 1 year ago

Because of:

See a previous post for a previous case of prohibiting a popular email domain provider.

lysace3• 1 year ago

That was outlook.com/hotmail.com. So? Incompetent/malicious/disengaged mail providers come in all shapes and forms.

reconnecting9• 1 year ago

Online fraud will never end, but it is possible to make it much more expensive and shift attackers to other victims.

nzeid2• 1 year 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?

stavros• 1 year ago

Probably because that would be too expensive for PyPI.

akerl_5• 1 year ago

Who would do the manual review?

vips7L• 1 year ago

A staffer from the Python foundation? This is how maven central works. Someone physically verifies that you own the reverse domain of your package.

zahlman2• 1 year ago

PyPI's human resources are extremely strained. (The technical side also only exists thanks to Fastly's generosity.)

Sohcahtoa82• 1 year ago

Because that would easily get DoS'd.

Any time you introduce humans manually reviewing things, the attackers win instantly by just spamming it with garbage.

Tiberium• 1 year ago

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.

[0] https://blog.pypi.org/posts/2024-06-16-prohibiting-msn-email...

snickerdoodle125• 1 year ago

What is the core issue and how would you solve it?

WmWsjA6B29B4nfk• 1 year 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• 1 year 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• 1 year 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.

klntsky• 1 year ago

Google accounts are $0.50 on hstock. It's impossible to stop spam

OldfieldFund• 1 year ago

Yup, and Microsoft with access tokens are $0.05

ynbl_• 1 year ago

and mail.ru is not even a real internet service:

Please enter the phone number you'll use to sign in to Mail instead of a password. This is more secure.

codedokode4• 1 year ago

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.

joecool1029• 1 year ago

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.

Nickste• 1 year ago

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

PyPI Prohibits inbox.ru email domain registrations

Related Stories