非官方中文译本声明：本页为 IETF RFC 6186《Use of SRV Records for Locating Email Submission/Access Services》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc6186。

RFC 6186：用 SRV 记录定位邮件服务

标准跟踪 · C. Daboo · Apple Inc. · 2011 年 3 月 · 类别：Standards Track（标准跟踪）· 更新 RFC 1939、RFC 3501 · ISSN: 2070-1721

摘要

本规范描述了如何使用 SRV 记录来定位邮件服务。

本备忘录的状态

本文档是互联网标准跟踪（Standards Track）文档。

本文档是互联网工程任务组（IETF）的成果，代表了 IETF 社区的共识。它已经过公开评审，并由互联网工程指导组（IESG）批准发布。有关互联网标准的更多信息见 RFC 5741 第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc6186 获取。

Copyright (c) 2011 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含简化 BSD 许可证文本（如信托法律条款第 4.e 节所述），并按简化 BSD 许可证所述"不提供担保"地提供。

目录

1. 引言

互联网电子邮件协议包括 SMTP [RFC5321]、IMAP [RFC3501] 与 POP3 [RFC1939]。IMAP 与 POP3 都是邮件存储访问协议，由邮件存储用户代理（MUA）用于在邮件投递后操作电子邮件报文。[RFC4409] 定义了 SMTP 服务的一个"配置（profile）"，专门供邮件提交使用。MUA 应当使用这种方式将报文提交给邮件提交代理（MSA）。

[RFC2782] 定义了一种基于 DNS 的服务发现协议，该协议已被广泛采用，作为在局域网及更广范围内定位特定服务的一种手段，其使用的是 DNS SRV 资源记录（RR）。

[RFC5321] 规定了如何使用 DNS MX 记录来为某个域定位 SMTP 服务。然而，MUA 应当使用 [RFC4409] 中定义的提交协议，而该协议并不使用 MX 记录。

通常，MUA 要求用户输入其所需服务的完全限定域名（FQDN）与端口信息。这并不理想，因为服务器配置信息的指定方式可能随 MUA 不同而不同，容易让用户感到困惑，导致在录入细节时出错。作为一种替代，部分 MUA 采用了复杂的"自动发现"流程，通过探测某个域来查看可能提供哪些服务。对所有这些情况而言，更好的做法是只要求用户输入最少的信息，从而自动为其配置合适的服务。所输入的最少信息就是用户的电子邮件地址。

本规范为邮件提交、IMAP 与 POP3 服务定义新的 SRV 服务类型，以实现 MUA 的简单自动配置。SRV 记录的优先级（priority）字段也可用于指示对某一邮件存储访问协议的偏好高于另一协议。

2. 本文档使用的约定

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"MAY（可以）"和"OPTIONAL（可选）"应按 [RFC2119] 所述进行解释。

本文使用了 [RFC5598] 中的电子邮件相关术语。

3. SRV 服务标签

3.1. 邮件提交

本规范为邮件提交 [RFC4409] 新增一个 SRV 服务标签：

submission：标识使用 [RFC4409] 的 MSA。注意，这同时涵盖带与不带传输层安全（TLS）[RFC5246] 的连接，如 [RFC3207] 为 SMTP 所定义的那样。

示例：服务记录

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

3.2. IMAP

本规范为 IMAP [RFC3501] 新增两个 SRV 服务标签：

_imap：标识一个 IMAP 服务器，它可以（MAY）通告 "LOGINDISABLED" 能力，并可以（MAY）要求 MUA 在认证前使用 "STARTTLS" 命令。尽管这两个扩展对 MUA 与 IMAP 服务器都是"必须实现（mandatory-to-implement）"的，但服务提供商并非必须（not mandatory）使用它们。

_imaps：标识一个 IMAP 服务器，在该服务器上，TLS [RFC5246] 于连接建立后即刻发起。

示例：服务记录

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

示例：服务记录

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

3.3. POP3

本规范为 POP3 [RFC1939] 新增两个 SRV 服务标签：

_pop3：标识一个 POP3 服务器，它可以（MAY）要求 MUA 在认证前使用 "STLS" 扩展命令 [RFC2595]。

_pop3s：标识一个 POP3 服务器，在该服务器上，TLS [RFC5246] 于连接建立后即刻发起。

示例：服务记录

    _pop3._tcp     SRV 0 1 110 pop3.example.com.

示例：服务记录

    _pop3s._tcp    SRV 0 1 995 pop3.example.com.

3.4. 域偏好优先级

SRV 记录中的优先级（priority）字段允许一个域指示：在 DNS 查询结果中，某些记录比其他记录具有更高的偏好（由这些记录具有较小数值的优先级值来确定）。通常，这用于在单个服务标签的一组记录中进行选择；然而，它并不局限于仅在单一服务内部进行选择。

一个站点常常会同时为用户提供 IMAP 与 POP3 这两种邮件存储访问服务。但是，该站点可能对其中之一有所偏好，并希望将该偏好传达给用户，以确保：当用户拥有能够同时使用 IMAP 与 POP3 的 MUA 时，使用的是其偏好的选择。

