GitHub 推荐：13K stars 邮箱 OSINT 神器 holehe：用一个忘记密码接口撬开 120+ 平台

GitHub: https://github.com/megadose/holehe

一句话总结

holehe 是一个用「忘记密码/注册/登录」等无告警接口，探测某个邮箱在 120+ 互联网平台是否注册过账号的开源 OSINT 工具——它把「邮箱」这个比 username 更稳定的身份锚点，做成了开源 CLI 中事实标准级的查询界面。

值得关注的理由

• 赛道卡位独特：在 Sherlock/Maigret 统治的 username OSINT 矩阵外，holehe 几乎独占「邮箱 → 跨平台账号」这条横轴，被 HackerTarget、OSINT Dojo 等多份独立评测列为”必装”
• 架构极简到极致：123 个 site module，每个就是一份「加一个 .py 文件 = 加一个数据源」的开源协作范本，单人主导却拉到了 34 个贡献者
• OPSEC 友好是产品化核心承诺：「Does not alert the target email」不仅写在 README 的 badge 里，还通过 -NP 黑名单（adobe / mail_ru / odnoklassniki / samsung）做了硬约束——这是它能进入企业 OSINT 调查员工具箱的关键
• 独立开发者的”开源+SaaS”双轨样本：作者把 holehe 作为 GPLv3 开源顶层漏斗，把聚合报告/在线版商业化路径留给社区运营的 osint.industries，是单人 OSINT 工具商业化的典型范式

项目展示

终端 ASCII 风格输出样张，工具核心 value prop 一图胜千言——「用邮箱查出某人在哪些平台开了账号」

CLI 实时运行动图，展示 trio + asyncio + tqdm 进度条的实际效果

项目画像

维度	数据
GitHub	https://github.com/megadose/holehe
Star / Fork	13,091 / 1,742（OSINT 细分领域头部）
Watcher	282
代码行数	7,310 行（Python 99.8% / 152 个 .py 文件）
代码/注释比	9.2:1
项目年龄	约 6 年（首次提交 2020-08-22，仓库创建 2020-06-25）
开发阶段	已停滞（最近 push 2024-09-10，已 11 个月无主线提交）
贡献模式	单核 + 社区补丁（主作者占 73.1% commits；34 名贡献者）
热度定位	小众精品里的大众热门——OSINT 圈内被广泛引用，但开源生态整体小众
质量评级	代码 B / 文档 C / 测试 F / CI C / 错误处理 B+
License	GPL-3.0
官方主页	无（README + DeepWiki 是主要文档面）

作者视角：为什么存在这个项目

创始人/作者背景

Palenath（megadose）是一位独立 OSINT 工具开发者，账号 7.2 年、粉丝 2,888、20 个公开仓库，公开 bio 写”Behind you”——戏谑式匿名是他的品牌标签。他矩阵化运营 8+ 个 OSINT 工具：

• holehe（邮箱 → 跨平台账号）
• toutatis（Instagram 用户情报）
• ignorant（电话号 → 注册账号，username 维度）
• OnionSearch（暗网搜索）
• Quidam（匿名身份关联）

这种矩阵化布局说明他不是”碰巧写了一个 OSINT 工具的人”，而是把 OSINT 当作产品线在经营——holehe 在这个矩阵里担任「以邮箱为枢轴，桥接到 toutatis/ignorant 的 username 维度」的连接件位置。

问题判断

2020 年这个时点，作者观察到三个窗口期叠加：

1. username 路径已饱和：英美主流社交平台 username 维度工具（Sherlock/Maigret）覆盖度已接近上限，但海量 SaaS / CRM / 论坛 / 本地化服务只在 email 维度做唯一性约束
2. password recovery 接口仍是 oracle：2018-2020 年间，遗忘密码接口被广泛用作「账号枚举 oracle」——这窗口期被 socialscan / UhOh365 等先驱项目证实
3. GitHub 未下达强 abuse 政策：自动枚举行为尚未被明确封禁

他看到的机会是：username 维度的工具圈层（ignorant、Maigret 早期）已存在，但「email × 跨平台」仍是空白——holehe 正好补位。

解法哲学

