电子邮件系统的自动发现: Autodiscover, Autoconfiguration 和 RFC 6186.

前言

电子邮件属于一种去中心化的通讯协议, 核心的电子邮件标准只有出入站协议的定义, 并没有定义一个电子邮件服务器如何为电子邮件客户端下发服务器配置, 所以在 Autodiscover 和 Autoconfiguration 之前, 大部分的电子邮件客户端都需要用户手动填写服务器传入和传出配置, 而获取这些配置往往需要用户自己到邮件服务器后台, Webmail 或者提供托管服务的服务商文档中搜寻, 这样的做法等于用户配置与服务器配置并不是自动同步, 在邮件服务器出现更改(迁移某部分的域名, 加密协议或端口)并不会及时通知客户端中跟随做出更改, 从而造成服务端改动后客户端的收发问题.

除去邮件服务器和用户之间的不同步问题, 没有那么多经验用户自己在首次配置客户端的时候可能会对那些参数感到莫名其妙: 为什么我的 SMTP 服务器和 IMAP 服务器域名不是我的邮件地址域名? 为什么要使用 STARTTLS 而不是 TLS? 为什么我的密码不是我的 Webmail 密码?

然后就是: 为什么我每次都要自己手动填这些乱七八糟的参数才能用? 为什么 Webmail 就可以一键登录? (🤦‍♂️)

本文主要叙述基于 DNS 查询, HTTP 请求和静态配置文件实现的 Autodiscover 和 Autoconfiguration. 不包含基于本地的如: 环境变量, 注册表, 网络部署和用户目录等; 以及基于远程网络服务器的: 动态配置文件, 身份验证和多配置文件等.

区别与实现

所以, 为了解决以上的 "电子邮件客户端自动配置邮件服务器参数" 的问题, 引出了 "Autodiscover" 和 "Autoconfiguration", 顾名思义 Autodiscover 即为 "自动发现", Autoconfiguration 即为 "自动配置". 两者大同小异, 区别在于前者 Autodiscover 主要指的是存在于 Microsoft 开发的电子邮件系统 Exchange 中使用到的另一个也是 Microsoft 开发的同步协议 Exchange ActiveSync 中附带的为电子邮件客户端下发邮件服务器配置的功能; 后者主要是由 Thunderbrid 定义的一种为了实现前者类似功能的规范.

Autodiscover

Autodiscover 目前存在于 Exchange Server 和 Exchange Online 中, 由于 Microsoft 逐渐推广禁止使用基本身份验证, 所以这部分功能可能未来只会在 Exchange Server 中见到了, 目前 Exchange Online 主要从 Active Directory 用户目录中获取配置, 之后才会尝试使用传统的 Autodiscover 去发现配置.

发起 Autodiscover 的基本步骤:

从 Exchange Activesync 中请求配置:
1. 尝试从 URL 中请求配置: https://example.com/Autodiscover/Autodiscover.xml
2. 尝试从 URL 中请求配置: https://autodiscover.example.com/Autodiscover/Autodiscover.xml
3. 尝试从主机名 Autodiscover DNS 中寻找重定向 URL: autodiscover.example.com >> CNAME >> autodiscover.exchangeserver.com >> HTTP 301/302 >> autodiscover.mailhoster.com
  1. 尝试从重定向 URL 中请求配置: https://autodiscover.mailhoster.com/Autodiscover/Autodiscover.xml
    1. 尝试从主机名 Autodiscover DNS 中寻找重定向 URL: autodiscover.mailhoster.com
    - ...

Autodiscover 就是不断从主机名和 URI 中寻找配置, 一层一层从上到下尝试寻找, 经过多层重定向之后最终找到文件名为 Autodiscover.xml 配置文件, 如果多次重定向之后还是没找到, 那客户端读取不到配置文件就还是需要手动配置了.

Autoconfiguration

Autoconfiguration 来自 Thunderbrid, 使用了 Autodiscover 类似的实现方法, 但步骤和规范上有些区别.

发起 Autoconfiguration 的基本步骤:

从 Thunderbrid 在本地磁盘上的安装目录中读取配置: C:/Program Files/Mozilla/Thunderbird/isp/example.com.xml
从电子邮件服务商获取配置:
1. 尝试请求 http://autoconfig.emailaddressdomain/mail/[email protected] 或 http://example.com/.well-known/autoconfig/mail/config-v1.1.xml 文件路径.
2. 尝试从 DNS 记录中寻找配置:
  1. 尝试查询用户名域名 example.com 中存在内容为 https://www.example.com/mozilla.xml 的 TXT 记录依据记录进行请求配置文件未应用 .
  2. 另一种提议, 也是基于 DNS未应用 :
    1. 尝试解析用户名域名中的 MX 记录, 若存在多个 MX 记录则取最高优先级的记录; 如果不存在 MX 记录, 则查询并使用用户名域名中符合 SMTP 协议(RFC 2821^[1])的 A 记录.
    2. 依据上方的查询结果, 从结果主机名中查询存在 mailconf=https://... 形式的 TXT 记录, 依据记录寻找配置文件, 如果 URL 错误则继续向下寻找.
    3. 如果查询不到有效的 TXT 记录则选择第一条有效的 TXT 记录进行查找配置文件.
      1. 在对配置文件进行 GET 请求时中附带初始请求的用户邮件地址(mailto:[email protected])为 referrer, 用于实现可能存在的动态配置文件下发.
      2. 解析配置文件并让用户选择需要的协议和其他建议配置.
      3. 继续进行登录验证.
  3. 尝试解析用户名域名 DNS 从中寻找 SRV 记录获取配置(RFC 6186^[2])未应用 .
