Network Working Group R. Siemborski, Ed. Request for Comments: 4954 Google, Inc. Obsoletes: 2554 A. Melnikov, Ed. Updates: 3463 Isode Limited Category: Standards Track July 2007
Network Working Group R. Siemborski, Ed. Request for Comments: 4954 Google, Inc. Obsoletes: 2554 A. Melnikov, Ed. Updates: 3463 Isode Limited Category: Standards Track July 2007
SMTP Service Extension for Authentication
用于身份验证的SMTP服务扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议,并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态,请参考当前版本的“互联网官方协议标准”(STD 1)。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有(C)IETF信托基金(2007年)。
Abstract
摘要
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
本文档定义了一个简单邮件传输协议(SMTP)扩展,SMTP客户端可通过该扩展向服务器指示身份验证机制,执行身份验证协议交换,并可选择为此会话期间的后续协议交互协商安全层。此扩展包括SMTP的简单身份验证和安全层(SASL)的配置文件。
This document obsoletes RFC 2554.
本文件淘汰RFC 2554。
Table of Contents
目录
1. Introduction ....................................................2 2. How to Read This Document .......................................2 3. The Authentication Service Extension ............................3 4. The AUTH Command ................................................3 4.1. Examples ...................................................7 5. The AUTH Parameter to the MAIL FROM command .....................9 5.1. Examples ..................................................10 6. Status Codes ...................................................11 7. Additional requirements on servers .............................12 8. Formal Syntax ..................................................13 9. Security Considerations ........................................14 10. IANA Considerations ...........................................15 11. Normative References ..........................................15 12. Informative References ........................................16 13. Acknowledgments ...............................................17 14. Additional Requirements When Using SASL PLAIN over TLS ........17 15. Changes since RFC 2554 ........................................18
1. Introduction ....................................................2 2. How to Read This Document .......................................2 3. The Authentication Service Extension ............................3 4. The AUTH Command ................................................3 4.1. Examples ...................................................7 5. The AUTH Parameter to the MAIL FROM command .....................9 5.1. Examples ..................................................10 6. Status Codes ...................................................11 7. Additional requirements on servers .............................12 8. Formal Syntax ..................................................13 9. Security Considerations ........................................14 10. IANA Considerations ...........................................15 11. Normative References ..........................................15 12. Informative References ........................................16 13. Acknowledgments ...............................................17 14. Additional Requirements When Using SASL PLAIN over TLS ........17 15. Changes since RFC 2554 ........................................18
This document defines a Simple Mail Transport Protocol (SMTP) extension whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, optionally negotiate a security layer for subsequent protocol interactions during this session and, during a mail transaction, optionally specify a mailbox associated with the identity that submitted the message to the mail delivery system.
本文档定义了简单邮件传输协议(SMTP)扩展,在此扩展中,SMTP客户端可以向服务器指示身份验证机制,执行身份验证协议交换,可以选择协商安全层,以便在此会话期间以及在邮件事务期间进行后续协议交互,(可选)指定与将邮件提交到邮件传递系统的标识关联的邮箱。
This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
此扩展包括SMTP的简单身份验证和安全层(SASL)的配置文件。
When compared to RFC 2554, this document deprecates use of the 538 response code, adds a new Enhanced Status Code, adds a requirement to support SASLprep profile for preparing authorization identities, recommends use of RFC 3848 transmission types in the Received trace header field, and clarifies interaction with SMTP PIPELINING [PIPELINING] extension.
与RFC 2554相比,本文档不推荐使用538响应代码,添加了新的增强状态代码,添加了支持SASLprep配置文件以准备授权标识的要求,建议在接收的跟踪头字段中使用RFC 3848传输类型,并澄清了与SMTP管道的交互[管道]扩大
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中,“C:”和“S:”分别表示客户端和服务器发送的行。
1. The name of this [SMTP] service extension is "Authentication".
1. 此[SMTP]服务扩展名为“身份验证”。
2. The EHLO keyword value associated with this extension is "AUTH".
2. 与此扩展关联的EHLO关键字值为“AUTH”。
3. The AUTH EHLO keyword contains as a parameter a space-separated list of the names of available [SASL] mechanisms. The list of available mechanisms MAY change after a successful STARTTLS command [SMTP-TLS].
3. AUTH EHLO关键字包含可用[SASL]机制名称的空格分隔列表作为参数。成功执行STARTTLS命令[SMTP-TLS]后,可用机制的列表可能会更改。
4. A new [SMTP] verb "AUTH" is defined.
4. 定义了一个新的[SMTP]动词“AUTH”。
5. An optional parameter using the keyword "AUTH" is added to the MAIL FROM command, and extends the maximum line length of the MAIL FROM command by 500 characters.
5. 将使用关键字“AUTH”的可选参数添加到MAIL FROM命令中,并将MAIL FROM命令的最大行长度延长500个字符。
6. This extension is appropriate for the submission protocol [SUBMIT].
6. 此扩展适用于提交协议[SUBMIT]。
AUTH mechanism [initial-response]
验证机制[初始响应]
Arguments: mechanism: A string identifying a [SASL] authentication mechanism.
参数:机制:标识[SASL]身份验证机制的字符串。
initial-response: An optional initial client response. If present, this response MUST be encoded as described in Section 4 of [BASE64] or contain a single character "=".
初始响应:可选的初始客户端响应。如果存在,此响应必须按照[BASE64]第4节中的说明进行编码,或包含单个字符“=”。
Restrictions: After an AUTH command has been successfully completed, no more AUTH commands may be issued in the same session. After a successful AUTH command completes, a server MUST reject any further AUTH commands with a 503 reply.
限制:成功完成AUTH命令后,同一会话中不能再发出AUTH命令。在成功的AUTH命令完成后,服务器必须以503回复拒绝任何进一步的AUTH命令。
The AUTH command is not permitted during a mail transaction. An AUTH command issued during a mail transaction MUST be rejected with a 503 reply.
在邮件事务期间不允许使用AUTH命令。邮件事务期间发出的AUTH命令必须以503回复被拒绝。
Discussion: The AUTH command initiates a [SASL] authentication exchange between the client and the server. The client identifies the SASL mechanism to use with the first parameter of the AUTH command. If the server supports the requested authentication mechanism, it performs the SASL exchange to authenticate the
讨论:AUTH命令启动客户端和服务器之间的[SASL]身份验证交换。客户端识别要与AUTH命令的第一个参数一起使用的SASL机制。如果服务器支持请求的身份验证机制,它将执行SASL交换以对请求进行身份验证
user. Optionally, it also negotiates a security layer for subsequent protocol interactions during this session. If the requested authentication mechanism is invalid (e.g., is not supported or requires an encryption layer), the server rejects the AUTH command with a 504 reply. If the server supports the [ESMTP-CODES] extension, it SHOULD return a 5.5.4 enhanced response code.
使用者可选地,它还为会话期间的后续协议交互协商安全层。如果请求的身份验证机制无效(例如,不受支持或需要加密层),服务器将拒绝带有504回复的AUTH命令。如果服务器支持[ESMTP-CODES]扩展,则应返回5.5.4增强响应代码。
The SASL authentication exchange consists of a series of server challenges and client responses that are specific to the chosen [SASL] mechanism.
SASL身份验证交换由一系列特定于所选[SASL]机制的服务器质询和客户端响应组成。
A server challenge is sent as a 334 reply with the text part containing the [BASE64] encoded string supplied by the SASL mechanism. This challenge MUST NOT contain any text other than the BASE64 encoded challenge.
服务器质询作为334应答发送,文本部分包含SASL机制提供的[BASE64]编码字符串。此质询不能包含BASE64编码质询以外的任何文本。
A client response consists of a line containing a [BASE64] encoded string. If the client wishes to cancel the authentication exchange, it issues a line with a single "*". If the server receives such a response, it MUST reject the AUTH command by sending a 501 reply.
客户端响应由包含[BASE64]编码字符串的行组成。如果客户端希望取消身份验证交换,它将发出一行,其中包含一个“*”。如果服务器收到这样的响应,它必须通过发送501回复来拒绝AUTH命令。
The optional initial response argument to the AUTH command is used to save a round-trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in Section 5.1 of [SASL]. In SMTP, a server challenge that contains no data is defined as a 334 reply with no text part. Note that there is still a space following the reply code, so the complete response line is "334 ".
AUTH命令的可选初始响应参数用于在使用支持初始客户端响应的身份验证机制时保存往返。如果省略了initial response参数,并且所选机制需要初始客户端响应,则服务器必须按照[SASL]第5.1节中的定义进行操作。在SMTP中,不包含数据的服务器质询被定义为没有文本部分的334应答。请注意,回复代码后面还有一个空格,因此完整的响应行是“334”。
Note that the AUTH command is still subject to the line length limitations defined in [SMTP]. If use of the initial response argument would cause the AUTH command to exceed this length, the client MUST NOT use the initial response parameter (and instead proceed as defined in Section 5.1 of [SASL]).
请注意,AUTH命令仍受[SMTP]中定义的行长度限制的约束。如果使用initial response参数会导致AUTH命令超过此长度,则客户端不得使用initial response参数(而是按照[SASL]第5.1节中的定义进行操作)。
If the client is transmitting an initial response of zero length, it MUST instead transmit the response as a single equals sign ("="). This indicates that the response is present, but contains no data.
如果客户端正在传输长度为零的初始响应,则它必须改为以单个等号(“=”)传输响应。这表示响应存在,但不包含任何数据。
If the client uses an initial-response argument to the AUTH command with a SASL mechanism in which the client does not begin the authentication exchange, the server MUST reject the
如果客户端使用带有SASL机制的AUTH命令的初始响应参数,在该机制中客户端不开始身份验证交换,则服务器必须拒绝
AUTH command with a 501 reply. Servers using the enhanced status codes extension [ESMTP-CODES] SHOULD return an enhanced status code of 5.7.0 in this case.
带有501回复的AUTH命令。在这种情况下,使用增强状态代码扩展[ESMTP-codes]的服务器应返回增强状态代码5.7.0。
If the server cannot [BASE64] decode any client response, it MUST reject the AUTH command with a 501 reply (and an enhanced status code of 5.5.2). If the client cannot BASE64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response. In particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the BASE64 alphabet, and MUST reject any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
如果服务器无法[BASE64]解码任何客户端响应,则必须拒绝带有501回复(增强状态代码为5.5.2)的AUTH命令。如果客户端无法BASE64解码服务器的任何挑战,则必须使用“*”响应取消身份验证。特别是,服务器和客户端必须拒绝(而不是忽略)BASE64字母表不明确允许的任何字符,并且必须拒绝任何包含填充字符('=')的BASE64字符序列,而不是字符串末尾(例如,不允许“=AAA”和“AAA=BBB”)。
Note that these [BASE64] strings can be much longer than normal SMTP commands. Clients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported authentication mechanisms. This requirement is independent of any line length limitations the client or server may have in other parts of its protocol implementation. (At the time of writing of this document, 12288 octets is considered to be a sufficient line length limit for handling of deployed authentication mechanisms.) If, during an authentication exchange, the server receives a line that is longer than the server's authentication buffer, the server fails the AUTH command with the 500 reply. Servers using the enhanced status codes extension [ESMTP-CODES] SHOULD return an enhanced status code of 5.5.6 in this case.
请注意,这些[BASE64]字符串可能比普通SMTP命令长得多。客户机和服务器必须能够处理由其支持的身份验证机制生成的挑战和响应的最大编码大小。此要求独立于客户端或服务器在其协议实现的其他部分可能具有的任何线路长度限制。(在编写本文档时,12288个八位字节被认为是处理已部署的身份验证机制的足够行长度限制。)如果在身份验证交换期间,服务器接收到的行长度超过服务器的身份验证缓冲区,则服务器无法执行AUTH命令,并返回500个应答。在这种情况下,使用增强状态代码扩展[ESMTP-codes]的服务器应返回增强状态代码5.5.6。
The authorization identity generated by this [SASL] exchange is a "simple username" (in the sense defined in [SASLprep]), and both client and server SHOULD (*) use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication.
此[SASL]交换生成的授权标识是一个“简单用户名”(在[SASLprep]中定义的含义),客户端和服务器都应(*)使用[StringPrep]算法的[SASLprep]配置文件来准备这些名称以供传输或比较。如果授权标识的准备失败或导致空字符串(除非它作为空字符串传输),则服务器必须使身份验证失败。
(*) Note: Future revision of this specification may change this requirement to MUST. Currently, the SHOULD is used in order to avoid breaking the majority of existing implementations.
(*)注:本规范的未来版本可能会将此要求更改为“必须”。目前,使用SHOULD是为了避免破坏大多数现有实现。
If the server is unable to authenticate the client, it SHOULD reject the AUTH command with a 535 reply unless a more specific error code is appropriate. Should the client successfully complete the exchange, the SMTP server issues a 235 reply. (Note that the SMTP protocol doesn't support the SASL feature of returning additional
如果服务器无法对客户端进行身份验证,则应拒绝带有535回复的AUTH命令,除非出现更具体的错误代码。如果客户端成功完成交换,SMTP服务器将发出235回复。(请注意,SMTP协议不支持返回其他邮件的SASL功能。)
data with a successful outcome.) These status codes, along with others defined by this extension, are discussed in Section 6 of this document.
这些状态代码以及本扩展定义的其他状态代码将在本文件第6节中讨论。
If a security layer is negotiated during the SASL exchange, it takes effect for the client on the octet immediately following the CRLF that concludes the last response generated by the client. For the server, it takes effect immediately following the CRLF of its success reply.
如果在SASL交换期间协商了安全层,则它将在CRLF结束客户端生成的最后一个响应后立即对客户端的八位字节生效。对于服务器,它在成功回复的CRLF之后立即生效。
When a security layer takes effect, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the EHLO argument, which was not obtained from the SASL negotiation itself. Likewise, the client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the SASL negotiation itself. (Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack).
当安全层生效时,SMTP协议将重置为初始状态(服务器发出220服务就绪问候语后SMTP中的状态)。服务器必须放弃从客户机获得的任何知识,例如并非从SASL协商本身获得的EHLO参数。同样,客户机必须放弃从服务器获得的任何知识,例如SMTP服务扩展列表,这些知识不是从SASL协商本身获得的。(请注意,客户端可能会在身份验证之前和之后比较公布的SASL机制,以便检测主动向下协商攻击)。
The client SHOULD send an EHLO command as the first command after a successful SASL negotiation that results in the enabling of a security layer.
成功的SASL协商导致启用安全层后,客户端应发送EHLO命令作为第一个命令。
When an entity (whether it is the client or the server end) is sending data, and both [TLS] and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding, regardless of the order in which the layers were negotiated.
当一个实体(无论是客户端还是服务器端)正在发送数据,并且[TLS]和SASL安全层都有效时,必须在SASL编码之后应用TLS编码,而不管层的协商顺序如何。
The service name specified by this protocol's profile of SASL is "smtp". This service name is also to be used for the [SUBMIT] protocol.
此协议的SASL配置文件指定的服务名称为“smtp”。此服务名称也将用于[SUBMIT]协议。
If an AUTH command fails, the client MAY proceed without authentication. Alternatively, the client MAY try another authentication mechanism or present different credentials by issuing another AUTH
如果AUTH命令失败,则客户端可以在不进行身份验证的情况下继续。或者,客户端可以尝试另一种身份验证机制,或者通过发出另一个身份验证来提供不同的凭据
Note: A server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless either the STARTTLS [SMTP-TLS] command has been negotiated or some other mechanism that protects the session from password snooping has been provided. Server sites SHOULD NOT use any configuration which permits a plaintext password mechanism without such a protection mechanism against password snooping.
注意:服务器实现必须实现不允许任何明文密码机制的配置,除非已协商STARTTLS[SMTP-TLS]命令或已提供保护会话免受密码窥探的其他机制。服务器站点不应使用任何允许明文密码机制的配置,而不应使用防止密码窥探的保护机制。
To ensure interoperability, client and server implementations of this extension MUST implement the [PLAIN] SASL mechanism running over TLS [TLS] [SMTP-TLS]. See also Section 15 for additional requirements on implementations of [PLAIN] over [TLS].
为确保互操作性,此扩展的客户端和服务器实现必须实现在TLS[TLS][SMTP-TLS]上运行的[PLAIN]SASL机制。关于在[TLS]上实现[PLAIN]的其他要求,请参见第15节。
Note that many existing client and server implementations implement CRAM-MD5 [CRAM-MD5] SASL mechanism. In order to ensure interoperability with deployed software, new implementations MAY implement it; however, implementations should be aware that this SASL mechanism doesn't provide any server authentication. Note that at the time of writing of this document the SASL Working Group is working on several replacement SASL mechanisms that provide server authentication and other features.
注意,许多现有的客户机和服务器实现实现了CRAM-MD5[CRAM-MD5]SASL机制。为了确保与已部署软件的互操作性,新的实现可能会实现它;但是,实现应该知道,此SASL机制不提供任何服务器身份验证。请注意,在编写本文档时,SASL工作组正在研究几种替代SASL机制,这些机制提供服务器身份验证和其他功能。
When the AUTH command is used together with the [PIPELINING] extension, it MUST be the last command in a pipelined group of commands. The only exception to this rule is when the AUTH command contains an initial response for a SASL mechanism that allows the client to send data first, the SASL mechanism is known to complete in one round-trip, and a security layer is not negotiated by the client. Two examples of such SASL mechanisms are PLAIN [PLAIN] and EXTERNAL [SASL].
当AUTH命令与[Pipeline]扩展一起使用时,它必须是流水线命令组中的最后一个命令。此规则的唯一例外是,AUTH命令包含SASL机制的初始响应,该机制允许客户端首先发送数据,已知SASL机制在一次往返中完成,并且客户端不协商安全层。此类SASL机制的两个示例是普通[PLAIN]和外部[SASL]。
Here is an example of a client attempting AUTH using the [PLAIN] SASL mechanism under a TLS layer, and making use of the initial client response:
下面是一个示例,客户机尝试在TLS层下使用[PLAIN]SASL机制进行身份验证,并使用初始客户机响应:
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful
Here is another client that is attempting AUTH PLAIN under a TLS layer, this time without the initial response. Parts of the negotiation before the TLS layer was established have been omitted:
下面是另一个客户端,它正在尝试在TLS层下进行普通身份验证,这次没有初始响应。TLS层建立之前的部分协商已被省略:
... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN (note: there is a single space following the 334 on the following line) S: 334 C: dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful
... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN (note: there is a single space following the 334 on the following line) S: 334 C: dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 Authentication successful
Here is an example using CRAM-MD5 [CRAM-MD5], a mechanism in which the client does not begin the authentication exchange, and includes a server challenge:
下面是一个使用CRAM-MD5[CRAM-MD5]的示例,在该机制中,客户端不开始身份验证交换,并包括服务器质询:
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH DIGEST-MD5 CRAM-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: AUTH CRAM-MD5 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk dT4= C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== S: 235 2.7.0 Authentication successful
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH DIGEST-MD5 CRAM-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: AUTH CRAM-MD5 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk dT4= C: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== S: 235 2.7.0 Authentication successful
Here is an example of a client attempting AUTH EXTERNAL under TLS, using the derived authorization ID (and thus a zero-length initial client response).
下面是一个客户机尝试在TLS下使用派生的授权ID(以及零长度的初始客户机响应)进行外部身份验证的示例。
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN C: AUTH EXTERNAL = S: 235 2.7.0 Authentication successful
S: 220-smtp.example.com ESMTP Server C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPI DIGEST-MD5 S: 250-ENHANCEDSTATUSCODES S: 250 STARTTLS C: STARTTLS S: 220 Ready to start TLS ... TLS negotiation proceeds, further commands protected by TLS layer ... C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH EXTERNAL GSSAPI DIGEST-MD5 PLAIN C: AUTH EXTERNAL = S: 235 2.7.0 Authentication successful
AUTH=mailbox
AUTH=邮箱
Arguments: A <mailbox> (see Section 4.1.2 of [SMTP]) that is associated with the identity that submitted the message to the delivery system, or the two character sequence "<>" indicating such an identity is unknown or insufficiently authenticated. To comply with restrictions imposed on ESMTP parameters, the <mailbox> is encoded inside an xtext. The syntax of an xtext is described in Section 4 of [ESMTP-DSN].
参数:一个<邮箱>(见[SMTP]第4.1.2节),它与将邮件提交给传递系统的标识关联,或者两个字符序列“<>”表示该标识未知或未经充分验证。为了遵守对ESMTP参数施加的限制,将<mailbox>编码在xtext中。xtext的语法在[ESMTP-DSN]的第4节中描述。
Note: For the purposes of this discussion, "authenticated identity" refers to the identity (if any) derived from the authorization identity of previous AUTH command, while the terms "authorized identity" and "supplied <mailbox>" refer to the sender identity that is being associated with a particular message. Note that one authenticated identity may be able to identify messages as being sent by any number of authorized identities within a single session. For example, this may be the case when an SMTP server (one authenticated identity) is processing its queue (many messages with distinct authorized identities).
注意:在本讨论中,“已验证身份”指的是从先前AUTH命令的授权身份派生的身份(如果有),而术语“已授权身份”和“提供的<邮箱>”指的是与特定邮件关联的发件人身份。请注意,一个经过身份验证的标识可以将消息标识为在单个会话中由任意数量的授权标识发送。例如,SMTP服务器(一个经过身份验证的标识)正在处理其队列(许多具有不同授权标识的邮件)时可能会出现这种情况。
Discussion: The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a trusted environment to communicate the authorization identity associated with individual messages.
讨论:MAIL FROM命令的可选AUTH参数允许可信环境中的协作代理传递与单个消息关联的授权标识。
If the server trusts the authenticated identity of the client to assert that the message was originally submitted by the supplied <mailbox>, then the server SHOULD supply the same <mailbox> in an AUTH parameter when relaying the message to any other server which supports the AUTH extension.
如果服务器信任客户端的经过身份验证的标识来断言消息最初是由提供的<mailbox>提交的,则服务器在将消息中继到支持身份验证扩展的任何其他服务器时,应在身份验证参数中提供相同的<mailbox>。
For this reason, servers that advertise support for this extension MUST support the AUTH parameter to the MAIL FROM command even when the client has not authenticated itself to the server.
因此,即使客户机尚未向服务器进行身份验证,公布对此扩展的支持的服务器也必须支持MAIL FROM命令的AUTH参数。
A MAIL FROM parameter of AUTH=<> indicates that the original submitter of the message is not known. The server MUST NOT treat the message as having been originally submitted by the authenticated identity that resulted from the AUTH command.
参数AUTH=<>的MAIL-FROM表示消息的原始提交者未知。服务器不得将消息视为最初由AUTH命令生成的经过身份验证的标识提交。
If the AUTH parameter to the MAIL FROM command is not supplied, the client has authenticated, and the server believes the message is an original submission, the server MAY generate a <mailbox> from the user's authenticated identity for use in an AUTH parameter when relaying the message to any server which supports the AUTH extension. The generated <mailbox> is implementation specific, but it MUST conform to the syntax of [SMTP]. If the implementation cannot generate a valid <mailbox>, it MUST transmit AUTH=<> when relaying this message.
如果未向MAIL FROM命令提供AUTH参数,客户机已通过身份验证,并且服务器认为邮件是原始提交,则服务器可以根据用户的身份验证生成一个<mailbox>,以便在将邮件中继到支持AUTH扩展的任何服务器时在AUTH参数中使用。生成的<mailbox>是特定于实现的,但它必须符合[SMTP]的语法。如果实现无法生成有效的<mailbox>,则在中继此消息时必须传输AUTH=<>。
If the server does not sufficiently trust the authenticated identity of the client, or if the client is not authenticated, then the server MUST behave as if the AUTH=<> parameter was supplied. The server MAY, however, write the value of any supplied AUTH parameter to a log file.
如果服务器不充分信任客户机的身份验证,或者客户机未经过身份验证,则服务器的行为必须与提供了AUTH=<>参数一样。但是,服务器可以将任何提供的AUTH参数的值写入日志文件。
If an AUTH=<> parameter was supplied, either explicitly or due to the requirement in the previous paragraph, then the server MUST supply the AUTH=<> parameter when relaying the message to any server which it has authenticated to using the AUTH extension.
如果提供了AUTH=<>参数,无论是显式提供的还是由于上一段中的要求提供的,则服务器在将消息中继到其已使用AUTH扩展进行身份验证的任何服务器时,必须提供AUTH=<>参数。
A server MAY treat expansion of a mailing list as a new submission, setting the AUTH parameter to the mailing list address or mailing list administration address when relaying the message to list subscribers.
服务器可以将邮件列表的扩展视为新提交,在将邮件转发给列表订户时,将AUTH参数设置为邮件列表地址或邮件列表管理地址。
Note that an implementation which is hard-coded to treat all clients as being insufficiently trusted is compliant with this specification. In that case, the implementation does nothing more than parse and discard syntactically valid AUTH parameters to the MAIL FROM command, and supply AUTH=<> parameters to any servers that it authenticates to.
请注意,硬编码以将所有客户端视为不充分可信的实现符合此规范。在这种情况下,实现只需解析并丢弃语法上有效的AUTH参数到mailfrom命令,并向其验证的任何服务器提供AUTH=<>参数。
An example where the original identity of the sender is trusted and known:
发送方的原始身份受信任且已知的示例:
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com S: 250 OK
C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com S: 250 OK
One example where the identity of the sender is not trusted or is otherwise being suppressed by the client:
发送方的身份不受信任或被客户端禁止的一个示例:
C: MAIL FROM:<john+@example.org> AUTH=<> S: 250 OK
C: MAIL FROM:<john+@example.org> AUTH=<> S: 250 OK
The following error codes may be used to indicate various success or failure conditions. Servers that return enhanced status codes [ESMTP-CODES] SHOULD use the enhanced codes suggested here.
以下错误代码可用于指示各种成功或失败情况。返回增强状态代码[ESMTP-codes]的服务器应使用此处建议的增强代码。
235 2.7.0 Authentication Succeeded
235 2.7.0身份验证成功
This response to the AUTH command indicates that the authentication was successful.
对AUTH命令的此响应表示身份验证成功。
432 4.7.12 A password transition is needed
432 4.7.12需要进行密码转换
This response to the AUTH command indicates that the user needs to transition to the selected authentication mechanism. This is typically done by authenticating once using the [PLAIN] authentication mechanism. The selected mechanism SHOULD then work for authentications in subsequent sessions.
对AUTH命令的响应表明用户需要转换到所选的身份验证机制。这通常通过使用[PLAIN]身份验证机制进行一次身份验证来完成。然后,所选机制应可用于后续会话中的身份验证。
454 4.7.0 Temporary authentication failure
454.7.0临时身份验证失败
This response to the AUTH command indicates that the authentication failed due to a temporary server failure. The client SHOULD NOT prompt the user for another password in this case, and should instead notify the user of server failure.
对AUTH命令的此响应表示由于临时服务器故障,身份验证失败。在这种情况下,客户端不应提示用户输入另一个密码,而应将服务器故障通知用户。
534 5.7.9 Authentication mechanism is too weak
534 5.7.9身份验证机制太弱
This response to the AUTH command indicates that the selected authentication mechanism is weaker than server policy permits for that user. The client SHOULD retry with a new authentication mechanism.
对AUTH命令的此响应表示所选身份验证机制弱于该用户的服务器策略允许。客户端应使用新的身份验证机制重试。
535 5.7.8 Authentication credentials invalid
535.7.8身份验证凭据无效
This response to the AUTH command indicates that the authentication failed due to invalid or insufficient authentication credentials. In this case, the client SHOULD ask the user to supply new credentials (such as by presenting a password dialog box).
对AUTH命令的此响应表示由于身份验证凭据无效或不足,身份验证失败。在这种情况下,客户机应该要求用户提供新凭据(例如通过显示密码对话框)。
500 5.5.6 Authentication Exchange line is too long
500 5.5.6身份验证交换线路太长
This response to the AUTH command indicates that the authentication failed due to the client sending a [BASE64] response that is longer than the maximum buffer size available for the currently selected SASL mechanism.
此对AUTH命令的响应表明身份验证失败,因为客户端发送的[BASE64]响应长于当前所选SASL机制可用的最大缓冲区大小。
530 5.7.0 Authentication required
530 5.7.0需要身份验证
This response SHOULD be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT when server policy requires authentication in order to perform the requested action and authentication is not currently in force.
当服务器策略需要身份验证以执行请求的操作且身份验证当前未生效时,此响应应该由AUTH、EHLO、HELO、NOOP、RSET或QUIT以外的任何命令返回。
538 5.7.11 Encryption required for requested authentication mechanism
538 5.7.11请求的身份验证机制需要加密
This response to the AUTH command indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted. Note that this response code is documented here for historical purposes only. Modern implementations SHOULD NOT advertise mechanisms that are not permitted due to lack of encryption, unless an encryption layer of sufficient strength is currently being employed.
对AUTH命令的此响应表明,只有在加密基础SMTP连接时,才能使用选定的身份验证机制。请注意,此处记录的此响应代码仅用于历史目的。现代实现不应该宣传由于缺乏加密而不被允许的机制,除非目前正在使用具有足够强度的加密层。
This document adds several new enhanced status codes to the list defined in [ENHANCED]:
本文档向[enhanced]中定义的列表中添加了几个新的增强状态代码:
The following 3 Enhanced Status Codes were defined above:
上面定义了以下3个增强状态代码:
5.7.8 Authentication credentials invalid 5.7.9 Authentication mechanism is too weak 5.7.11 Encryption required for requested authentication mechanism
5.7.8 身份验证凭据无效5.7.9身份验证机制太弱请求的身份验证机制需要5.7.11加密
X.5.6 Authentication Exchange line is too long
X.5.6 身份验证交换线路太长
This enhanced status code SHOULD be returned when the server fails the AUTH command due to the client sending a [BASE64] response which is longer than the maximum buffer size available for the currently selected SASL mechanism. This is useful for both permanent and persistent transient errors.
当服务器由于客户端发送的[BASE64]响应长于当前所选SASL机制可用的最大缓冲区大小而使AUTH命令失败时,应返回此增强状态代码。这对于永久性和持久性瞬态错误都很有用。
As described in Section 4.4 of [SMTP], an SMTP server that receives a message for delivery or further processing MUST insert the "Received:" header field at the beginning of the message content. This document places additional requirements on the content of a generated "Received:" header field. Upon successful authentication, a server SHOULD use the "ESMTPA" or the "ESMTPSA" [SMTP-TT] (when appropriate) keyword in the "with" clause of the Received header field.
如[SMTP]第4.4节所述,接收要传递或进一步处理的邮件的SMTP服务器必须在邮件内容的开头插入“Received:”标头字段。本文档对生成的“已接收:”标题字段的内容提出了附加要求。成功身份验证后,服务器应在接收头字段的“with”子句中使用“ESMTPA”或“ESMTPSA”[SMTP-TT](适当时)关键字。
The following syntax specification uses the Augmented Backus-Naur Form notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [ABNF] or [SASL]. The non-terminal <mailbox> is defined in [SMTP].
以下语法规范使用[ABNF]中指定的扩展的Backus-Naur形式表示法。以下引用但未定义的非端子由[ABNF]或[SASL]定义。非终端<邮箱>在[SMTP]中定义。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明,否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
hexchar = "+" HEXDIG HEXDIG
hexchar=“+”HEXDIG HEXDIG
xchar = %x21-2A / %x2C-3C / %x3E-7E ;; US-ASCII except for "+", "=", SP, and CTL
xchar = %x21-2A / %x2C-3C / %x3E-7E ;; US-ASCII except for "+", "=", SP, and CTL
xtext = *(xchar / hexchar) ;; non-US-ASCII is only allowed as hexchar
xtext = *(xchar / hexchar) ;; non-US-ASCII is only allowed as hexchar
auth-command = "AUTH" SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF ;; <sasl-mech> is defined in [SASL]
auth-command = "AUTH" SP sasl-mech [SP initial-response] *(CRLF [base64]) [CRLF cancel-response] CRLF ;; <sasl-mech> is defined in [SASL]
auth-param = "AUTH=" xtext ;; Parameter to the MAIL FROM command. ;; This non-terminal complies with ;; syntax defined by esmtp-param [SMTP]. ;; ;; The decoded form of the xtext MUST be ;; either a <mailbox> or the two ;; characters "<>"
auth-param = "AUTH=" xtext ;; Parameter to the MAIL FROM command. ;; This non-terminal complies with ;; syntax defined by esmtp-param [SMTP]. ;; ;; The decoded form of the xtext MUST be ;; either a <mailbox> or the two ;; characters "<>"
base64 = base64-terminal / ( 1*(4base64-char) [base64-terminal] )
base64=base64终端/(1*(4base64字符)[base64终端])
base64-char = ALPHA / DIGIT / "+" / "/" ;; Case-sensitive
base64-char = ALPHA / DIGIT / "+" / "/" ;; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
base64-terminal = (2base64-char "==") / (3base64-char "=")
continue-req = "334" SP [base64] CRLF ;; Intermediate response to the AUTH ;; command. ;; This non-terminal complies with ;; syntax defined by Reply-line [SMTP].
continue-req = "334" SP [base64] CRLF ;; Intermediate response to the AUTH ;; command. ;; This non-terminal complies with ;; syntax defined by Reply-line [SMTP].
initial-response= base64 / "="
initial-response= base64 / "="
cancel-response = "*"
取消响应=“*”
Security issues are discussed throughout this memo.
本备忘录中讨论了安全问题。
If a client uses this extension to get an encrypted tunnel through an insecure network to a cooperating server, it needs to be configured to never send mail to that server when the connection is not mutually authenticated and encrypted. Otherwise, an attacker could steal the client's mail by hijacking the [SMTP] connection and either pretending the server does not support the Authentication extension or causing all AUTH commands to fail.
如果客户机使用此扩展获取通过不安全网络到协作服务器的加密隧道,则需要将其配置为在连接未经过相互身份验证和加密时从不向该服务器发送邮件。否则,攻击者可以通过劫持[SMTP]连接并假装服务器不支持身份验证扩展或导致所有身份验证命令失败来窃取客户端的邮件。
Before the [SASL] negotiation has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer.
在[SASL]协商开始之前,任何协议交互都会在clear中执行,并且可能会被活动攻击者修改。因此,客户机和服务器必须放弃在建立安全层后开始SASL协商之前获得的任何知识。
This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt (i.e., a connection between two Mail Transfer Agents (MTAs)) to the submission port [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing a relayed message and, in the absence of other envelope authentication, from picking up the authentication of the relay client.
此机制不保护TCP端口,因此主动攻击者可能会将中继连接尝试(即两个邮件传输代理(MTA)之间的连接)重定向到提交端口[SUBMIT]。AUTH=<>参数可防止此类攻击导致中继消息,并在没有其他信封身份验证的情况下,防止获取中继客户端的身份验证。
A message submission client may require the user to authenticate whenever a suitable [SASL] mechanism is advertised. Therefore, it may not be desirable for a submission server [SUBMIT] to advertise a SASL mechanism when use of that mechanism grants the clients no benefits over anonymous submission.
消息提交客户端可能要求用户在发布合适的[SASL]机制时进行身份验证。因此,提交服务器[SUBMIT]可能不希望公布SASL机制,因为使用该机制不会给客户端带来匿名提交带来任何好处。
Servers MAY implement a policy whereby the connection is dropped after a number of failed authentication attempts. If they do so, they SHOULD NOT drop the connection until at least 3 attempts to authenticate have failed.
服务器可以实现一种策略,即在多次身份验证尝试失败后断开连接。如果他们这样做,在至少3次身份验证尝试失败之前,他们不应断开连接。
If an implementation supports SASL mechanisms that are vulnerable to passive eavesdropping attacks (such as [PLAIN]), then the implementation MUST support at least one configuration where these SASL mechanisms are not advertised or used without the presence of an external security layer such as [TLS].
如果一个实现支持易受被动窃听攻击的SASL机制(如[PLAIN]),那么该实现必须支持至少一种配置,其中这些SASL机制在没有外部安全层(如[TLS])的情况下不会公布或使用。
This extension is not intended to replace or be used instead of end-to-end message signature and encryption systems such as [S/MIME] or [PGP]. This extension addresses a different problem than end-to-end systems; it has the following key differences:
此扩展不打算取代或替代端到端消息签名和加密系统,如[S/MIME]或[PGP]。此扩展解决了与端到端系统不同的问题;它有以下主要区别:
1. It is generally useful only within a trusted enclave.
1. 它通常只在受信任的飞地内有用。
2. It protects the entire envelope of a message, not just the message's body.
2. 它保护消息的整个信封,而不仅仅是消息的正文。
3. It authenticates the message submission, not authorship of the message content.
3. 它验证消息提交,而不是消息内容的作者身份。
4. When mutual authentication is used along with a security layer, it can give the sender some assurance that the message was successfully delivered to the next hop.
4. 当相互身份验证与安全层一起使用时,它可以向发送方提供消息已成功传递到下一跳的一些保证。
Additional security considerations are mentioned in the [SASL] specification. Additional security considerations specific to a particular SASL mechanism are described in the relevant specification. Additional security considerations for [PLAIN] over [TLS] are mentioned in Section 15 of this document.
[SASL]规范中提到了其他安全注意事项。相关规范中描述了特定SASL机制的其他安全注意事项。本文件第15节提到了[TLS]上[PLAIN]的其他安全注意事项。
IANA updated the entry for the "smtp" SASL protocol name to point at this document.
IANA将“smtp”SASL协议名称的条目更新为指向此文档。
IANA updated the registration of the Authentication SMTP service extension as defined in Section 3 of this document. This registry is currently located at <http://www.iana.org/assignments/mail-parameters>.
IANA更新了本文档第3节中定义的认证SMTP服务扩展的注册。此注册表当前位于<http://www.iana.org/assignments/mail-parameters>.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker,D.和P.Overell,“语法规范的扩充BNF:ABNF”,RFC 4234,2005年10月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64]Josefsson,S.,“Base16、Base32和BASE64数据编码”,RFC4648,2006年10月。
[ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[ESMTP-CODES]Freed,N.,“用于返回增强错误代码的SMTP服务扩展”,RFC 2034,1996年10月。
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[ENHANCED]Vaudreuil,G.,“增强邮件系统状态代码”,RFC 3463,2003年1月。
[ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[ESMTP-DSN]Moore,K.,“简单邮件传输协议(SMTP)服务扩展交付状态通知(DSN)”,RFC 34612003年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov,A.和K.Zeilenga,“简单身份验证和安全层(SASL)”,RFC 4422,2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga,K.,“SASLprep:Stringprep用户名和密码配置文件”,RFC 4013,2005年2月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP]Klensin,J.,“简单邮件传输协议”,RFC 28212001年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]Hoffman,P.,“传输层安全SMTP的SMTP服务扩展”,RFC 3207,2002年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[StringPrep]Hoffman,P.和M.Blanchet,“国际化弦的准备(“StringPrep”)”,RFC 3454,2002年12月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交]Gellens,R.和J.Klensin,“邮件信息提交”,RFC 4409,2006年4月。
[SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2004.
[SMTP-TT]Newman,C.,“ESMTP和LMTP传输类型注册”,RFC 3848,2004年7月。
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[普通]Zeilenga,K.,Ed.“普通简单认证和安全层(SASL)机制”,RFC4616,2006年8月。
[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[X509]Housley,R.,Polk,W.,Ford,W.,和D.Solo,“Internet X.509公钥基础设施证书和证书撤销列表(CRL)配置文件”,RFC 32802002年4月。
[PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[PGP]Elkins,M.,“具有良好隐私的MIME安全性(PGP)”,RFC 2015,1996年10月。
[S/MIME] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[S/MIME]Ramsdell,B.,编辑,“安全/多用途Internet邮件扩展(S/MIME)版本3.1消息规范”,RFC 38512004年7月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.1”,RFC 4346,2006年4月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[PIPELINING]Freed,N.,“用于命令管道的SMTP服务扩展”,STD 60,RFC 2920,2000年9月。
[CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[CRAM-MD5]Klensin,J.,Catoe,R.,和P.Krumviede,“简单质询/响应的IMAP/POP授权扩展”,RFC 21951997年9月。
The editors would like to acknowledge the contributions of John Myers and other contributors to RFC 2554, on which this document draws from heavily.
编辑们要感谢约翰·迈尔斯和其他贡献者对RFC2554的贡献,本文件从这些贡献中汲取了大量经验。
The editors would also like to thank Ken Murchison, Mark Crispin, Chris Newman, David Wilson, Dave Cridland, Frank Ellermann, Ned Freed, John Klensin, Tony Finch, Abhijit Menon-Sen, Philip Guenther, Sam Hartman, Russ Housley, Cullen Jennings, and Lisa Dusseault for the time they devoted to reviewing of this document and/or for the comments received.
编辑们还要感谢肯·默奇森、马克·克里斯平、克里斯·纽曼、大卫·威尔逊、戴夫·克里德兰、弗兰克·埃勒曼、内德·弗里德、约翰·克莱辛、托尼·芬奇、阿比吉特·梅农·森、菲利普·根瑟、萨姆·哈特曼、罗斯·霍斯利、卡伦·詹宁斯、,和Lisa Dusseault,感谢他们花时间审查本文件和/或收到的评论。
This section is normative for SMTP implementations that support SASL [PLAIN] over [TLS].
本节是支持[TLS]上的SASL[PLAIN]的SMTP实现的规范。
If an SMTP client is willing to use SASL PLAIN over TLS to authenticate to the SMTP server, the client verifies the server certificate according to the rules of [X509]. If the server has not provided any certificate, or if the certificate verification fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism.
如果SMTP客户端愿意使用SASL PLAIN over TLS对SMTP服务器进行身份验证,则客户端将根据[X509]的规则验证服务器证书。如果服务器未提供任何证书,或者证书验证失败,则客户端不得尝试使用SASL普通机制进行身份验证。
After a successful [TLS] negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. If the match fails, the client MUST NOT attempt to authenticate using the SASL PLAIN mechanism. Matching is performed according to the following rules:
[TLS]协商成功后,客户端必须对照服务器证书消息中显示的服务器身份检查其对服务器主机名的理解,以防止中间人攻击。如果匹配失败,客户端不得尝试使用SASL普通机制进行身份验证。根据以下规则执行匹配:
The client MUST use the server hostname it used to open the connection as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use
客户端必须使用用于打开连接的服务器主机名作为值,以与服务器证书中表示的服务器名称进行比较。客户端不得使用
any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done.
从不安全的远程源(例如,不安全的DNS查找)派生的任何形式的服务器主机名。CNAME规范化未完成。
If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity.
如果证书中存在dNSName类型的subjectAltName扩展名,则应将其用作服务器标识的源。
Matching is case-insensitive.
匹配不区分大小写。
A "*" wildcard character MAY be used as the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com.
“*”通配符可以用作证书中最左边的名称组件。例如,*.example.com将与a.example.com、foo.example.com等匹配,但与example.com不匹配。
If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable.
如果证书包含多个名称(例如,多个dNSName字段),则认为与任何一个字段的匹配都是可接受的。
1. Clarified that servers MUST support the use of the AUTH=mailbox parameter to MAIL FROM, even when the client is not authenticated.
1. 阐明服务器必须支持使用AUTH=mailbox参数发送邮件,即使客户端未经过身份验证。
2. Clarified the initial-client-send requirements, and give additional examples.
2. 阐明了最初的客户发送要求,并给出了其他示例。
3. Updated references to newer versions of various specifications.
3. 更新了对各种规范的更新版本的引用。
4. Required SASL PLAIN (over TLS) as mandatory-to-implement.
4. 强制实施所需的SASL平原(超过TLS)。
5. Clarified that the mechanism list can change.
5. 阐明了机制列表可以更改。
6. Deprecated the use of the 538 response code.
6. 不推荐使用538响应代码。
7. Added the use of the SASLprep profile for preparing authorization identities.
7. 添加了SASLprep配置文件用于准备授权标识。
8. Substantial cleanup of response codes and indicated suggested enhanced response codes. Also indicated what response codes should result in a client prompting the user for new credentials.
8. 大量清除响应代码,并指出建议的增强响应代码。还指出了客户端提示用户输入新凭据时应使用的响应代码。
9. Updated ABNF section to use RFC 4234.
9. 更新ABNF部分以使用RFC 4234。
10. Clarified interaction with SMTP PIPELINING extension.
10. 阐明了与SMTP管道扩展的交互。
11. Added a reference to RFC 3848.
11. 添加了对RFC 3848的参考。
12. Added a new Enhanced Status Code for "authentication line too long" case.
12. 为“身份验证线路过长”案例添加了新的增强状态代码。
13. Other general editorial clarifications.
13. 其他一般性编辑澄清。
Editors' Addresses
编辑地址
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043, USA
Robert Siemborski Google,Inc.美国加利福尼亚州安比瑟尔公园山景大道1600号,邮编94043
Phone: +1 650 623 6925 EMail: robsiemb@google.com
Phone: +1 650 623 6925 EMail: robsiemb@google.com
Alexey Melnikov Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK
Alexey Melnikov Isode Limited 5城堡商业村,英国米德尔塞克斯汉普顿车站路36号,TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有(C)IETF信托基金(2007年)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。