为辅助这一选择，站点应该（SHOULD）在其 DNS 中同时提供 IMAP（_imap 和/或 _imaps）与 POP3（_pop3 和/或 _pop3s）这两组 SRV 记录，并为这些记录组设置优先级，使得"被偏好"的服务的优先级值小于另一服务。当某个 MUA 同时支持 IMAP 与 POP3 时，它应该（SHOULD）检索这两种服务的记录，然后使用优先级值最小的服务。若两种服务的优先级相同，MUA 可自由选择其中合适的那一个。当考虑不同协议、优先级相同但权重（weight）不同的多条记录时，客户端必须（MUST）首先选择它打算使用的协议，然后对与该选定协议相关联的记录执行 [RFC2782] 中给出的权重选择算法。

示例：IMAP 与 POP3 的服务记录，其中 IMAP 具有比 POP3（10）更小的优先级值（0），向 MUA 表明：当 MUA 能够支持任一服务时，IMAP 优先于 POP3。

    _imap._tcp     SRV  0 1 143 imap.example.com.
    _pop3._tcp     SRV 10 1 110 pop3.example.com.

此外，借助 SRV 记录，还可以通过将某条 SRV 记录的目标（target）设为 "."，来表明某个特定服务在某个特定域上完全不受支持。如果存在此类记录，客户端必须（MUST）假定指定的服务不可用，转而利用其他 SRV 记录来确定域偏好。

示例：IMAP 与 POP3 的服务记录，同时提供了带 TLS 与不带 TLS 两种服务类型。IMAP 与 POP3 的不带 TLS 服务类型均被标记为不可用。IMAP（带 TLS）具有比 POP3（带 TLS，优先级 10）更小的优先级值 0，向 MUA 表明：当 MUA 能够支持任一服务、且仅有带 TLS 版本的服务可用时，IMAP 优先于 POP3。

    _imap._tcp     SRV  0 0 0   .
    _imaps._tcp    SRV  0 1 993 imap.example.com.
    _pop3._tcp     SRV  0 0 0   .
    _pop3s._tcp    SRV 10 1 995 pop3.example.com.

4. 面向 MUA 的指引

通过上述方式使用 SRV 记录，MUA 初始只需提示用户输入其电子邮件地址 [RFC5322]。"local-part"与"domain"两个部分随后由 MUA 从该电子邮件地址中提取。MUA 将"domain"部分用作服务域，对其想要配置的服务执行 SRV 查询。若 SRV 查询成功，便可确定该服务的目标 FQDN 与端口，并用于完成 MUA 配置。若未找到 SRV 记录，MUA 就需要提示用户直接输入 FQDN 与端口信息，或采用其他某种启发式方法。对于为某项特定服务返回的多条 SRV 记录，MUA必须（MUST）使用记录中的优先级与权重字段来确定使用哪一条（依 [RFC2782]）。

同时支持 POP3 与 IMAP 的 MUA，在两者均被提供时，使用第 3.4 节中的过程在两项服务之间进行选择。

配置完成后，MUA 将连接到该服务。当使用 "imaps" 或 "pop3s" 服务时，TLS [RFC5246] 协商于连接建立后即刻进行。对于 "imap"、"pop3" 与 "submission" 服务，则分别使用 "STARTTLS"、"STLS" 与 "STARTTLS" 命令来发起受 TLS [RFC5246] 保护的连接。以这种方式使用 TLS 时，MUA应该（SHOULD）使用 TLS 服务器名称指示（Server Name Indication）[RFC6066]。证书验证必须（MUST）采用 [RFC6125] 第 6 节所述、以 SRV 记录为起点的验证流程。

一旦建立了合适的连接并设置了所需的任何保护，MUA 通常就需要与 IMAP、POP3 或 SMTP（submission）服务器进行认证。这方面细节由具体协议本身规定，尽管往往需要某种形式的用户/口令认证所需的"用户标识符"。当需要用户标识符时，MUA必须（MUST）首先使用用户提供的完整电子邮件地址；若因此导致认证失败，则应该（SHOULD）回退到使用从电子邮件地址提取的 "local-part"。这与第 5 节所述指引一致。若这两种用户标识符都导致认证失败，MUA应该（SHOULD）提示用户输入有效的标识符。

一旦完成了成功的连接与认证，MUA应该（SHOULD）缓存成功使用的服务细节（主机名、端口、用户身份），并在后续再次连接时复用这些细节。

若后续的连接尝试失败，或认证失败，MUA应该（SHOULD）重新执行 SRV 查询，以"刷新"客户端此前选定协议的缓存数据；也就是说，这意味着：除非有用户交互，否则客户端不得（MUST NOT）因相应 SRV 优先级的变化而从 IMAP 服务切换到 POP3（或反之）。

5. 面向服务提供商的指引

希望提供可由 MUA 使用 SRV 记录配置的 IMAP、POP3 或 SMTP（submission）服务，服务提供商需要遵循若干准则，以确保正常运行。

a. IMAP、POP3 与 SMTP（submission）服务器应该（SHOULD）配置为允许使用电子邮件地址或电子邮件 local-part 进行认证。对于前者，电子邮件地址不得（MUST NOT）与其他允许的登录名形式冲突。对于后者，电子邮件 local-part 需要在服务器范围内唯一，且不得（MUST NOT）与服务器上任何登录名冲突。