OPSEC 优先于功能完整性。他明确选择不做什么：

• 不抓 profile/followers/posts——只问「该邮箱是否已注册」
• 不接入泄露库（避免法律灰区与时效性负担）
• 不向被调查邮箱发送任何邮件（核心承诺，被 issue #12 与 README badge 强化成卖点）
• 不内嵌 proxy/iptables 逻辑（README 写 “Rate limit? Change your IP.”——把责任推给操作者）

最直观的体现：nopasswordrecovery 黑名单硬编码 4 个站点（adobe / mail_ru / odnoklassniki / samsung）——它们的 password-recovery 接口可能触发邮件/SMS，于是被默认剔除。这是一种「宁可少做也不要越界」的姿态。

战略意图

README 显著位置链接到 osint.industries/——一个 SaaS 平台，定位为「holehe 在线版 + 更广数据」。作者把 holehe 作为「垂直工具 = 开源 + GPLv3（阻止被封闭转售）+ 营销漏斗顶层」，把离线能力留给社区，把云端聚合报告留给付费 SaaS。BTC 捐赠地址 + FUNDING.yml + osint.industries SaaS 形成「捐赠 + 雇主/咨询 + SaaS 订阅」三轨变现层。

核心价值提炼

创新之处

创新点	新颖度	实用性	可迁移性
”邮箱作为稳定身份锚点”系统化	3/5	5/5	4/5
trio nursery + Instrument 钩子进度条	3/5	4/5	4/5
”被动 OSINT”承诺（Does not alert the target email）作为产品差异化标签	2/5	5/5	3/5
”一行 commit = 一个 module”的极简 contribution 协议	4/5	4/5	5/5

新颖×实用最强的是”邮箱身份锚点的产品化深度”——虽然 socialscan/UhOh365 概念不首发，但 holehe 把这件事做到 123 个站点、4 种 method 分类、统一 JSON schema 的工程深度，是行业独一档。

可复用的模式与技巧

1. pkgutil.walk_packages + 文件名即协议名：子目录扫描 → 自动 import → 按 segment 取函数引用；适用场景：subdomain enum / endpoint fuzzer / 字典攻击等「加一个数据源 = 加一个文件」的工具
2. method 枚举标签 + 表格化文档：用单一字符串字段给一类网络行为打 tag，README 用 Markdown 表格展示全集；适用场景：OSINT/扫描器类的 API 表面分类
3. try/except → rateLimit: True, exists: False 降级：把所有异常当成「反爬了，我跳过去」；适用场景：多目标并行、容忍丢精度的批量查询
4. 运行时 PyPI 版本自检 + subprocess 自升级：启动时拉一次 PyPI，落后则 pip install -U；适用场景：单人维护的小工具（成本最低的版本传播机制）
5. trio Instrument 桥接 tqdm：把 async 调度事件转进度条 tick；适用场景：任何 trio-based 长任务加进度可视化
6. 统一 JSON schema + others 自由扩展字段：主键稳定，扩展走 Pascal-Case dict；适用场景：聚合型 CLI/SDK 给下游消费者用

关键设计决策

决策 1: trio + httpx.AsyncClient 全异步并发（替代 asyncio）

• 问题: 120+ 站点串行探测耗时不可接受，但又要支持动态取消/优雅停机
• 方案: trio.run(maincore) 顶层驱动；trio.open_nursery() 并发孵化 123 个 launch_module 子任务；统一共享一个 httpx.AsyncClient(timeout=10)（TCP 连接池复用）
• Trade-off: trio 比 asyncio 生态小（少 LLM 集成、少中间件），换来更干净的取消语义（nursery-based structured concurrency）
• 可迁移性: 高。任何「多目标无共享状态」的并发任务（爬虫/扫描器/批量健康检查）都可套用同一骨架

决策 2: “四种探测术”抽象（register / login / password recovery / other）

• 问题: 不同平台的「账号是否存在 oracle」分布在哪条 API 路径上没有统一规律，必须逐站探索
• 方案: 每个 module 在最上面声明 method = "..." 一个枚举字符串，README 用一个表格把 123 个 site × method × frequent_rate_limit 全部展示出来
• Trade-off: 这是「贴标签型」抽象，不是 polymorphism 抽象——它不能在代码里被 dispatch，只能被人眼分类
• 可迁移性: 中。可以借鉴到一切「枚举型 OSINT」项目（username/phone/IMEI/leaked handle 等）