尝试从 Mozilla 服务器检索配置:
1. 从 autoconfig.thunderbird.net^[3] 请求用户名域名中的服务商配置文件, 如: https://autoconfig.thunderbird.net/v1.1/google.com.
2. 如果找不到公共配置文件, 则尝试使用一些通配字符和常用端口进行猜测, 如 imap.example.com, pop.example.com, pop3.example.com, smtp.example.com 或 mail.example.com.
3. 继续失败, 则直接让用户进行手动配置.

以上标记有未应用的都代表存在这些提议, 但没有实际应用到 Thunderbird 邮件客户端和服务器系统中.

RFC 6186

请直接阅读下一节中有关 RFC 6186 的响应规范.

协议响应规范

从上面小节对两种自动寻找配置的方式可以看出, 它们都依赖于一个扩展名为 .xml 及使用 XML 标记语言的编写的二进制文件.

两种实现方式虽然在过程上大同小异, 但它们要使用到的最终配置文件是存在差异的, 并不能通用. Microsoft 在 Exchange Server 多个版本也修改了对于这部分静态文件的定义和规范, 直到现在的 Exchange Online 加入身份验证之后基本上就无法用于静态文件的实现, 所以需要向前使用还能单纯依靠静态文件就能被客户端解析的规范.

如果要一同在服务器实现, 那么需要分别针对两种方式编写对应的 XML 源文件.

此外上面还稍微提到过, 还存在一个拟议中的规范 RFC 6186^[2:1], 并不依赖于特定域名下的配置文件, 而是使用完全基于 DNS 的 SRV 记录查询实现配置发现.

Autodiscover

以下是 Microsoft 提供的适用 Outlook 2010 邮件客户端的服务端配置文件模板:

计划自动在 Outlook 2010 中配置用户帐户 | Microsoft Learn

以下配置文件注释经过本人翻译.

Autodiscover.xml

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <!-- Response: 必须
本标签用于指示该 XML 是一个 Autodiscover 响应.
-->
    <Response
        xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <!-- User: 可选
本标签用于提供用户信息, Autodiscover 必须使用 UTF-8 编码.
-->
        <User>
            <!-- DisplayName: 可选
服务端使用这个标签提供一个默认显示名称. 客户端可以选择接受或自定义, 这可以免除用户所需要的输入从而节省时间.
-->
            <DisplayName>John Doe</DisplayName>
        </User>

        <!-- Account: 必须
本标签用于指定账户类型, 如电子邮件(Email), 新闻组(Newsgroup)和 SIP 服务器等.
-->
        <Account>
            <!-- AccountType: 必须
本标签中的值用于指定账户类型.
可用值:
email: 表示该标签内用于定义电子邮件服务器的配置.
nntp: 表示该标签内用于定义 NNTP 服务器的配置(Outlook 2007 没有使用).
-->
            <AccountType>email | nntp</AccountType>

            <!-- Action: 必须
本标签中的值用于定义直接使用本文件的配置或重定向至另一个可提供 Autodiscover 配置的网络服务器.
可用值:
redirectUrl: 如果指定使用这个值, 那么在 RedirectUrl 标签中必须要包含要定向到的 Autodiscover 配置路径(http/https).
            为了防止服务端的重定向将客户端置入请求循环中, 客户端应在 10 次重定向后停止继续重定向.
redirectAddr: 如果指定使用这个值, 表示客户端应当使用 RedirectAddr 标签中的电子邮件地址进行 Autodiscover 配置查找, 而不是使用当前的用户电子邮箱地址.
settings: 如果指定使用了这个值, 表示本 XML 文件中包含进行账户配置所需要的信息. 客户端将使用 Protocol 标签下的服务器配置进行配置客户端.
-->
            <Action>redirectUrl | redirectAddr | settings</Action>

            <!-- RedirectUrl: 如果 Action 标签值指定为 "redirectUrl", 则本标签值为必须; 如果未指定, 则应该移除本标签.
本标签的值应是一个 http 或 https 协议的 URL, 用于客户端使用该值进一步获取配置.
-->
            <RedirectUrl>redirect.URL</RedirectUrl>

            <!-- RedirectAddr: 如果 Action 标签值指定为 "redirectAddr", 则本标签值为必须; 如果未指定, 则应该移除本标签.
本标签的值应是一个电子邮件地址, 用于客户端使用该地址重新查找 Autodiscover 配置.
-->
            <RedirectAddr>email@address</RedirectAddr>

            <!-- Image: 可选
本标签的值是一张网络 JPG 图片, 用作配置电子邮件服务提供商的品牌标志(Outlook 2007 没有使用).
-->
            <Image>http://path.to.image.com/image.jpg</Image>

            <!-- ServiceHome: 可选
本标签的值是一个指向电子邮件服务提供商主页的 URL, 客户端可以选择是否将这个值显示给用户(Outlook 2007 没有使用).
-->
            <ServiceHome>http://web.page.com</ServiceHome>

            <!-- Protocol: 如果 Action 标签值指定为 "settings", 则本标签值为必须; 如果未指定, 则应该移除本标签.
本标签只能包含一个账户类型的配置信息, 多个 Protocol 标签可按照服务端的偏好进行配置, 但客户端可以自行选择偏好协议.
-->
            <Protocol>
                <!-- Type: 必须.
本标签的值指定使用何种账户类型.
可选值:
POP3: 指定连接到服务器的协议使用 POP3. 仅适用于 AccountType 标签值为 "email" 时.
SMTP: 指定连接到服务器的协议使用 SMTP. 仅适用于 AccountType 标签值为 "email" 时.
IMAP: 指定连接到服务器的协议使用 IMAP. 仅适用于 AccountType 标签值为 "email" 时.
DAV: 指定连接到服务器的协议使用 DAV. 仅适用于 AccountType 标签值为 "email" 时.
WEB: 指定客户端使用 Server 标签中的 URL 从浏览器访问电子邮件. 仅适用于 AccountType 标签值为 "email" 时(Outlook 2007 没有使用).
NNTP: 指定连接到服务器的协议使用 NNTP. 仅适用于 AccountType 标签值为 "nntp" 时(Outlook 2007 没有使用).
-->
                <Type>POP3 | SMTP | IMAP | DAV | WEB | NNTP</Type>

                <!-- ExpirationDate: 可选.