b. 若服务提供商使用 TLS [RFC5246]，则服务提供商必须（MUST）确保安装了一张可由 MUA 依据 [RFC6125] 第 6 节所述、以 SRV 记录为起点的验证流程所验证的证书。若服务提供商在同一 IP 地址上托管多个域，则服务提供商必须（MUST）启用对 TLS 服务器名称指示（Server Name Indication）[RFC6066] 的支持。

c. 为所提供的服务安装恰当的 SRV 记录。

6. 安全考量

若用户明确要求使用传输层安全机制建立连接（用户界面有时会以"使用 SSL"或"安全连接"复选框的形式呈现这一选择），则 MUA必须（MUST）在发送认证命令之前成功协商传输层安全。例如，MUA 可以通过 "imaps"、"pop3s"、带 "STARTTLS" 的 "imap"，或带 "STLS" 的 "pop3" 来实现这一点。服务提供商可以（MAY）为邮件服务提供这四种选项中的任意子集。

一个能够访问 DNS 服务器数据、或能让伪造应答被缓存进递归解析器的恶意攻击者，有可能使 MUA 连接到攻击者选定的任意 IMAP、POP3 或 submission 服务器。在没有安全 DNS 选项的情况下，MUA应该（SHOULD）检查 SRV 记录中返回的目标 FQDN 是否与最初被查询的服务域相匹配。若目标 FQDN 不在被查询的域内，MUA应该（SHOULD）在与该主机建立任何连接之前，先与用户确认该 SRV 目标 FQDN 是否适合使用。作为替代，若电子邮件服务正在使用 TLS [RFC5246]，则 MUA必须（MUST）使用 [RFC6125] 第 6 节所述流程来验证该服务。

TLS [RFC5246] 的实现通常支持该协议的多个版本，以及较旧的安全套接字层（SSL）协议。由于已知的安全漏洞，电子邮件客户端与电子邮件服务器不得（MUST NOT）请求、提供或使用 SSL 2.0。更多细节见 [RFC5246] 的附录 E.2。

7. 致谢

感谢 Tony Finch、Ned Freed、Alfred Hoenes、Suresh Krishnan、Alexey Melnikov、Chris Newman 与 Phil Pennock 提供的反馈与建议。本工作的部分内容基于 John Klensin 与 Eric Hall 此前起草的一份文档。

8. 参考文献

8.1. 规范性参考文献

[RFC1939] Myers, J. 与 M. Rose，《Post Office Protocol - Version 3（邮局协议 — 第 3 版）》，STD 53，RFC 1939，1996 年 5 月。

[RFC2119] Bradner, S.，《Key words for use in RFCs to Indicate Requirement Levels（用于 RFC 中以指示需求级别的关键词）》，BCP 14，RFC 2119，1997 年 3 月。

[RFC2595] Newman, C.，《Using TLS with IMAP, POP3 and ACAP（在 IMAP、POP3 与 ACAP 中使用 TLS）》，RFC 2595，1999 年 6 月。

[RFC2782] Gulbrandsen, A.、Vixie, P. 与 L. Esibov，《A DNS RR for specifying the location of services (DNS SRV)（用于指定服务位置的 DNS 资源记录（DNS SRV））》，RFC 2782，2000 年 2 月。

[RFC3207] Hoffman, P.，《SMTP Service Extension for Secure SMTP over Transport Layer Security（基于传输层安全的 SMTP 安全扩展）》，RFC 3207，2002 年 2 月。

[RFC3501] Crispin, M.，《INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1（互联网消息访问协议 — 第 4rev1 版）》，RFC 3501，2003 年 3 月。

[RFC4409] Gellens, R. 与 J. Klensin，《Message Submission for Mail（邮件提交）》，RFC 4409，2006 年 4 月。

[RFC5246] Dierks, T. 与 E. Rescorla，《The Transport Layer Security (TLS) Protocol Version 1.2（传输层安全（TLS）协议 第 1.2 版）》，RFC 5246，2008 年 8 月。

[RFC5321] Klensin, J.，《Simple Mail Transfer Protocol（简单邮件传输协议）》，RFC 5321，2008 年 10 月。

[RFC5322] Resnick, P.（编），《Internet Message Format（互联网报文格式）》，RFC 5322，2008 年 10 月。

[RFC6066] Eastlake, D.，《Transport Layer Security (TLS) Extensions: Extension Definitions（传输层安全（TLS）扩展：扩展定义）》，RFC 6066，2011 年 1 月。

[RFC6125] Saint-Andre, P. 与 J. Hodges，《Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)（在传输层安全背景下使用 X.509（PKIX）证书对基于域的应用服务身份进行表示与验证）》，RFC 6125，2011 年 3 月。

8.2. 资料性参考文献

[RFC5598] Crocker, D.，《Internet Mail Architecture（互联网邮件架构）》，RFC 5598，2009 年 7 月。

作者地址

Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA

EMail: cyrus@daboo.name
URI: http://www.apple.com/