决策 3: 错误处理—OPSEC 友好的”按站点降级而非整体失败”

• 问题: 并发 123 个请求，必然有站点 429/超时/被拦截；任何一个异常导致全盘崩溃既不安全也低效
• 方案: 每个 module 函数体内 1-3 个 try/except，异常一律降级为 rateLimit: True, exists: False；launch_module 包裹一层 except Exception 兜底；UI 区分四种状态 [+]/[-]/[x]/[!]
• Trade-off: 通过静默吞错来避免单点失败换取鲁棒性，但失去可诊断性—Issue #37（“flickr.py show allways Rate_limit”）就是用户根本看不出来为什么某些 module 一直返回 [x]
• 可迁移性: 高

决策 4: 无 Git Tag / Release，版本号只活在 setup.py 与 core.py 两个常量里

• 问题: 项目从未打过任何 tag（已确认 git tag 输出为空）
• 方案: 启动时通过 httpx.get("https://pypi.org/pypi/holehe/json") 拉 PyPI 最新版本号，与本地 __version__ 对比，不一致则 subprocess.Popen(["pip", "install", "--upgrade", "holehe"]) 后 exit()
• Trade-off: 把”什么时候发布”与”什么时候发布版本号”完全解耦——好处是单人维护无流程负担，坏处是 PyPI 是事实上的唯一时间轴，PyPI 不可达 = 启动阻塞
• 可迁移性: 低。这种 auto-upgrade-on-launch 是 OSINT 小工具圈的古老 hack 模式，长远来看应当被现代 pip install -U holehe 或 uv 取代

竞品格局与定位

竞品对比矩阵

维度	holehe	Sherlock	Maigret	h8mail	SpiderFoot
身份锚点	email	username	username	email	多维
覆盖站点数	120+	400+	3000+	依赖泄露库	200+ 模块
是否触发告警	不告警（OPSEC 友好）	几乎不告警	可能留 UA/referer	不适用	不适用
数据来源	实时接口 oracle	实时接口 200/404	实时 profile 抓取	历史泄露库匹配	外部 API 聚合
部署难度	CLI 一行	CLI 一行	CLI 一行	CLI + 泄露语料	重型平台
输出结构	统一 JSON + CSV + Maltego	彩色文本 + CSV	dossier + 头像 + PDF	文本报告	多维聚合
社区规模	13K stars / 34 贡献者	89K stars	36K stars	8K stars	21K stars
License	GPL-3.0	MIT	MIT	MIT	GPL-2.0
维护状态	停滞 11 个月	活跃	活跃	活跃	活跃

差异化护城河

• 技术护城河：email 锚点的稳定性，username 工具无法复制；OPSEC 友好承诺 + nopasswordrecovery 黑名单的硬约束
• 生态护城河：GPLv3 + 123 模块的「开源社区合作社」模式，与 Sherlock/Maigret 错位而非正面对抗
• 信任护城河：与 osint.industries SaaS 形成的「开源+SaaS」双轨，Maltego 官方 transform 集成

竞争风险

• 模块会陈旧（Flickr issue #37 反映长期未维护带来的 false rate-limit）
• Docker 镜像 issue #232 长期未更新
• UA 池停留在 2010s 中期（Chrome 41 / Firefox 40 时代），现代反爬系统会一眼识破
• 单纯换 UA 已不够，UA 与企业 IP 风控日益严格
• 作者主线停摆，模块修复合入速度慢，h8mail 之类的”泄露库路线”在隐私法规收紧后可能获得不对称优势

生态定位

在 OSINT 工具矩阵中，holehe 扮演 “邮箱维度”的代表——与 username 工具（sherlock/maigret）正交，与 breach 工具（h8mail）互补，与综合平台（spiderfoot/theHarvester）错位。是 Recon-ng / Maltego 工作流的标准 transform。

套利机会分析

