适用场景：选择邮件客户端和邮箱服务时的安全隐私参考
一、中国邮箱”授权码”机制 vs OAuth 2.0
1.1 QQ 邮箱授权码工作原理
QQ 邮箱的”授权码”本质是 App-Specific Password（应用专用密码），与 OAuth 2.0 的 Authorization Code 是完全不同的概念。
工作流程：
- 登录 QQ 邮箱网页版 → 设置 → 账号与安全 → 安全管理
- 开启 POP3/IMAP/SMTP/Exchange/CardDAV/CalDAV 服务
- 通过短信验证生成授权码（16 位字符）
- 在第三方客户端中用授权码替代 QQ 密码进行 IMAP/SMTP 认证
技术特征：
– 协议层面仍然是 IMAP PLAIN/LOGIN 认证（Basic Auth），不是 OAuth 2.0
– 授权码是长期有效的静态凭证（直到手动撤销或修改密码）
– 163 邮箱（网易）采用完全相同的机制
服务器配置：
| 参数 |
值 |
| IMAP 服务器 |
imap.qq.com:993 (SSL) |
| SMTP 服务器 |
smtp.qq.com:465 (SSL) 或 :587 (STARTTLS) |
1.2 为什么中国邮箱不使用 OAuth 2.0
| 因素 |
说明 |
| 生态封闭性 |
腾讯/网易的 OAuth 生态面向自有平台（微信开放平台、QQ 互联），不对外提供邮件 OAuth |
| 历史路径 |
中国邮箱基于 IMAP/POP3 + 密码认证，授权码是安全增强而非协议升级 |
| 监管需求 |
授权码绑定手机号，天然满足实名验证要求 |
| 无商业动力 |
中国邮箱第三方客户端生态较小，缺乏推动 OAuth 的需求 |
1.3 IMAP Basic Auth vs OAuth 2.0
| 维度 |
Basic Auth (含授权码) |
OAuth 2.0 (XOAUTH2) |
| 认证方式 |
用户名 + 密码/授权码 |
短期 Access Token (Bearer Token) |
| IMAP 命令 |
AUTHENTICATE PLAIN |
AUTHENTICATE XOAUTH2 |
| 凭证生命周期 |
长期有效 |
Access Token 约 1 小时，Refresh Token 续期 |
| 密码暴露 |
存储在客户端，泄露即暴露 |
客户端不接触用户密码 |
| 撤销粒度 |
撤销码影响所有使用该码的客户端 |
可按应用/scope 精确撤销 |
| MFA 集成 |
不原生支持 |
授权流程中原生集成 MFA |
| 权限范围 |
完整邮箱权限 |
可通过 scope 限制（只读/只发送） |
1.4 Basic Auth 淘汰趋势
- Google：Workspace 于 2024 年 9 月 30 日关闭 LSA（Less Secure Apps），个人 Gmail 于 2025 年 3 月 14 日全面要求 OAuth（已完成）
- Microsoft：Exchange Online SMTP AUTH Basic Auth 从 2026 年 3 月 1 日开始逐步拒绝，最终延至 2026 年 12 月完全关闭（已确认，进行中）
淘汰原因：凭证重放攻击、无法整合 MFA、凭证分散存储在第三方客户端。
二、中国邮箱实名制
2.1 法律框架
| 法律法规 |
生效时间 |
核心要求 |
| 《网络安全法》第 24 条 |
2017.06 |
用户必须提供真实身份信息 |
| 《反恐怖主义法》第 21 条 |
2016.01 |
电信和互联网服务商须验证用户身份 |
| 《个人信息保护法》(PIPL) |
2021.11 |
规范个人信息处理，最小化原则 |
| 《反电信网络诈骗法》 |
2022.12 |
重申实名要求 |
核心原则：”后台实名、前台自愿” — 平台通过绑定手机号完成间接实名（手机号已与身份证绑定）。
2.2 与国际邮箱对比
| 维度 |
中国邮箱 (QQ/163) |
国际邮箱 (Gmail/Outlook/ProtonMail) |
| 注册要求 |
强制中国手机号（间接身份证级实名） |
手机号可选；ProtonMail/Tuta 不要求手机号 |
| 匿名性 |
后台完全实名 |
可相对匿名注册 |
| 法律依据 |
网络安全法强制 |
GDPR 强调数据最小化，无强制实名 |
| 执法配合 |
必须配合提供真实身份 |
需法律程序（搜查令/传票） |
| 数据管辖 |
数据必须存储在中国境内 |
跨境流动相对自由 |
2.3 隐私影响
- 邮箱 → 手机号 → 身份证 → 银行账户，形成完整身份链
- 同一手机号在多平台实名，可构建完整用户画像
- 实名数据泄露的隐私损害远超匿名账号
三、开源 vs 闭源邮件客户端
3.1 开源客户端
FairEmail
| 项目 |
详情 |
| 来源 |
F-Droid / Aurora Store / GitHub |
| 语言 |
Java + C++ |
| 隐私 |
内置追踪像素屏蔽、不收集用户数据、PGP/S-MIME 加密 |
| OAuth |
Play Store/GitHub 版支持 Gmail OAuth；F-Droid 版不支持（Google 仅授权官方签名版） |
K-9 Mail / Thunderbird for Android
| 项目 |
详情 |
| 来源 |
F-Droid / Aurora Store |
| 语言 |
Kotlin + Java |
| 背景 |
2022 年被 Mozilla 收购，正在重构为 Thunderbird for Android |
| 隐私 |
不追踪用户、支持 PGP、Apache 2.0 开源许可 |
开源客户端共同优势
- 代码可审计，无隐藏后门
- 不内置追踪/广告
- 用户完全控制数据
3.2 闭源客户端
Gmail App
- 不使用邮件内容投广告（2017 年停止），但仍扫描邮件用于”智能功能”
- 收集数据：Web & App Activity、位置历史、广告 ID
Outlook App (新版)
- 新版 Outlook 已演变为数据收集平台（Proton Mail 公开批评）
- 与 801 个第三方广告合作伙伴共享数据
- 收集范围：姓名、密码、人口统计、支付、搜索、设备、位置、语音、文本等
- 关闭应用不会停止数据收集（需登出）
OPPO Mail 等国产厂商邮件
- 不开源，无法审计
- 可能嵌入厂商遥测和广告 SDK
- OAuth 注册为 “unverified”（未通过微软验证），授权可信度存疑
3.3 OAuth “未验证应用”问题
这是开源邮件客户端的核心障碍：
- Google/Microsoft 对敏感 API 要求应用通过验证（需域名、隐私政策、安全评估）
- 未验证应用显示警告，施加用户数量限制
- F-Droid 构建的 FairEmail 因非官方签名无法获得 Google OAuth 授权
- 悖论：越注重隐私的开源应用，越难获得大厂 OAuth 验证
四、自建邮件服务器 vs 商业邮箱
4.1 自建方案对比
| 方案 |
特点 |
最低配置 |
适合人群 |
| Docker Mailserver |
轻量 Docker，单文件配置 |
2GB RAM |
Docker 熟练用户 |
| Mailcow |
全功能套件，含 Web 管理 |
6GB RAM |
小型组织 |
| Mail-in-a-Box |
自动化安装，极简设置 |
1GB RAM |
新手 |
| Stalwart |
Rust 编写，全协议支持 |
2GB RAM |
追求安全的用户 |
| Mailu |
Docker 化，轻量现代 |
2GB RAM |
中等技术水平 |
4.2 优势
- 完全数据主权：邮件存储在自己服务器，第三方无法访问
- 无供应商锁定：不受条款变更、提价影响
- 灵活配置：无限邮箱地址，无附件大小限制
4.3 核心挑战：邮件可达性 (Deliverability)
这是自建邮件最大的难题：
DNS 认证三件套
| 记录 |
作用 |
| SPF |
声明哪些 IP 有权代表域名发信 |
| DKIM |
加密签名证明邮件未被篡改 |
| DMARC |
告知收件方如何处理未通过认证的邮件 |
IP 信誉问题
- Gmail/Outlook 默认不信任新 IP，个人 IP 发的邮件极易进垃圾箱
- 住宅 IP 被大面积黑名单
- 需要长期 IP 预热（逐步增加发信量）
- 一次配置错误可能导致 永久黑名单
社区共识
“2026 年自建邮件服务器几乎不可行…Gmail/Outlook 默认屏蔽住宅 IP，SPF/DKIM/DMARC 配置复杂，一次错误 = 永远进垃圾箱，维护信誉是全职工作。”
4.4 推荐折衷：混合方案
- 自建 IMAP 收件（完全隐私控制）
- 通过 Amazon SES / SendGrid 发件（利用其 IP 信誉）
- 避免 IP 信誉问题，保留数据主权
五、主流邮箱服务隐私对比
5.1 安全与隐私
| 维度 |
Gmail |
Outlook |
ProtonMail |
Tuta |
| 总部 |
美国 |
美国 |
瑞士 |
德国 |
| 情报联盟 |
Five Eyes 核心 |
Five Eyes 核心 |
非联盟成员 |
14 Eyes |
| 端到端加密 |
否 |
否 |
是 (PGP) |
是 (自研) |
| 零知识加密 |
否 |
否 |
是 |
是 |
| 追踪像素屏蔽 |
部分 |
否 |
是 |
是 |
| 广告 |
是 |
是（801 广告伙伴） |
否 |
否 |
| 开源 |
否 |
否 |
是（客户端） |
是（完整） |
| PGP 兼容 |
否 |
否 |
是 |
否（自研协议） |
| 量子安全加密 |
否 |
否 |
开发中 |
已实现 |
5.2 免费套餐
| 维度 |
Gmail |
Outlook |
ProtonMail |
Tuta |
| 存储 |
15 GB |
15 GB |
1 GB |
1 GB |
| 每日发信 |
500 封 |
~300 封 |
150 封 |
无限制 |
| IMAP 支持 |
是（需 OAuth） |
是（需 OAuth） |
需付费 Bridge |
否 |
| 注册要求 |
手机号可选 |
手机号可选 |
不要求 |
不要求 |
5.3 法律与执法
| 服务 |
法律管辖 |
执法配合方式 |
| Gmail |
美国 CLOUD Act / FISA |
可被政府直接要求提供数据（NSL 可禁止告知用户） |
| Outlook |
美国 CLOUD Act / FISA |
同上 |
| ProtonMail |
瑞士联邦法 |
仅响应瑞士法院命令；零知识加密，只能提供元数据 |
| Tuta |
德国法 (GDPR) |
响应德国法院命令；曾被要求在加密前截取未加密来信副本 |
5.4 注意事项
- E2EE 局限：ProtonMail/Tuta 的端到端加密仅在双方都使用同一服务时自动生效
- 元数据泄露：即使内容加密，发件人/收件人/时间/IP 仍可被收集
- Proton 的 Google 依赖：ProtonMail 使用 Google Push Notification Service
- IMAP 限制：ProtonMail Bridge 是付费功能；Tuta 完全不支持 IMAP
本项目的邮件方案
当前配置
| 组件 |
选择 |
原因 |
| 邮件客户端 |
OPPO 系统邮件 (com.android.email) |
FairEmail 配置复杂且 OAuth 依赖 Play Store |
| QQ 邮箱 |
IMAP + 授权码 |
国内通讯需要，授权码避免直接暴露 QQ 密码 |
| Outlook |
未添加 |
OPPO Mail 的 OAuth 注册为”unverified”，存在安全隐患 |
安全建议
- 避免在 OPPO Mail 中通过 OAuth 添加 Outlook（”unverified” 应用）
- 若需使用 Outlook，建议安装微软官方 Outlook App（Aurora Store）
- 隐私敏感通信建议使用 ProtonMail（瑞士管辖 + 端到端加密）
最后更新: 2026-02-18