四段还是六段？outlook-auto-register产出格式与5种邮件令牌模式完整解析

outlook-auto-register 是一个纯协议的 Microsoft Outlook 批量注册工具，它的核心产出是「四段 / 六段 combo」账号文件。这篇文章帮你彻底搞清楚：四段与六段到底差在哪、5 种邮件令牌模式分别走哪条读信通道、以及新手应该选哪种产出格式。看完即可对号入座，避免选错模式导致注册完读不了信。

一、先搞懂：combo 的「段」是什么？

注册成功后，每个账号会被落盘成一行----分隔的文本（称为 combo），这是本项目最核心的交付格式。

combo 的拼接逻辑集中在 model/entity/register_models.py 的to_combo()方法中，三种形态一目了然：

四段（graph） : email----password----client_id----refresh_token 六段（recovery） : email----pwd----cid----rt----recovery_email----recovery_pwd 六段（dual） : email----pwd----cid----graph_rt----login_cid----login_rt

⚠️ 注意：两种六段完全不同。recovery六段的后两段是「恢复邮箱账号」，dual六段的后两段是「第二枚登录 refresh_token」（用于第三方 SSO 登录）。选错格式，下游工具会直接解析失败。

二、Web 控制台的三种产出格式怎么选？

在「批次注册」页可以下拉选择产出格式，界面默认推荐Graph 六段式：

三个模式的核心区别在「注册同意阶段授权的 scope」上，所有 scope 定义见 config/constants.py：

• graph：授权Mail.ReadWrite / Mail.Send / User.Read，走 Graph API 读信，注册完即可用；
• graph_recovery：第 4 段仍是 Graph refresh_token，额外绑定 proofs 恢复邮箱；
• login_exe：授权 Thunderbird 完整 scope（IMAP/POP/SMTP + EWS + Mail.Read/Send），是「卖家同款」出货格式。

三、5 种邮件令牌模式逐个拆解

真正决定「第 4 段令牌能不能读信」的，是环境变量OUTLOOK_MAIL_TOKEN_MODE。源码注释中有一段非常关键的实测结论（config/constants.py）：

新注册的 outlook.com 邮箱IMAP/POP 协议开关默认关闭，且新号短期内无法开启；IMAP 令牌虽然能拿到，XOAUTH2 登录会报User is authenticated but not connected→ 不可用。

这就是新手最容易踩的坑：默认走 IMAP 的模式在新号上读不了信。五种模式对比如下：

1.graph（默认，推荐）

• 走graph.microsoft.com/v1.0/me/messages读信；
• 完全绕开 IMAP 协议开关，注册完立即可用；
• 对应产出即「四段 combo」。

2.outlook_rest

• 走outlook.office.com/api/v2.0/me/messages（Outlook REST API）；
• 同样绕开 IMAP 开关，与graph互为备份通道；
• 三者复用同一个 Thunderbird 公共 client_id，无需自建应用。

3.imap/login_exe/recovery

• 传统 IMAP 令牌，仅老号或已手动开启 IMAP 的号可用；
• login_exe（即recovery别名）在注册同意时就把 Mail.Read/EWS 一起授权，新号可走 Outlook REST 读信，并绑定恢复邮箱产出六段式，属于卖家出货标准格式。

4.dual（双令牌）

• 同一次注册里做两次 code→token 交换，产出两枚 refresh_token：
  • token#1：Graph 收码/读信；
  • token#2：登录授权（openid profile offline_access），供第三方「用微软账号登录」SSO；
• 产出六段 combo，第 5/6 段是登录令牌的 client_id 与 refresh_token，详见 config/constants.py 中 token#2 的 scope 规范。

5. 组合使用（令牌模式 × 产出格式）

令牌模式决定「第 4 段是什么令牌」，产出格式决定「落盘几段」。例如：

• graph令牌 +graph_recovery产出 → Graph 六段式（Web 默认推荐）；
• login_exe令牌 + 恢复邮箱绑定 → IMAP 六段式；
• dual令牌 → 双令牌六段。

四、产出格式如何导出？

账号池页支持一键导出，后端接口会自动识别段数（controller/account_controller.py）：

• 导出graph：只输出前四段，文件为accounts_graph.txt；
• 导出recovery：有恢复邮箱的账号输出六段，其余自动降级为四段，响应头X-Export-Six会告知实际六段行数；
• 导出dual：有登录令牌的账号输出六段。

所有账号统一存储在 SQLite（accounts/outlook.db），表结构见 docs/DATABASE.md；导入时也支持自动识别四段/六段并归位到combo与combo_dual两个字段。

五、保活：令牌拿到之后怎么用

refresh_token 会过期，项目内置了保活链路：按 scope 自动路由到 Graph / Outlook REST / IMAP 通道，定时续期并读信自检（service/account/keepalive_service.py）。

页面文案给出了防封要点：默认认 Graph 读信、不强开 IMAP，每个号 2–3 天保活一次即可。完整防封策略（代理选型、并发抖动、产出自检）见 scripts/ANTIBAN.md。

六、新手快速决策清单

• 🎯只想要能读信的令牌→ 选graph四段式，最简单；
• 🛡️担心封号、需要恢复邮箱→ 选graph_recovery六段式（推荐，Web 默认项）；
• 📦对齐卖家标准出货→ 选login_exeIMAP 六段式；
• 🔐下游需要「微软账号登录」SSO→ 选dual双令牌六段；
• ❌新号千万别指望默认 IMAP 读信→ IMAP 开关默认关闭，优先 Graph 通道。

七、常见问题 FAQ

Q1：四段和六段下游工具通用吗？

不通用。下游解析器按段数取值：四段工具拿到六段会误把恢复邮箱当 client_id。导入本项目时两种都兼容（controller/account_controller.py），但交付前请按约定格式导出。

Q2：为什么第 4 段 refresh_token 前缀是M.C5xx之类？

这是 Microsoft 的 Refresh Token 版本标识，属正常现象，不代表令牌无效。可用 scripts/check_imap.py 对单条四段 combo 做可用性校验，Web 控制台的「测活」页也提供同样的单条校验入口。

Q3：注册失败会影响已产出的 combo 吗？

不会。每个账号独立落盘（SQLiteaccounts表 + combo 字段），批次内失败账号不会污染成功账号的导出结果，可单独补跑。

本项目仅供学习与研究，使用者需自行评估并遵守 Microsoft 服务条款。真实注册前请配置好恢复邮箱池，禁止批量 skip proofs（OUTLOOK_SKIP_PROOFS=1仅调试用）。