你的邮箱密码可能被发往日本公司服务器：微软一个持续六年的配置错误

你在 Outlook 里输入 email@example.com 测试账户时，密码可能正被送往日本。

这听起来像科幻电影情节，却是真实发生的技术事故。自 2020 年 2 月起，微软的 Autodiscover 服务将 IANA（互联网号码分配机构）明确保留的测试域名「example.com」，错误地路由到了日本住友电工（Sumitomo Electric Industries）的邮件服务器。这一错误配置持续了近六年，且并非来自用户反馈，而是微软内部手动添加的。

一个本不该存在的连接

「example.com」是什么？它是 IANA 根据 RFC 2606 标准保留的特殊用途域名，专供文档示例和开发测试使用，本就不该指向任何真实服务。

但当你在 Outlook（无论是 Windows 还是 macOS 版本）中设置 email@example.com 作为测试账户时，系统会自动配置使用以下服务器：

• IMAP：imapgms.jnet.sei.co.jp（端口 993）
• SMTP：smtpgms.jnet.sei.co.jp（端口 465）

这两个地址属于日本住友电工。换言之，全球无数开发者在测试邮件配置时输入的「测试密码」，可能被发送到了这家日本企业的服务器上。

DNS 验证：错误完全在微软内部

通过 DNS 查询可以确认，「example.com」本身没有任何指向住友电工的记录：

dig MX example.com +short # 返回空值（仅有一个 null MX 记录）
dig CNAME autodiscover.example.com +short # 无响应
dig SRV _autodiscover._tcp.example.com +short # 无响应

这说明问题完全出在微软的内部数据库，而非 DNS 层面。微软的 Autodiscover API 在收到请求后，直接从自己的配置库中返回了错误的服务器地址。

最令人震惊的部分：这是「手动添加」的

微软 API 返回的 x-debug-support 头信息（经 Base64 解码后）揭示了关键细节：

IsCrowdsourced 为 false 意味着：这不是来自用户反馈的「众包」配置，而是微软内部人员手动添加到数据库的。更讽刺的是，这个错误在添加当天就被「更新」了一次，说明有人专门处理过它，却依然保留了错误配置。

为什么这很严重？

1. 违反国际标准

IANA 保留域名的存在意义就是避免冲突和误用。将「example.com」路由到真实服务器，相当于在高速公路的「施工封闭」标志旁开了个收费站——完全违背了设计初衷。

2. 潜在的安全风险

虽然住友电工不太可能主动收集这些测试凭证，但问题在于：没人知道这些数据去了哪里。如果未来该服务器被攻击或配置变更，这些「测试密码」可能成为攻击跳板。

3. 微软的内部流程漏洞

一个手动添加的错误配置能存在六年未被发现，反映出微软内部的配置审核和监控机制可能存在严重问题。正如 Hacker News 上一位开发者吐槽：「这就像航空公司把『演练航班』的乘客真的送到了错误的国家，然后六年没人发现。」

延伸思考：互联网基础设施的「信任链」

这次事件暴露了一个更深层的问题：我们对大型科技公司的基础设施过度信任。

Autodiscover 作为 Outlook 的默认配置机制，每天为数百万用户自动设置邮件账户。当这样一个核心服务出现基础性错误时，影响范围是全球性的。更令人担忧的是，普通用户甚至无法察觉自己被错误配置了。

类似的「保留资源误用」问题在互联网历史上并不罕见：

• 过去曾有 CDN 服务商错误缓存了本该返回 404 的保留 IP 段
• 某些 DNS 服务商曾将「localhost」解析到真实服务器
• 甚至有云服务商一度允许用户注册「admin」这样的通用账户名

这些问题的共同点是：违反了行业共识和标准，而修复往往滞后于发现。

给开发者的建议

结语

这个持续六年的错误，像一面镜子，照出了互联网基础设施中那些「看不见的角落」。它提醒我们：即使是微软这样的科技巨头，也会在最基础的配置上犯错；而我们对这些「看不见的服务」的信任，可能比想象中更脆弱。

正如一位 Hacker News 用户的评论：「这不是一个 bug，这是一个关于责任、标准和透明度的故事。」