• 信息差: 已被充分发现，无「低关注但高质量」套利空间；但「停滞 11 个月」意味着如果有人愿意接手维护 UA 池/模块刷新，做一个「holehe 2026 fork」是合理切入口
• 技术借鉴: pkgutil.walk_packages 动态加载 + from X import * 极简 module 协议是 5 星可复用模式；trio Instrument 钩子进度条是 4 星可复用技巧；「按 method 枚举打 tag」是 3 星可借鉴的运营模式
• 生态位: 在 Recon-ng / Maltego 工作流里，holehe transform 是事实标准；「email oracle」是 OSINT 工具矩阵中独立的一格
• 趋势判断: 项目主线停滞是最大风险信号；UA 池陈旧和 Docker 镜像失效是当下立即的痛点；企业 OSINT 合规需求在上升（GDPR 收紧反而强化了”被动 OSINT”卖点）——这是项目最后可能复活的机会

风险与不足

1. 项目已实质停摆（最近 push 2024-09-10，main 分支无 11 个月）
2. 65 open issues + 38 open PRs 无人维护，且 issue 列表里大量是普通用户「找回邮箱」的求助（非典型技术 issue），作者已无力回
3. 无任何测试覆盖（仓库内完全没有 tests/ 目录），模块正确性完全靠 issue 反馈
4. UA 池陈旧（多数停留在 Chrome 41 / Firefox 40 时代），对现代反爬系统形同裸奔
5. UA 与现代企业 IP 风控日益脱节——单纯换 UA 已不够
6. GPL-3.0 License 阻止被封闭转售，但也限制了在闭源产品中的集成
7. PyPI 是事实上的唯一时间轴——启动时拉 PyPI 不可达 = 启动阻塞
8. frequent_rate_limit 字段是约定而非机制——module 自报”我经常被限流”，但无运行时统计验证
9. OSINT 工具的双刃剑属性——受害用户通过 holehe 反向找回被盗账号（issue #262/#270），这给作者带来道德与法律维护负担；同类项目 Sherlock/Maigret 也有相同问题

行动建议

• 如果你要用它: 安装前先理解 OPSEC 风险（自己的 IP 可能被目标平台风控记录）；建议跑在 VPN/Tor 出口；接受模块有 20-30% 概率 false rate-limit；如果生产环境用，固定一个 fork 并自己维护关键 module
• 如果你要学它: 必读 4 个文件：
  • holehe/core.py（228 次修改的调度核心，trio nursery + 共享 httpx client + import_submodules 动态加载）
  • holehe/instruments.py（trio Instrument 钩子桥接 tqdm 进度条，少见的用法）
  • holehe/modules/software/adobe.py 或 holehe/modules/social_media/instagram.py（典型 module 范本）
  • setup.py（PyPI 自检升级 hack）
• 如果你要 fork 它: 改进优先级建议：
  1. 刷新 localuseragent.py 的 UA 池到 Chrome 120+/Firefox 120+ 现代版本
  2. 给 core.py 加 type hint（当前为零，linter 完全看不到 module 内符号）
  3. 引入 pytest + 至少 5 个 module 的 mock-based 集成测试
  4. 加 GitHub Actions test/release/publish-to-pypi 三件套，结束「PyPI 自检 hack」的脆弱时间轴
  5. 考虑把 nopasswordrecovery 黑名单改成 module 自报（让每个 module 自己声明「我会不会触发邮件/SMS」），更可维护
  6. 改用 pydantic 或 dataclass 约束 JSON schema 的 others 字段（当前是 Pascal-Case 字符串 dict，大小写空格都不一致）

知识入口

资源	链接
DeepWiki	https://deepwiki.com/megadose/holehe（已收录，模块架构清晰）
Zread.ai	未收录
关联论文	无（OSINT 工具非学术项目）
在线 Demo	无；可在线替代品为 https://osint.industries/（社区运营，作者未直接背书）
外部评测	Holehe vs Sherlock vs Maigret — 独立观点：三者互补而非取代
Maltego 集成	https://github.com/megadose/holehe-maltego（255 stars，作者官方 transform）
致谢线索	README 致谢 socialscan、UhOh365（概念前驱）+ mxrch（GHUNT 作者，架构借鉴）