本标签的值指定一个该配置文件最后有效的日期, 在该日期过后客户端应该自动重新查找 Autodiscover 配置. 如果未指定则默认为不过期.
-->
                <ExpirationDate>YYYYMMDD</ExpirationDate>

                <!-- TTL: 可选.
本标签的值指定该配置文件的有效时间, 单位为小时. 自首次查找该配置文件起算, 经过本标签值的时间后客户端将再次查找 Autodiscover 配置. 如果本标签未指定值, 则默认使用 1 小时的
                TTL.
-->
                <TTL>168</TTL>

                <!-- Server: 必须.
本标签的值指定了与上方 Type 标签值中账户类型对应的服务器地址.
对于 Type 标签值为 POP3, SMTP, IMAP 或 NNTP 的, 该值应是一个主机名或 IP 地址.
对于 Type 标签值为 DAV 和 WEB 的, 该值应是一个 URL.
-->
                <Server>mail.contoso.com</Server>                <!--服务器的
                IP 地址或域名-->

                <!-- Port: 可选.
本标签的值指定对 Server 标签值使用的端口号. 如果未指定则根据 Type 标签值使用默认设置. 如果 Server 标签值是一个 URL, 则不使用本标签值.
-->
                <Port>110</Port>

                <!-- LoginName: 可选.
本标签值指定用户的登录名. 如果未指定, 则默认使用用户设置的电子邮件地址 "@" 前的字串符. 如果本标签值指定为一个域名, 则使用 [用户名]@[域名] 的格式进行配置, 如
                "[email protected]".
-->
                <LoginName>Alice</LoginName>

                <!-- DomainRequired: 可选.  默认为 off.
本标签指定身份验证过程中是否需要域名, 如果设置为 on, 则在身份验证过程中需要域名, off 则为不需要. 如果未在 LoginName 标签中指定一个域名或未指定 LoginName
                标签的值, 那么需要用户手动输入域名才能进行身份验证.
-->
                <DomainRequired>on | off</DomainRequired>

                <!-- DomainName: 可选.
本标签值指定用户域名. 如果未指定值, 则默认将用户电子邮件地址作为 UPN 的格式([用户名]@[域名])来使用. 如 [email protected].
-->
                <DomainName></DomainName>

                <!-- SPA: (Secure Password Authentication 安全密码验证) 可选.
本标签值指定是否需要安全密码验证. 如果未指定, 则默认为 on.
-->
                <SPA>on | off</SPA>

                <!-- SSL: 可选.
本标签值指定是否需要进行安全登录. 如果未指定, 则默认为 on.
-->
                <SSL>on | off</SSL>

                <!-- AuthRequired: 可选.
本标签值指定是否需要身份验证(基于密码). 如果未指定, 则默认为 on.
-->
                <AuthRequired>on | off</AuthRequired>                <!-- 可选: 是否需要身份验证. -->

                <!-- UsePOPAuth: 可选.
本标签值仅在 Type 标签值为 "SMTP" 时可用. 用于指定 POP3 类型的账户使用的身份验证信息是否也将用于 SMTP.
-->
                <UsePOPAuth>on | off</UsePOPAuth>

                <!-- SMTPLast: 可选.  默认为 off.
本标签值指定在通过 SMTP 发件前是否需要先下载电子邮件. 通常 SMTP 下载邮件时都会检查身份验证是否成功, 所以一般为需要.
-->
                <SMTPLast>on | off</SMTPLast>
            </Protocol>
        </Account>
    </Response>
</Autodiscover>

使用这个规范编写的一个典型的 IMAP & POP3 & SMTP 服务器配置应该像这样:

Autodiscover.xml

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <Account>
            <AccountType>email</AccountType>
            <Action>settings</Action>
            <Protocol>
                <Type>IMAP</Type>
                <Server>imap.example.com</Server>
                <Port>993</Port>
                <DomainRequired>off</DomainRequired>
                <LoginName></LoginName>
                <SPA>off</SPA>
                <SSL>on</SSL>
                <AuthRequired>on</AuthRequired>
            </Protocol>
            <Protocol>
                <Type>POP3</Type>
                <Server>pop3.example.com</Server>
                <Port>995</Port>
                <DomainRequired>off</DomainRequired>
                <LoginName></LoginName>
                <SPA>off</SPA>
                <SSL>on</SSL>
                <AuthRequired>on</AuthRequired>
            </Protocol>
            <Protocol>
                <Type>SMTP</Type>
                <Server>smtp.example.com</Server>
                <Port>465</Port>
                <DomainRequired>off</DomainRequired>
                <LoginName></LoginName>
                <SPA>off</SPA>
                <Encryption>SSL</Encryption>
                <AuthRequired>on</AuthRequired>
                <UsePOPAuth>off</UsePOPAuth>
                <SMTPLast>off</SMTPLast>
            </Protocol>
        </Account>
    </Response>
</Autodiscover>

由于是使用标准的电子邮件协议, 而 Microsoft 提供的给 Exchange 服务器中的协议模板中有部分配置项目并不是必须的, 比如 UPN 就只是 Microsoft 专门用来指定一个账户个体的简称, 实际上和电子邮箱地址并没有区别, 两者几乎是一模一样的定义.

Autoconfiguration

从 MozillaWiki 中可以得到配置格式:

