前言
电子邮件属于一种去中心化的通讯协议, 核心的电子邮件标准只有出入站协议的定义, 并没有定义一个电子邮件服务器如何为电子邮件客户端下发服务器配置, 所以在 Autodiscover 和 Autoconfiguration 之前, 大部分的电子邮件客户端都需要用户手动填写服务器传入和传出配置, 而获取这些配置往往需要用户自己到邮件服务器后台, Webmail 或者提供托管服务的服务商文档中搜寻, 这样的做法等于用户配置与服务器配置并不是自动同步, 在邮件服务器出现更改(迁移某部分的域名, 加密协议或端口)并不会及时通知客户端中跟随做出更改, 从而造成服务端改动后客户端的收发问题.
除去邮件服务器和用户之间的不同步问题, 没有那么多经验用户自己在首次配置客户端的时候可能会对那些参数感到莫名其妙:
- 为什么我的 SMTP 服务器和 IMAP 服务器域名不是我的邮件地址域名?
- 为什么要使用 STARTTLS 而不是 TLS?
- 为什么我的密码不是我的 Webmail 密码?
然后就是: 为什么我每次都要自己手动填这些乱七八糟的参数才能用? 为什么 Webmail 就可以一键登录?🤦♂️
本章节主要叙述基于 DNS 查询, HTTP 请求和静态配置文件实现的自动发现. 不包含基于本地的如: 环境变量, 注册表, 网络部署和用户目录等; 以及基于远程网络服务器的: 动态配置文件, 身份验证和多配置文件等.
现状
目前本章节中提到的自动发现, 对于 Autodiscover, 在 Exchange Online 所有的 Exchange Online 服务都需要组织管理员单独为域名设置一个 autodiscover 别名记录指向微软的 Outlook 服务器 autodiscover.outlook.com 并且由于关闭了基础身份验证, 还要用户先通过身份验证才能检索到 Microsoft 服务器中的配置; Exchange Server 目前依旧能够通过本地的 Active Directory 和 IIS 服务器发现到配置文件. 就目前来说, Autodiscover 还在是 Microsoft 自己设计能尚且还在运行的标准, 其他的非 Exchange 电子邮件服务器也能通过它的标准的部分来兼容实现自动发现.
对于 Autoconfiguration, 这是 Mozilla 的 Thunderbird 采用的一种发现标准, 比起 Autodiscover 为了兼容更多服务商的情况给出了很多 Autodiscover 中没有的选项. 但有的选项 Thunderbird 自己都没有实现支持, 或者还是存在疑问的地方. 最后衍生出了 Mozilla 自己的中心化 ISPDB 服务器, 主要的目的也是为了兼容.
而 RFC 6186 目前还是处于 "拟议标准 (Proposed Standard)" 状态, 也就是说这个标准刚通过起草阶段被 IETF 审阅后公布, 而如果已经做到被互联网广泛采用, 它应该已经被标记上 "标准追踪(Standards Track)" 状态. 它首次发表于 2011 年, 最后一次修改是 2015 年.
客户端
对于这些针对服务端份规范, 尚且处于不成熟不统一的状态. 那么客户端的规范呢?
对于目前的电子邮件客户端, 大部分由电子邮件服务商直接提供的本地客户端都优先使用的是内置的配置数据库, 对于不存在于内置数据库中的还是会要求用户自己输入配置, 并不会尝试去通过以上的标准进行自动发现. 并且对于这些专有客户端, 用户也无从得知它的自动发现支持状态和实现标准.
除了专有客户端, 大部分开源的或其他开放的电子邮件客户端几乎都支持其中一种或多种自动发现, 也内置预设配置数据. 实在不济的也还能通过账号系统保存上一次得到的配置数据, 或者能够导入导出账号列表的数据.
服务商
对于电子邮件服务提供商, 大部分都不会提供配置自动发现的指引, 甚至不会在 DNS 记录中提供官方的配置. 就算一万个用户使用十万个域名, 他们使用的服务端配置都是相同, 但服务商依旧不会提供自动发现, 甚至不提供指引, 当然这里也不是指所有的代托管服务商, 有少部分的服务商具有完整的自动发现指引, 有的还提供官方的自动发现服务器, 能够让客户(用户)通过自己的域名 CNAME 实现支持.
最终用户
对于用户, 本该并不需要知道什么是自动发现, 这应该是电子邮件管理员和电子邮件服务商提前配置好的. 但是由于客户端的问题, 或是管理员和服务商根本没有考虑自动发现, 导致每次登录新的客户端都需要手动配置至少两个(传入与传出)服务器的参数才能使用, 而且如果不是专业用户, 他们甚至会面对这些参数手无足措, 转而把问题转移到服务商和管理员身上(大部分不支持自动发现的客户端反而却能幸免于难). 那么, 又到了给不懂计算机的朋友修电脑的时候了, 但要面对的可能是你的用户.
但是, 即使是精明的用户, 也并不是都想或都了解过自动发现. 而是更愿意使用更成熟的, 内建客户端账号系统的电子邮件客户端, 将这些繁杂的服务器配置数据保存在第三方手中(包括密码).
未来
笔者期望的未来是用 RFC 实现的互联网标准, 但不会是目前的 RFC 6186, 因为它并不能解决除了下发配置之外的问题, 至少也要如 Mozilla Thunderbird 的 Autoconfiguration 中的一样, 为身份验证和个性化给出支持, 对于现代的 MSA 系统大部分都已经开始采用 API 与服务器交互, 而不是还在使用服务器通讯协议, MSA 的 587 端口同样难以抵御泛滥的网络攻击, 部分的服务商已经开始使用更进一步的身份验证保护 MSA 系统甚至禁止基本身份验证, 这其中包括现在多方强调的多因素身份验证以及零信任模型.
现代的电子邮件系统已经将用户和攻击者隔离在服务器之外很远的地方, 用户能通过身份验证表示攻击者也同样能, 只要还存在暴露的门, 那就一定会有乘虚而入的家伙. 所以, 如果电子邮件系统在未来依旧不会消亡, 那么对于自动发现应该实现的, 应该包括服务器安全策略和客户端策略, 而不是简单的指向一个端口和服务器.
又或者, 在 MSA 系统和用户之间再叠一层专用于身份验证和威胁防御的专用系统? 也许会叫 "用户认证代理 (User Verification Agent, UVA)"?🥱
