PyPI Prohibits inbox.ru email domain registrations

Domain ban rationale and scope

• Commenters note inbox.ru is a major Russian free email provider, so some legitimate users may be affected.
• Confusion over why only inbox.ru is banned when mail.ru and related domains have identical signup flows.
• Others reference earlier bans (e.g., Outlook / MSN) as part of a broader policy against providers heavily used for mass malicious signups.
• Some say providers also get banned when they mishandle or block verification emails, creating support burden.

Effectiveness and limits of email-domain bans

• Several argue banning a single popular domain only stops the lowest-effort attackers; cheap accounts for major providers are widely available.
• View that banning domains is still a reasonable “low-hanging fruit” control: you incrementally raise attacker costs, even if they can adapt.
• Analogy drawn with blocking abusive IP ranges: ultimately you pressure the provider to deal with its bad actors.

Is the package index model broken?

• Critics claim the “anyone can publish, one-command install” model (PyPI, npm, VS Code extensions, etc.) is structurally insecure, leading to typosquatting/slopsquatting and whack-a-mole responses.
• Some argue for distro-style curation: community validation first, then packaging by trusted maintainers, possibly plus sandboxing.
• Others counter that fully vetted indices would need dozens of full-time reviewers and are economically infeasible under current funding models.
• Rebuttal: the model has always implicitly assumed users vet dependencies themselves, but this is unrealistic when projects pull thousands of packages.

Linux distributions vs PyPI

• One camp: distros are more trustworthy because new maintainers are mentored, use signed keys, and packages are reviewed before inclusion.
• Another camp (including distro contributors): actual malware/code review is minimal; most effort checks packaging, not deep security. Large dependency trees often get rolled in without intense scrutiny.
• xz backdoor and long-lived vulnerabilities are cited as evidence that even distros don’t provide strong security guarantees.

Manual review and alternative mitigations

• Suggestions: manual review of first uploads for new accounts; requiring reviewers to vet random packages; domain-ownership checks like Maven Central.
• Pushback: PyPI is understaffed; manual queues are easy to DoS; domain validation proves identity, not integrity.
• Some propose more automated analysis: pagerank-style dependency metrics, security analytics platforms, and “firewall” CLIs that block known-malicious/typo/slopsquat packages.

Side thread: PHP app install patterns and security

• A promoted open-source security analytics tool using traditional PHP-style web installer receives criticism: web-accessible installer, manual deletion of install scripts, writable code directories.
• Others note this is still common in PHP apps (WordPress, Matomo, etc.), but also a major reason for PHP’s poor security reputation.
• Discussion branches into how quickly new hosts are probed (e.g., via certificate transparency logs) and the need to secure services within seconds of exposure.