Thunderbird:Autoconfiguration:ConfigFileFormat - MozillaWiki

以下配置文件注释经过本人翻译.

config-v1.1.xml

<?xml version="1.0"?>
<clientConfig version="1.1">
    <!-- 电子邮件服务提供商 -->
    <emailProvider id="example.com">
        <!-- domain: 域名 -->
        <domain>example.com</domain>
        <domain>example.net</domain>
        <!-- displayName: 显示在客户端上的名称. -->
        <displayName>Google Mail</displayName>
        <!-- displayShortName: 显示的简称. -->
        <displayShortName>GMail</displayShortName>

        <!-- incomingServer type: 传入服务器类型
                "imap": IMAP
                "pop3": POP3
           -->
        <incomingServer type="pop3">
            <!-- hostname: 选定类型所使用的服务器主机名. -->
            <hostname>
                pop.example.com</hostname>
            <!-- port: 选定类型所使用的服务器端口号. -->
            <port>995</port>
            <!-- socketType: 连接类型
                    "plain": 不加密.
                    "SSL": SSL 加密.
                    "STARTTLS": 使用 STARTTLS 进行机会性加密
                -->
            <socketType>SSL</socketType>
            <!-- username: 指定用户名. -->
            <username>%EMAILLOCALPART%</username>
            <!-- authentication: 身份验证类型
                    "password-cleartext":
                       直接发送明文密码进行验证. 如果没有加密连接协议还要使用明文密码则非常不安全.
                    "password-encrypted":
                       对于密码进行加密, 可以是 CRAM-MD5, DIGEST-MD5. 不包含 NTLM.
                    "NTLM":
                       使用 NTLM 或 HTLMv2 及后续版本. Windows 所使用的登录方法.
                    "GSSAPI":
                       使用 Kerberos 或 GSSAPI, 一种适用于大规模验证需要的单点登录方式.
                    "client-IP-address":
                       根据 IP 地址识别用户, 无需用户名和密码, 也不需要进行身份验证.
                    "TLS-client-cert":
                       使用客户端证书进行认证, 要求客户端提供 SSL 证书(如果需要, 可让用户自行选择证书后发送). Thunderbird 尚未支持.
                    "OAuth2":
                        使用 OAuth2, 仅在部分硬编码服务器上可用. 只能作为备用方法使用.
                        由于 OAuth2 规范的缺陷, 客户端一般需要发送客户端的凭证密钥到服务商,
                        这样做往往需要客户端要先在服务商注册客户端并获得服务商的同意.
                        这就不仅导致电子邮件服务商可以禁止用户使用任意电子邮件客户端, 还导致并不能支持所有的 OAuth2 服务器(这与开源的理念相悖).
                        最后 Thunderbird 只能将支持 OAuth2 的服务器和密钥硬编码进客户端里.
                        这也意味着并不能使用任意的 OAuth2 服务器. 只有在客户端中已经被定义好服务器才能使用.
                        在Thunderbird 中受支持的 OAuth2 服务器参见源代码:
            "https://searchfox.org/comm-central/source/mailnews/base/src/OAuth2Providers.jsm"
                    "none":
                        不进行验证.
                 -->
            <authentication>
                password-cleartext</authentication>
            <pop3>
                <!-- 移除以下内容则让客户端或用户自行选择以下参数配置. -->
                <!-- leaveMessagesOnServer: 是否将邮件保存在服务器上(true/false). -->
                <leaveMessagesOnServer>true</leaveMessagesOnServer>
                <!-- downloadOnBiff: 下载时发送 Biff 通知(?)(true/false).  -->
                <downloadOnBiff>true</downloadOnBiff>
                <!-- daysToLeaveMessagesOnServer: 服务器中邮件的保留天数. -->
                <daysToLeaveMessagesOnServer>
                    14</daysToLeaveMessagesOnServer>
                <!-- checkInterval: 从服务器检查的间隔(分钟数), 仅适用于不允许进行频繁请求检查的服务器. Thunderbird 暂不支持. -->
                <checkInterval minutes="15" />
            </pop3>
            <!-- password: 值可选, 用户的密码. -->
            <password></password>
        </incomingServer>

        <!-- outgoingServer type: 传出服务器类型 -->
        <outgoingServer type="smtp">
            <!-- hostname: 选定类型所使用的服务器主机名. -->
            <hostname>
                smtp.googlemail.com</hostname>
            <!-- port: 选定类型所使用的服务器端口号. -->
            <port>587</port>
            <!-- socketType: 连接类型
                    "plain": 不加密.
                    "SSL": SSL 加密.
                    "STARTTLS": 使用 STARTTLS 进行机会性加密
                -->
            <socketType>STARTTLS</socketType>
            <!-- username: 指定用户名. -->
            <username>%EMAILLOCALPART%</username>
            <!-- authentication: 身份验证类型
                符合 RFC 2554, RFC 4954 的或其他的身份验证方法, 可用选项参考 incomingServer 标签中的 authentication;
                除此之外还可用使用以下的方法:
                (关于 Thunderbird 对此的兼容性: Thunderbird 3.0 只支持 "plain", "secure", "none" 和 "smtp-after-pop".)
                 "SMTP-after-POP":
                    在对 SMTP 进行验证前先对传入服务器进行验证.
            -->
            <authentication>
                password-cleartext</authentication>
            <!-- restriction: 限定服务器在客户端上进行连接的条件(如果服务器在 authentication 之外还要求其他的验证选项).
                    "client-IP-address": 只有用户在特定的网络中才能连接到服务器且服务器才能工作. 如特定 ISP 网络或公司网络.
                        注意: <authentication>client-IP-address</> 表示可以在没有任何身份验证的情况下连接并使用服务器.
                        使用 <authentication>password-cleartext</> 和 <restriction>client-IP-address</> 时表示用户需要处于正确的 IP
            网络环境中并且应该进行身份验证.
                        建议不要使用实行这种验证措施的服务器, 详见: "https://bugzilla.mozilla.org/show_bug.cgi?id=556267".
                    尚未实现. 规范(标签元素?)可能会改动.
            -->
            <restriction>client-IP-address</restriction>
            <!-- 移除以下内容则让客户端或用户自行选择以下参数配置. -->
            <!-- 是否选择添加此服务器(true/false). -->
            <addThisServer>true</addThisServer>
            <!-- 是否是配置文件中的全局首选服务器(true/false) -->
            <useGlobalPreferredServer>
                true</useGlobalPreferredServer>
            <!-- password: 值可选, 用户的密码. -->
            <password></password>
        </outgoingServer>

        <!--
            在连接到服务器之前需要用户手动进行配置的选项(比如, 部分邮件服务提供商情况默认关闭 POP3, IMAP 或 SMTP, 需要用户登录 Webamil 手动打开账户设置中的这些选项).
            注意: 根据 XML 规范, 部分特殊符号需要进行转义, 如:
                "&" >> "&amp;"
                "<" >> "&lt;"
                ">" >> "&gt;"
                "'" >> "&apos;"
                """ >> "&quot;"
            尚未实现, 详见: "https://bugzilla.mozilla.org/show_bug.cgi?id=586364".
        -->
        <!-- visiturl 值为显示给用户的 URL. -->
        <enable visiturl="https://mail.google.com/mail/?ampshva=1#settings/fwdandpop">
            <!-- instruction: 说明文字 -->
            <instruction>Check 'Enable
                IMAP and POP' in Google settings page</instruction>
            <!-- instruction lang: 另一种语言的说明文字 -->
            <instruction lang="de">Schalten Sie 'IMAP und POP
                aktivieren' auf der Google
                Einstellungs-Seite an</instruction>
        </enable>

        <!--
            一个电子邮件服务商用于描述配置文件的网页.
            主要用于配置文件维护, 客户端并不使用这里的提供的信息.
            并不一定需要完全使用服务商提供的配置, 比如服务商在配置文件中不使用 SSL, 但 SLL 实际可用, 此时就可以选择性配置 SLL.
            descr 应该包含来自服务商对客户的(多语言)说明.
        -->
        <documentation url="http://www.example.com/help/mail/thunderbird">
            <descr lang="en">Configure Thunderbird 2.0 for
                IMAP</descr>
            <descr lang="de">Thunderbird 2.0 mit IMAP konfigurieren</descr>
        </documentation>

    </emailProvider>

    <!-- 用于同步用户通讯录或联系人方式的配置. 尚未实现. Thunderbird 使用 RFC 6764 实现这类功能的自动发现. -->
    <!-- 由于 RFC 6764 实现了相同的功能, 所以这部分配置已经被标注需要被移除. -->
    <addressBook type="carddav">
        <!-- 用户名 -->
        <username>
            %EMAILADDRESS%</username>
        <!-- authentication: 身份验证方式, 参见 incomingServer 标签配置.
              "http-basic":
                    使用 HTTP 服务器进行 WWW-Authenticate: Basic 身份验证.
              "http-digest":
                    使用 HTTP 服务器进行 WWW-Authenticate: Digest 身份验证.
              "OAuth2":
                    OAuth2 身份验证. 使用和 Email 相同的口令.
        -->
        <authentication>http-basic</authentication>
        <!-- 指定服务器 URL. -->
        <serverURL>https://contacts.example.com/remote.php/dav</serverURL>
    </addressBook>
    <!-- 用于同步用户日历方式的配置. 尚未实现. Thunderbird 使用 RFC 6764 实现这类功能的自动发现. -->
    <!-- 由于 RFC 6764 实现了相同的功能, 所以这部分配置已经被标注需要被移除. -->
    <calendar type="caldav">
        <!-- 用户名 -->
        <username>%EMAILADDRESS%</username>
        <!-- 身份验证方式, 参见 addressBook 中的身份验证方式. -->
        <authentication>
            http-basic</authentication>
        <!-- 指定服务器 URL. -->
        <serverURL>https://calendar.example.com/remote.php/dav</serverURL>
    </calendar>

    <!-- 用于用户进行文件共享方式的配置. 尚未实现. 可用于 Thunderbird 中的 FileLink 或者在用户桌面创建一个同步文件夹. -->
    <!-- 由于 RFC 6764 实现了相同的功能, 所以这部分配置已经被标注需要被移除. -->
    <fileShare type="webdav">
        <!-- 用户名 -->
        <username>%EMAILADDRESS%</username>
        <!-- 身份验证方式, 参见 addressBook 中的身份验证方式. -->
        <authentication>http-basic</authentication>
        <!-- 指定服务器 URL. -->
        <serverURL>https://share.example.com/remote.php/dav</serverURL>
    </fileShare>

    <!-- 可选, 用于访问 Webmail 的配置. 其中的 URL 值会在标准的网络浏览器中打开. -->
    <webMail>
        <!-- Webmail 的登录页面 URL, 用户必须手动输入用户名和密码进行登录. URL 需要使用 HTTPS. -->
        <loginPage url="https://mail.example.com/login/" />

        <!--
            与 loginAutomaticDOM 相同, 但网站会检查用户是否来自登录页.
            会在浏览器中打开登录页面, 获取页面 DOM, 然后自动填写用户名和密码然后触发登录按钮.
            登录按钮可能不是 HTML 而是一个 div, 所以触发这类按钮需要发送一个点击事件.
            URL 需要使用 HTTPS.
        -->
        <loginPageInfo url="https://mail.example.com/login/">
            <!-- username: 用户名
                填写入 usernameField 中的内容.
                格式(包括占位符)与 incomingServer 中的 username 相同.
            -->
            <username>%EMAILADDRESS%</username>
            <!--
                允许找到页面中的文本字段并填充它们.
                id 属性输出给 DOM name 属性. id 和 name 属性必须同时或存在其中一个. 如果存在, 则优先使用 id(例如使用 "getElementByid()"), 如果不存在,
            则会尝试按名称查找元素.
                不要把这个示例 XML 中的这些 id 当成是通用的, 在使用之前应该要验证格式(例如某些仅使用字符和数字的 id).
                如果你还使用 jQuery 这样强大的函数, 还在 XML 的用户名 id 中返回了没有经过检查的代码, 那么它有可能会被执行.
            -->
            <usernameField id="email_field" name="email" />
            <passwordField name="password" />
            <!-- 定义提交按钮, 用于填充完成后触发自动提交. id 和 name 属性参见 username.-->
            <loginButton id="submit_button" name="login" />
        </loginPageInfo>
    </webMail>

    <!-- 尚未实现, 详见: "https://bugzilla.mozilla.org/show_bug.cgi?id=564043". -->
    <!--
        在某些电子邮件服务提供商中, 用户名和密码并不与 IMAP, POP3 或 SMTP 的用户名和密码对应.
        比如用户邮件地址是 "[email protected]", 但用于登录电子邮件服务器的用户名是给定的用户 ID 或随机的用户名, 密码也可能同样不与电子邮件服务器的登录密码相同.
        此时可以提供一个 inputField 标签, 这可以让客户端向用户显示一个输入框, 从而实现自定义的的用户名或密码.
        输入框的提示由标签中的 label 属性定义, 其填充示例是 inputField 标签的值.
        用户在对应 inputField 标签中输入的内容会写入到标签属性的 key 之中, 这个用于 key 属性变量值必须是大写字母.
        同时被定义的变量可以在 XML 配置中的其他位置使用, 但并不建议用这种办法来让用户定义其他的配置属性(因为这样做的话, 提供该 XML 配置的意义就变得不再那么大, 并且用户体验比在 UI
    上手动配置还要差).
    -->
    <inputField key="USERNAME" label="Username">
        123456</inputField>
    <inputField key="NICKNAME" label="Nickname">Alice</inputField>
    <!--
        以上配置将生成如下的 UI:
        Username: [          ] example: 123456
        Nickname: [          ] example: Alice
        同时, 在配置文件的其他位置就能够使用 "%USERNAME%" 和 "%NICKNAME%" 来引用这两个用户输入的值.
    -->

    <!-- clientConfigUpdate: 客户端用于配置文件更新的 URL. -->
    <clientConfigUpdate url="https://www.example.com/config/mozilla.xml" />

</clientConfig>

对于配置文件中的 incomingServer (传入服务器) 和 outgoingServer(传出服务器) 可能出现多次. 但应该按照优先使用顺序来排序, 通常会使用第一个出现的服务器配置, 只有当实际服务器表现不满足配置中要求的选项时(比如配置指定使用 SSL 但实际无法通过 SSL 连接到服务器), 才尝试选择第二个服务器配置. 如果 IMAP 和 POP3 服务器同时存在, 客户端应该同时列出(依旧遵循配置中的顺序显示来表示服务商的偏好), 让用户自行选择需要的服务器协议.

除上面配置文件中提到的, 依据用户在客户端的输入内容, 还存在以下通用占位符(变量):

%EMAILADDRESS%: 用户的完整电子邮件地址.
%EMAILLOCALPART%: 用户电子邮件地址中 "@" 前的部分.
%EMAILDOMAIN%: 用户电子邮件地址中 "@" 后的部分.
%REALNAME%: 真实名字(?)

依据这个规范编写的一个典型的 IMAP & POP3 & SMTP 服务器配置应该像这样:

config-v1.1.xml

<?xml version="1.0"?>
<clientConfig version="1.1">
    <emailProvider id="example.com">
        <domain>example.com</domain>
        <displayName>EXAMPLE Inc</displayName>
        <displayShortName>CORG</displayShortName>
        <incomingServer type="imap">
            <hostname>imap.example.com</hostname>
            <port>994</port>
            <socketType>SSL</socketType>
            <username>%EMAILADDRESS%</username>
            <authentication>password-cleartext</authentication>
        </incomingServer>
        <incomingServer type="pop3">
            <hostname>pop3.example.com</hostname>
            <port>995</port>
            <socketType>SSL</socketType>
            <username>%EMAILADDRESS%</username>
            <authentication>password-cleartext</authentication>
            <pop3>
                <leaveMessagesOnServer>true</leaveMessagesOnServer>
            </pop3>
        </incomingServer>
        <outgoingServer type="smtp">
            <hostname>smtp.example.com</hostname>
            <port>465</port>
            <socketType>SSL</socketType>
            <username>%EMAILADDRESS%</username>
            <authentication>password-cleartext</authentication>
        </outgoingServer>
        <clientConfigUpdate url="https://autoconfig.example.com/mail/config-v1.1.xml" />
    </clientConfig>

对于不需要的配置如果不是需要保留为空值, 那么应该在配置文件中移除.

RFC 6186

RFC 6186 的响应是基于 DNS 的 SRV 记录, 所以实现响应的标准就是 SRV 记录(RFC 2782^[4]).

SRV 记录标准:

1	_Service._Proto.Name TTL Class SRV Priority Weight Port Target

使用 ZONE 进行命名就是:

1	_[服务类型]._[协议].[域名名称] [生存时间] IN SRV [优先级] [权重] [端口] [目标服务器]

比如:

1	_minecraft._tcp.minecraft.example.com 3600 IN SRV 0 1 19132 minecraft.hoster.com.

部署与应用

依据在协议响应规范中提到的各自的发现行为, 除了 RFC 6186, 实现只需要在对应域名设置 DNS 即可. Autodiscover 和 Autoconfiguration 按照对应需要解析 DNS 并放置配置文件至对应域名的固定路径即可实现部署.

Autodiscover

标准实现

编写正确规范的 XML 配置文件.
将电子邮件地址使用的域名解析到一个用于托管配置文件的网络服务器. 如:
1
example.com 3600 IN A 1.0.0.1
将配置文件放入网络服务器, 使其路径为: /Autodiscover/Autodiscover.xml.
再次解析邮件地址域名的子域名 autodiscover 到配置文件服务器:
1
autodiscover.example.com 3600 IN A 1.0.0.1
将配置文件放入网络服务器, 使其路径为: /Autodiscover/Autodiscover.xml

多个配置文件理论并不会相互覆盖, 因为只会使用最先被发现的的那一个配置文件, 其目的是为了冗余. 但是不同客户端可能存在不同的行为, 所以建议同时设置多个方法且保证配置文件内容相同. 如果当前 DNS 解析状况导致解析已存在或不允许再次占用, 那么应该向后选择不冲突的那一种实现方式.

当然使用 CNAME 也是可以的, 因为会自动到 DNS 中的 CNAME 域名寻找.

跳转实现

从 Autodiscover 响应规范小节可以看出, 配置文件中存在一个 RedirectUrl 的标签, 可以让电子邮件客户端解析到时跳转到下一个网络配置文件路径.

因此可以将当前电子邮件域名的两个用于 Autodiscover 的 DNS 记录解析后在网络服务器对应的路径放入一个只用于重定向跳转的 XML:

XML 格式应该为:

Autodiscover.xml

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response
        xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <Account>
            <AccountType>email</AccountType>
            <Action>redirectUrl</Action>
            <RedirectUrl>https://filesystem.example.com/autodiscover/example.com/Autodiscover.xml</RedirectUrl>
        </Account>
    </Response>
</Autodiscover>

这样就能将当前电子邮件域名的配置文件重定向到另一个网络文件路径

这样做的好处是能够将大量的域名电子邮件配置集中在一个网络文件系统中管理, 这个文件系统可以是你的服务商管理也可以是企业的 IT 管理员管理, 作为客户及最终用户可以免去维护 XML 配置的步骤. 如果多个域名都使用了相同的电子邮件服务器或电子邮件服务提供商, 那么这些电子邮件服务器的提供的客户端配置一般都是相同的.

但相比直接使用 CNAME 的跳转发现, 还需要配置一个用于跳转的 XML, 所以其实并不太理想. 这样的跳转实现大多用在 Outlook 本地安装的情况, 在本地设备上一次性使用注册表或者组策略将 Outlook 的 Autodiscover 指向这个跳转文件.

除了使用 HTTP 跳转, 还能跳转到另一个邮箱地址进行发现, XML 格式为:

Autodiscover.xml

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response
        xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
        <Account>
            <AccountType>email</AccountType>
            <Action>redirectAddr</Action>
            <RedirectAddr>[email protected]</RedirectAddr>
        </Account>
    </Response>
</Autodiscover>

同样的, 这样会让客户端解析到这个 XML 文件后直接跳转到 [email protected] 对这个邮箱地址的 example.net 的域名进行配置文件发现. 相较于直接配置一个 XML 的好处是: 避免跳转 URL 的修改可能无法及时同步到用于本地配置. 所以使用了跳转到另一个邮箱域名进行重新发现.

多种配置模式适用于不同的电子邮件系统架构和组织部署环境, 需要按照需求选择合适自身的方法.

Autoconfiguration

标准实现

编写正确规范的 XML 配置文件.
1. 将电子邮件地址使用的域名的子域名 autoconfig 解析到一个用于托管配置文件的网络服务器, 如:
  1
  autoconfig.example.com 3600 IN A 1.0.0.1
2. 将配置文件放入网络服务器, 使其路径为: /mail/config-v1.1.xml.
编写正确规范的 XML 配置文件.
1. 将电子邮件域名直接解析至配置文件服务器:
  1
  example.com 3600 IN A 1.0.0.1
2. 将配置文件放入网络服务器, 使其路径为: /.well-known/autoconfig/mail/config-v1.1.xml
编写正确规范的 XML 配置文件.
1. 将其电子邮件域名的子域名 www 解析至网络服务器, 并将 XML 文件放入该网络文件服务器, 使其为任意便于管理的路径, 如 /autoconfig/example.com/config-v1.1.xml.
2. 为电子邮箱域名添加一个 TXT 记录, 值为上一步放置的 XML 文件完整的 HTTP/HTTPS 网络路径:
  1
  example.com 3600 IN TXT "https://www.example.com/autoconfig/example.com/config-v1.1.xml"

中心化实现

本文将 Autoconfiguration 实现方法中, 需要依赖第三方中心化服务实现自动发现的方式称为 "中心化实现". 比如这里要提到的 "尝试从 Mozilla 服务器检索配置".

由 Thunderbird 维护并托管的电子邮件服务商配置文件数据库称为 "ISPDB", 可免费供给任何用户(客户)使用. 它包含了最多的电子邮件服务商配置, 大多市场份额超过 0.1% 的服务商都包含在内, 几乎囊括了全球 50% 的电子邮件账户.

但要注意, 并不是随便一个服务商就能进入这个数据库, 比如自托管的个人电子邮件服务器就不符合要求. ISPDB 要求:

If you are a big ISP (> 100,000 users) providing email addresses solely under a few domains like "example.com" and "example.de", you may either submit the configuration to the ISPDB or set up a configuration server.^[5]

"如果您是大型 ISP(> 100,000 个用户), 仅在 "example.com" 和 "example.de" 等几个域下提供电子邮件地址, 您可以将配置提交到 ISPDB 或设置配置服务器."^[5:1]

If you are a small company installing Thunderbird on your employees' desktops, you can place a configuration file in the Thunderbird installation folder.^[5:2]

如果您是在员工桌面上安装 Thunderbird 的小公司, 您可以将配置文件放在 Thunderbird 安装文件夹中.^[5:3]

如果想要为自己的电子邮件服务能够通过 Mozilla 服务器查找到服务器配置, 那么除去需要在客户端支持从 ISPDB 中检索, 还要为该服务的源 Git 仓库提交你的 Autoconfiguration 配置文件:

thundernest/autoconfig: The ISPDB, Thunderbird's database of mail configuration files.

源仓库存在两分支的配置文件索引, 一个是 prod 分支, 直接用于 Thunderbird(https://autoconfig.thunderbird.net/autoconfig/v1.1/); 另一个是 master 分支, 用于暂存服务器(https://autoconfig-stage.thunderbird.net/autoconfig/v1.1/).

RFC 6186

RFC 6186^[2:2] 制定的目的就是为了解决从域名中发现电子邮件服务器配置的问题, SMTP^[1:1] 本身存在对 MX 记录进行发现进而查找到对应的服务器主机, 但是现代邮件系统中的 MSA 不使用 MX 记录以及工作端口是 587. 于是这个规范设计来与 RFC 4409 联合使用.

在由 RFC 4409^[6] 确立的现代的电子邮件提交系统里, 在用户发送电子邮件时, 需要通过 MSA(Message submission agent, 消息提交代理)进行处理才能传输到邮件服务器或中继服务器. 通常来说, 最终用户使用的传出服务器基本都是 MSA 系统, 这样避免了恶意提交对邮件服务器的侵害, 也能保护用户身份不被盗用.

这个标准中定义了对 MSA, IMAP 和 POP3 进行配置的新 SRV 记录类型, 并且还可以定义优先使用哪一种传入协议.

值得一提的是, RFC 6186 是由 Apple 起草发起的, RFC 4409 主要作者之一是 Qualcomm(高通).

实现标准

MSA

使用如下的 SRV 记录指向 MSA 服务:

1	_submission._tcp 3600 IN SRV 0 1 587 mail.example.com.

IMAP
- 使用 imap 标识一个普通 IMAP 服务类型.
对于 STARTTLS 应该是客户端和 IMAP 服务器必须实现的, 但有的服务商可能并不需要使用.
- 使用 imaps 表示一个使用 TLS 连接的 IMAP 服务器.
使用如下的 SRV 记录指向 IMAP 服务:
1
_imap._tcp 3600 IN SRV 0 1 143 imap.example.com.
1
_imaps._tcp 3600 IN SRV 0 1 993 imap.example.com.
POP3
- 使用 pop3 标识一个可能会需要客户端使用 STLS^[7] 进行连接的普通 POP3 服务器.
- 使用 pop3s 标识一个使用 TLS 连接的 POP3 服务器.
使用如下的 SRV 记录指向 POP3 服务:
1
_pop3._tcp 3600 IN SRV 0 1 110 pop3.example.com.
1
_pop3s._tcp 3600 IN SRV 0 1 995 pop3.example.com.

优先级指定

由于 SRV 记录允许为服务指定优先级, 所以如果同时在 DNS 中解析指向了多种服务类型, 那么管理员可以通过指定 SRV 记录优先级表示服务端对服务类型的偏好.

SRV 记录与 MX 记录指定优先级的概念相同, 是以优先级数字编号越小代表越优先(权重恰恰相反, 数字越大表示权重越高, 但在 SRV 里优先使用优先级, 如果优先级相同再使用权重判定).

通过设置优先级, 将希望优先被采用的传入服务器配置记录使其小于其他的服务记录实现服务端偏好设置.

优先使用 IMAP 而不是 POP3:

1	_imap._tcp 3600 IN SRV 0 1 143 imap.example.com.

1	_pop3._tcp 3600 IN SRV 10 1 110 pop3.example.com.

通过将 SRV 记录中的目标服务器值设置为 . 来表示该域完全不支持此服务. 如果存在这种记录值, 则电子邮件客户端应该认为这种服务器不可用, 并继续使用 SRV 记录进行确定.

比如, 通过以下的记录值

1	_imap._tcp 3600 IN SRV 0 0 0 .

1	_imaps._tcp 3600 IN SRV 0 1 993 imap.example.com.

1	_pop3._tcp 3600 IN SRV 0 0 0 .

1	_pop3s._tcp 3600 IN SRV 10 1 995 pop3.example.com.

上面的记录值指定本域中存在使用 TLS 和不使用 TLS 的 IMAP 服务和 POP3 服务(带 s 和不带 s), 但是不使用 TLS 的 IMAP 和 POP3 服务不可用. 且使用 IMAPs 服务的优先级高于使用 POP3s, 因为 IMAPs 的优先级 0 要比 POP3s 的优先级 10 要小.

现状与未来

到此为止, 本文就介绍完目前所有去中心化且主流的实现自动发现方式了.

那么现在在电子邮件中的自动发现是一个什么样的情况? 未来呢?

现状

目前文中提到的自动发现, 对于 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)"?🥱

前言

区别与实现

Autodiscover

Autoconfiguration

RFC 6186

协议响应规范

Autodiscover

Autoconfiguration

RFC 6186

部署与应用

Autodiscover

标准实现

跳转实现

Autoconfiguration

标准实现

中心化实现

RFC 6186

实现标准

优先级指定

现状与未来

现状

未来

参考资料