Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6186 Apple Inc.
Updates: 1939, 3501 March 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Daboo
Request for Comments: 6186 Apple Inc.
Updates: 1939, 3501 March 2011
Category: Standards Track
ISSN: 2070-1721
Use of SRV Records for Locating Email Submission/Access Services
使用SRV记录查找电子邮件提交/访问服务
Abstract
摘要
This specification describes how SRV records can be used to locate email services.
本规范描述了如何使用SRV记录定位电子邮件服务。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6186.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6186.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 3
3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 4
4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
5. Guidance for Service Providers . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 3
3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 4
4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
5. Guidance for Service Providers . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Internet email protocols include SMTP [RFC5321], IMAP [RFC3501], and POP3 [RFC1939]. IMAP and POP3 are both message store access protocols used by message store user agents (MUAs) to manipulate email messages after delivery. [RFC4409] defines a "profile" of the SMTP service that is specifically used for message submission. MUAs are expected to submit messages to mail submission agents (MSAs) using this approach.
Internet电子邮件协议包括SMTP[RFC5321]、IMAP[RFC3501]和POP3[RFC1939]。IMAP和POP3都是MessageStore用户代理（MUA）用于在邮件传递后操作电子邮件的邮件存储访问协议。[RFC4409]定义专门用于邮件提交的SMTP服务的“配置文件”。MUA将使用这种方法向邮件提交代理（MSA）提交邮件。
[RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using DNS SRV resource records (RRs).
[RFC2782]定义了一种基于DNS的服务发现协议，该协议已被广泛采用，作为使用DNS SRV资源记录（RRs）在局域网内外定位特定服务的一种手段。
[RFC5321] specifies how to use DNS MX RRs to locate SMTP services for a domain. However, MUAs are expected to use the submission protocol defined in [RFC4409], which does not use MX records.
[RFC5321]指定如何使用DNS MX RRs查找域的SMTP服务。但是，预期MUA将使用[RFC4409]中定义的提交协议，该协议不使用MX记录。
Typically MUAs have required users to enter a fully qualified domain name (FQDN) and port information for the services they need. This is not ideal as the way in which server configuration information is specified can differ from MUA to MUA, and can be confusing to users, leading to errors when inputting the details. Alternatively, some MUAs have adopted a complex "auto-discovery" process involving probing a domain to see what services might be available. A better approach to all this would be to require minimal information to be entered by a user that would result in automatic configuration of appropriate services for that user. The minimal information entered would be the user's email address.
通常，MUA要求用户输入所需服务的完全限定域名（FQDN）和端口信息。这并不理想，因为指定服务器配置信息的方式可能因MUA而异，并且可能会让用户感到困惑，从而导致在输入详细信息时出错。或者，一些MUA采用了复杂的“自动发现”过程，包括探测域以查看哪些服务可用。解决所有这些问题的更好方法是要求用户输入最少的信息，从而为该用户自动配置适当的服务。输入的最少信息是用户的电子邮件地址。
This specification defines new SRV service types for the message submission, IMAP, and POP3 services, to enable simple auto-configuration of MUAs. The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another.
本规范为消息提交、IMAP和POP3服务定义了新的SRV服务类型，以实现MUA的简单自动配置。SRV记录的优先级字段还可用于指示一种消息存储访问协议优于另一种。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Email-related terminology from [RFC5598] is used.
使用[RFC5598]中与电子邮件相关的术语。
This specification adds one SRV service label for message submission [RFC4409]:
本规范为消息提交添加了一个SRV服务标签[RFC4409]：
submission: Identifies an MSA using [RFC4409]. Note that this covers connections both with and without Transport Layer Security (TLS) [RFC5246] as defined for SMTP in [RFC3207].
提交：使用[RFC4409]标识MSA。请注意，这涵盖了[RFC3207]中为SMTP定义的带和不带传输层安全性（TLS）[RFC5246]的连接。
Example: service record
示例：服务记录
_submission._tcp SRV 0 1 587 mail.example.com.
_提交。_TCPSRV 0 1 587 mail.example.com。
This specification adds two SRV service labels for IMAP [RFC3501]:
本规范为IMAP[RFC3501]添加了两个SRV服务标签：
_imap: Identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the MUA to use the "STARTTLS" command prior to authentication. Although these two extensions are mandatory-to-implement for both MUAs and IMAP servers, they are not mandatory-to-use by service providers.
_imap：标识一个imap服务器，该服务器可能会公布“LOGINDISABLED”功能，并可能要求MUA在身份验证之前使用“STARTTLS”命令。尽管这两个扩展是MUAs和IMAP服务器必须实现的，但服务提供商不必使用它们。
_imaps: Identifies an IMAP server where TLS [RFC5246] is initiated directly upon connection to the IMAP server.
_imaps：标识一个IMAP服务器，其中TLS[RFC5246]在连接到IMAP服务器时直接启动。
Example: service record
示例：服务记录
_imap._tcp SRV 0 1 143 imap.example.com.
_imap._TCPSRV 0 1 143 imap.example.com。
Example: service record
示例：服务记录
_imaps._tcp SRV 0 1 993 imap.example.com.
_imaps._TCPSRV 0 1 993 imap.example.com。
This specification adds two SRV service labels for POP3 [RFC1939]:
本规范为POP3[RFC1939]添加了两个SRV服务标签：
_pop3: Identifies a POP3 server that MAY require the MUA to use the "STLS" extension command [RFC2595] prior to authentication.
_pop3：标识可能要求MUA在身份验证之前使用“STL”扩展命令[RFC2595]的pop3服务器。
_pop3s: Identifies a POP3 server where TLS [RFC5246] is initiated directly upon connection to the POP3 server.
_POP3：标识连接到POP3服务器时直接启动TLS[RFC5246]的POP3服务器。
Example: service record
示例：服务记录
_pop3._tcp SRV 0 1 110 pop3.example.com.
_pop3._TCPSRV 0 1 110 pop3.example.com。
Example: service record
示例：服务记录
_pop3s._tcp SRV 0 1 995 pop3.example.com.
_pop3s._TCPSRV 0 1 995 pop3.example.com。
The priority field in the SRV RR allows a domain to indicate that some records have a higher preference than others in the DNS query results (determined by those records having a lower-numbered priority value). Typically, this is used for choosing a record from a set for a single service label; however, it is not restricted to choice within only one service.
SRV RR中的优先级字段允许域在DNS查询结果中指示某些记录比其他记录具有更高的优先级（由具有较低编号优先级值的记录确定）。通常，这用于从单个服务标签的集合中选择记录；但是，它并不局限于仅在一个服务中进行选择。
Often a site will offer both IMAP and POP3 message store access services for users. However, the site may have a preference for one over the other that they want to convey to the user to ensure that, when the user has an MUA capable of using both IMAP and POP3, the preferred choice is used.
通常，一个站点会为用户提供IMAP和POP3消息存储访问服务。然而，站点可能对它们想要传达给用户的其中一个具有偏好，以确保当用户具有能够同时使用IMAP和POP3的MUA时，使用偏好选择。
To aid with this choice, sites SHOULD offer both sets of IMAP (_imap and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their DNS and set the priority for those sets of records such that the "preferred" service has a lower-numbered priority value than the other. When an MUA supports both IMAP and POP3, it SHOULD retrieve records for both services and then use the service with the lowest priority value. If the priority is the same for both services, MUAs are free to choose whichever one is appropriate. When considering multiple records for different protocols at the same priority but with different weights, the client MUST first select the protocol it
为了帮助进行此选择，站点应在其DNS中同时提供IMAP（_IMAP和/或_IMAP）和POP3（_POP3和/或_POP3）SRV记录集，并为这些记录集设置优先级，以便“首选”服务的编号优先级值低于其他服务。当MUA同时支持IMAP和POP3时，它应该检索这两个服务的记录，然后使用优先级最低的服务。如果两种服务的优先级相同，MUA可以自由选择合适的优先级。当考虑具有相同优先级但权重不同的不同协议的多个记录时，客户端必须首先选择它所使用的协议
intends to use, then perform the weight selection algorithm given in [RFC2782] on the records associated with the selected protocol.
打算对与所选协议相关联的记录使用[RFC2782]中给出的权重选择算法，然后执行该算法。
Example: service records for both IMAP and POP3, with IMAP having a lower-numbered priority value (0) than POP3 (10), indicating to the MUA that IMAP is preferred over POP3, when the MUA can support either service.
示例：IMAP和POP3的服务记录，其中IMAP的编号优先级值（0）低于POP3（10），这向MUA表明，当MUA可以支持任一服务时，IMAP优先于POP3。
_imap._tcp SRV 0 1 143 imap.example.com. _pop3._tcp SRV 10 1 110 pop3.example.com.
_imap._TCPSRV 0 1 143 imap.example.com_pop3._TCPSRV 10 1 110 pop3.example.com。
In addition, with SRV RRs it is possible to indicate that a particular service is not supported at all at a particular domain by setting the target of an SRV RR to ".". If such records are present, clients MUST assume that the specified service is not available, and instead make use of the other SRV RRs for the purposes of determining the domain preference.
此外，使用SRV RRs，通过将SRV RR的目标设置为“”，可以指示特定域中根本不支持特定服务。如果存在此类记录，则客户端必须假定指定的服务不可用，并使用其他SRV RRs来确定域首选项。
Example: service records for IMAP and POP3 with both TLS and non-TLS service types are present. Both IMAP and POP3 non-TLS service types are marked as not available. IMAP (with TLS) has a lower-numbered priority value 0 than POP3 (with TLS) at priority 10, indicating to the MUA that IMAP is preferred over POP3, when the MUA can support either service, and only the TLS versions of the services are available.
示例：存在具有TLS和非TLS服务类型的IMAP和POP3的服务记录。IMAP和POP3非TLS服务类型都标记为不可用。IMAP（带TLS）的编号优先级值0低于优先级为10的POP3（带TLS），这向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.
_imap.\u tcp SRV 0_imaps._TCPSRV 0 1 993 imap.example.com_pop3.\u tcp SRV 0_pop3._TCPSRV 10 1 995 pop3.example.com。
By using SRV records as above, MUAs need initially only to prompt the user for their email address [RFC5322]. The "local-part" and "domain" portions are then extracted from the email address by the MUA. The MUA uses the "domain" portion as the service domain to perform SRV lookups for the services it wants to configure. If the SRV lookup is successful, the target FQDN and port for the service can be determined and used to complete MUA configuration. If an SRV record is not found, the MUA will need to prompt the user to enter the FQDN and port information directly, or use some other heuristic. In the case of multiple SRV records returned for a particular service, the MUA MUST use the priority and weight fields in the record to determine which one to use (as per [RFC2782]).
通过如上所述使用SRV记录，MUA最初只需提示用户输入其电子邮件地址[RFC5322]。然后，MUA从电子邮件地址提取“本地部分”和“域”部分。MUA将“域”部分用作服务域，以对其要配置的服务执行SRV查找。如果SRV查找成功，则可以确定服务的目标FQDN和端口，并用于完成MUA配置。如果未找到SRV记录，MUA将需要提示用户直接输入FQDN和端口信息，或者使用其他启发式方法。如果为特定服务返回多个SRV记录，MUA必须使用记录中的优先级和权重字段来确定使用哪一个（根据[RFC2782]）。
MUAs that support both POP3 and IMAP use the procedure in Section 3.4 to choose between each service when both are offered.
同时支持POP3和IMAP的MUA使用第3.4节中的程序在提供两种服务时在每种服务之间进行选择。
Subsequent to configuration, the MUA will connect to the service. When using "imaps" or "pop3s" services, a TLS [RFC5246] negotiation is done immediately upon connection. With "imap", "pop3", and "submission" services, the "STARTTLS", "STLS", and "STARTTLS" commands respectively are used to initiate a protected connection using TLS [RFC5246]. When using TLS in this way, MUAs SHOULD use the TLS Server Name Indication [RFC6066]. Certificate verification MUST use the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point.
配置之后，MUA将连接到服务。当使用“imaps”或“POP3”服务时，TLS[RFC5246]协商在连接后立即完成。对于“imap”、“pop3”和“submission”服务，“STARTTLS”、“STLS”和“STARTTLS”命令分别用于启动使用TLS的受保护连接[RFC5246]。以这种方式使用TLS时，MUA应使用TLS服务器名称指示[RFC6066]。证书验证必须使用[RFC6125]第6节中概述的程序，以SRV RR为起点进行验证。
Once a suitable connection has been made, and any required protection set up, the MUA will typically need to authenticate with the IMAP, POP3, or SMTP (submission) server. The details of that are governed by the specific protocols themselves, though often times a "user identifier" is required for some form of user/password authentication. When a user identifier is required, MUAs MUST first use the full email address provided by the user, and if that results in an authentication failure, SHOULD fall back to using the "local-part" extracted from the email address. This is in line with the guidance outlined in Section 5. If both these user identifiers result in authentication failure, the MUA SHOULD prompt the user for a valid identifier.
一旦建立了合适的连接并设置了任何所需的保护，MUA通常需要通过IMAP、POP3或SMTP（提交）服务器进行身份验证。这方面的细节由特定协议本身控制，尽管某些形式的用户/密码身份验证通常需要“用户标识符”。当需要用户标识符时，MUA必须首先使用用户提供的完整电子邮件地址，如果这导致身份验证失败，则应返回使用从电子邮件地址提取的“本地部分”。这符合第5节中概述的指南。如果这两个用户标识符都导致身份验证失败，MUA应提示用户输入有效标识符。
Once a successful connection and authentication have been done, MUAs SHOULD cache the service details (hostname, port, user identity) that were successfully used, and reuse those when connecting again at a later time.
成功连接和身份验证完成后，MUA应缓存成功使用的服务详细信息（主机名、端口、用户标识），并在以后再次连接时重用这些信息。
If a subsequent connection attempt fails, or authentication fails, MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for the same protocol the client had chosen earlier; i.e., this means that the client MUST NOT change from IMAP service to POP3 (or vice versa) due to changes in the corresponding SRV priorities without user interaction.
如果后续连接尝试失败或身份验证失败，MUA应重新尝试SRV查找，以“刷新”客户端先前选择的相同协议的缓存数据；i、 例如，这意味着在没有用户交互的情况下，客户端不得由于相应SRV优先级的变化而从IMAP服务更改为POP3（反之亦然）。
Service providers wanting to offer IMAP, POP3, or SMTP (submission) services that can be configured by MUAs using SRV records need to follow certain guidelines to ensure proper operation.
想要提供IMAP、POP3或SMTP（提交）服务（可由MUA使用SRV记录配置）的服务提供商需要遵循某些准则以确保正确操作。
a. IMAP, POP3, and SMTP (submission) servers SHOULD be configured to allow authentication with email addresses or email local-parts. In the former case, the email addresses MUST NOT conflict with other forms of permitted user login name. In the latter case, the email local-parts need to be unique across the server and MUST NOT conflict with any login name on the server.
a. IMAP、POP3和SMTP（提交）服务器应配置为允许使用电子邮件地址或电子邮件本地部分进行身份验证。在前一种情况下，电子邮件地址不得与其他形式的允许用户登录名冲突。在后一种情况下，电子邮件本地部分需要在整个服务器上是唯一的，并且不得与服务器上的任何登录名冲突。
b. If the service provider uses TLS [RFC5246], the service provider MUST ensure a certificate is installed that can be verified by MUAs using the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point. If the service provider hosts multiple domains on the same IP address, then the service provider MUST enable support for the TLS Server Name Indication [RFC6066].
b. 如果服务提供商使用TLS[RFC5246]，则服务提供商必须确保安装了可由MUAs使用[RFC6125]第6节中概述的程序验证的证书，该程序以SRV RR为起点进行验证。如果服务提供商在同一IP地址上托管多个域，则服务提供商必须启用对TLS服务器名称指示的支持[RFC6066]。
c. Install the appropriate SRV records for the offered services.
c. 为提供的服务安装适当的SRV记录。
If a user has explicitly requested a connection with a transport layer security mechanism (user interfaces sometimes present this choice as a "use SSL" or "secure connection" checkbox), the MUA MUST successfully negotiate transport layer security prior to sending an authentication command. For example, the MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any subset of these four options for the mail service.
如果用户明确请求使用传输层安全机制进行连接（用户界面有时将此选项显示为“使用SSL”或“安全连接”复选框），MUA必须在发送身份验证命令之前成功协商传输层安全。例如，MUA可以使用“imaps”、“pop3”、“imap”和“STARTTLS”或“pop3”和“STL”来实现这一点。服务提供商可以为邮件服务提供这四个选项中的任何一个子集。
A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause MUAs to connect to any IMAP, POP3, or submission server chosen by the attacker. In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. Alternatively, if TLS [RFC5246] is being used for the email service, MUAs MUST use the procedure outlined in Section 6 of [RFC6125] to verify the service.
恶意攻击者可以访问DNS服务器数据，或者能够获取缓存在递归解析程序中的伪造答案，可能会导致MUA连接到攻击者选择的任何IMAP、POP3或提交服务器。在缺少安全DNS选项的情况下，MUA应检查SRV记录中返回的目标FQDN是否与查询的原始服务域匹配。如果目标FQDN不在查询的域中，MUA应在执行到主机的任何连接之前，与用户验证SRV目标FQDN是否适合使用。或者，如果TLS[RFC5246]用于电子邮件服务，MUAs必须使用[RFC6125]第6节中概述的程序来验证服务。
Implementations of TLS [RFC5246] typically support multiple versions of the protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, email clients and email servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [RFC5246] for further details.
TLS[RFC5246]的实现通常支持协议的多个版本以及较旧的安全套接字层（SSL）协议。由于已知的安全漏洞，电子邮件客户端和电子邮件服务器不得请求、提供或使用SSL 2.0。有关更多详细信息，请参见[RFC5246]的附录E.2。
Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, Alexey Melnikov, Chris Newman, and Phil Pennock for feedback and suggestions. Some of this work is based on a previously drafted document by John Klensin and Eric Hall.
感谢Tony Finch、Ned Freed、Alfred Hoenes、Suresh Krishnan、Alexey Melnikov、Chris Newman和Phil Pennock的反馈和建议。这项工作的一部分是基于约翰·克林森和埃里克·霍尔先前起草的文件。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939]迈尔斯，J.和M.罗斯，“邮局协议-第3版”，STD 53，RFC 1939，1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[RFC2595]Newman，C.，“将TLS与IMAP、POP3和ACAP一起使用”，RFC2595，1999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC3207，2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6125] Saint-Andre, P. and 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)", RFC 6125, March 2011.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务标识”，RFC 61252011年3月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC5598，2009年7月。
Author's Address
作者地址
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo苹果公司，美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
EMail: cyrus@daboo.name
URI: http://www.apple.com/
EMail: cyrus@daboo.name
URI: http://www.apple.com/