[要約] RFC 4954は、SMTPサービス拡張のための認証に関する規格であり、SMTPセッションの認証を提供することを目的としています。要約すると、このRFCはSMTPのセキュリティを向上させるための認証メカニズムを定義しています。
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）The IETF Trust（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
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クライアントが認証メカニズムを示す可能性がある単純なメールトランスポートプロトコル（SMTP）拡張機能を定義しています。オプションで、メッセージをメール配信システムに送信したIDに関連付けられたメールボックスを指定します。
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 Pipelining [Pipelining] Extensionとの相互作用を明確にします。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
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」を使用したオプションのパラメーターがコマンドからメールに追加され、コマンドからのメールの最大行長を500文字で拡張します。
6. This extension is appropriate for the submission protocol [SUBMIT].
6. この拡張機能は、送信プロトコル[送信]に適しています。
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コマンドが完了した後、サーバーは503の返信でさらに承認コマンドを拒否する必要があります。
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.
郵便取引中に認証コマンドは許可されていません。郵便取引中に発行された認証コマンドは、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 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.
ディスカッション：authコマンドは、クライアントとサーバーの間の[SASL]認証交換を開始します。クライアントは、認証コマンドの最初のパラメーターで使用するSASLメカニズムを識別します。サーバーが要求された認証メカニズムをサポートする場合、SASL Exchangeを実行してユーザーを認証します。オプションでは、このセッション中にその後のプロトコル相互作用のセキュリティレイヤーも交渉します。要求された認証メカニズムが無効である場合（たとえば、サポートされていないか、暗号化レイヤーが必要です）、サーバーは504応答で認証コマンドを拒否します。サーバーが[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.
サーバーチャレンジは、SASLメカニズムによって提供された[base64]エンコードされた文字列を含むテキストパーツを含む334の応答として送信されます。この課題は、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コマンドに対するオプションの初期応答引数は、初期クライアント応答をサポートする認証メカニズムを使用する場合、ラウンドトリップを保存するために使用されます。初期応答の引数が省略され、選択されたメカニズムが最初のクライアント応答を必要とする場合、サーバーは[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]).
認証コマンドは、[SMTP]で定義されているライン長の制限の対象となることに注意してください。初期応答引数の使用により、認証コマンドがこの長さを超える場合、クライアントは初期応答パラメーターを使用してはなりません（代わりに[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 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.
クライアントが認証交換を開始しないSASLメカニズムを使用して、クライアントがauthコマンドに初期応答引数を使用している場合、サーバーは501の応答でauthコマンドを拒否する必要があります。拡張されたステータスコード拡張機能[ESMTPコード]を使用したサーバーは、この場合、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の強化されたステータスコード）で認証コマンドを拒否する必要があります。クライアントがサーバーの課題のいずれかをデコードできない場合、「*」応答を使用して認証をキャンセルする必要があります。特に、サーバーとクライアントは、base64アルファベットで明示的に許可されていない文字を拒否する（無視しない）必要があり、文字列の端以外の場所でパッド文字（ '='）を含むベース64文字のシーケンスを拒否する必要があります。たとえば、「= 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オクテットは、展開された認証メカニズムの処理に十分なライン長い制限と見なされます。）認証交換中に、サーバーがサーバーの認証バッファーよりも長いラインを受信した場合、サーバーは、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] Exchangeによって生成された認証IDは「単純なユーザー名」（[SASLPrep]で定義されている意味）であり、クライアントとサーバーの両方が[StringPrep]アルゴリズムの[SASLPrep]プロファイルを使用する必要があります。伝送または比較のためのこれらの名前。承認IDの準備が失敗するか、空の文字列に陥った場合（空の文字列として送信されない限り）、サーバーは認証に失敗する必要があります。
(*) 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.
（*）注：この仕様の将来の改訂は、この要件を必須に変更する可能性があります。現在、既存の実装の大部分を壊すことを避けるために使用されています。
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 data with a successful outcome.) These status codes, along with others defined by this extension, are discussed in Section 6 of this document.
サーバーがクライアントを認証できない場合、より具体的なエラーコードが適切でない限り、535の返信でauthコマンドを拒否する必要があります。クライアントがExchangeを正常に完了した場合、SMTPサーバーは235の返信を発行します。（SMTPプロトコルは、成功した結果で追加データを返すSASL機能をサポートしていないことに注意してください。）これらのステータスコードは、この拡張機能で定義されている他のステータスコードについて、このドキュメントのセクション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引数など、クライアントから取得した知識を廃棄する必要があります。同様に、クライアントは、SASL交渉自体から得られなかったSMTPサービス拡張機能のリストなど、サーバーから取得した知識を廃棄する必要があります。（クライアントは、アクティブな減少攻撃を検出するために、認証の前後に広告された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」です。このサービス名は、[送信]プロトコルにも使用されます。
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
認証コマンドが失敗した場合、クライアントは認証なしで続行できます。あるいは、クライアントは別の認証メカニズムを試したり、別の認証を発行して異なる資格情報を提示したりする場合があります
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]を介して実行される[プレーン] 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].
[Pipelining]拡張機能とともにauthコマンドが使用される場合、パイプラインのコマンドグループの最後のコマンドでなければなりません。このルールの唯一の例外は、認証コマンドがクライアントが最初にデータを送信できるようにするSASLメカニズムの初期応答を含む場合です。SASLメカニズムは1つの往復で完了することが知られており、セキュリティ層はによって交渉されません。クライアント。このようなSASLメカニズムの2つの例は、プレーン[プレーン]と外部[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メカニズムを使用してAUTHを試み、最初のクライアント応答を使用しているクライアントの例です。
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レイヤーの下でAuth Plainを試みている別のクライアントです。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
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
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).
以下は、派生承認IDを使用して、TLSの下で外部外部を試みるクライアントの例です（したがって、ゼロの長さの初期クライアント応答）。
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].
引数：<mailbox>（[SMTP]のセクション4.1.2を参照）は、配信システムにメッセージを送信したIDに関連付けられている、またはそのようなアイデンティティが不明または不十分に認証されていることを示す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コマンドの承認アイデンティティから派生した身元（もしあれば）を指し、「承認されたアイデンティティ」と「供給<メールボックス>」という用語は、送信者のアイデンティティを参照しますそれは特定のメッセージに関連付けられています。1つの認証されたアイデンティティは、単一のセッション内で任意の数の承認されたアイデンティティによって送信されるものとしてメッセージを識別できる場合があることに注意してください。たとえば、これは、SMTPサーバー（1つの認証されたアイデンティティ）がキュー（明確な承認されたアイデンティティを持つ多くのメッセージ）を処理している場合に当てはまります。
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.
ディスカッション：コマンドからのメールへのオプションの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>によって送信されたと主張する場合、サーバーは、サポートする他のサーバーにメッセージをリレーするときに、AUTHパラメーターに同じ<メールボックス>を供給する必要があります。認証拡張。
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.
このため、この拡張機能のサポートを宣伝するサーバーは、クライアントがサーバーに認証されていない場合でも、コマンドからのメールパラメーターをコマンドからサポートする必要があります。
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 = <>のパラメーターからのメールは、メッセージの元の送信者が不明であることを示します。サーバーは、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.
コマンドからのauthパラメーターが供給されていない場合、クライアントが認証されている場合、サーバーはメッセージが元の提出物であると考えています。Auth Extensionをサポートするサーバーへのメッセージ。生成された<mailbox>は実装固有ですが、[SMTP]の構文に適合する必要があります。実装が有効な<メールボックス>を生成できない場合、このメッセージを中継するときは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.
サーバーがクライアントの認証されたIDを十分に信頼していない場合、またはクライアントが認証されていない場合、サーバーは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パラメーターを解析および破棄し、認証するサーバーに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
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
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.
認証コマンドに対するこの応答は、認証が成功したことを示しています。
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コマンドに対するこの応答は、ユーザーが選択した認証メカニズムに移行する必要があることを示しています。これは通常、[プレーン]認証メカニズムを使用して認証することによって行われます。選択したメカニズムは、後続のセッションで認証のために機能する必要があります。
454 4.7.0 Temporary authentication failure
454 4.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.
認証コマンドに対するこの応答は、一時的なサーバーの障害により認証が失敗したことを示しています。クライアントは、この場合に別のパスワードをユーザーに促すべきではなく、代わりにユーザーにサーバーの失敗を通知する必要があります。
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.
認証コマンドに対するこの応答は、選択した認証メカニズムがそのユーザーのサーバーポリシー許可よりも弱いことを示しています。クライアントは、新しい認証メカニズムで再試行する必要があります。
535 5.7.8 Authentication credentials invalid
535 5.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).
認証コマンドに対するこの応答は、認証資格情報が無効または不十分であるために認証が失敗したことを示しています。この場合、クライアントはユーザーに新しい資格情報を提供するように依頼する必要があります（パスワードダイアログボックスを表示するなど）。
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.
認証コマンドに対するこの応答は、現在選択されているSASLメカニズムで利用可能な最大バッファサイズよりも長いクライアントが[Base64]応答を送信するために認証が失敗したことを示しています。
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.
認証コマンドに対するこの応答は、選択された認証メカニズムが基礎となるSMTP接続が暗号化されている場合にのみ使用できることを示しています。この応答コードは、歴史的な目的のみで文書化されていることに注意してください。現在、十分な強度の暗号化層が採用されていない限り、最新の実装は、暗号化の欠如のために許可されていないメカニズムを宣伝すべきではありません。
This document adds several new enhanced status codes to the list defined in [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.
この強化されたステータスコードは、現在選択されているSASLメカニズムで利用可能な最大バッファサイズよりも長いクライアントが[base64]応答を送信するため、サーバーが認証コマンドに失敗したときに返される必要があります。これは、永続的および永続的な過渡エラーの両方に役立ちます。
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サーバーは、メッセージコンテンツの開始時に「受信：ヘッダーフィールドを挿入する必要があります。このドキュメントは、生成された「受信：」ヘッダーフィールドのコンテンツに追加の要件を配置します。認証が成功すると、サーバーは「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
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-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-char）[base64ターミナル]）
base64-char = ALPHA / DIGIT / "+" / "/"
;; Case-sensitive
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].
initial-response= base64 / "="
cancel-response = "*"
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]の交渉が始まる前に、プロトコルの相互作用は明確なもので実行され、アクティブな攻撃者によって変更される場合があります。このため、クライアントとサーバーは、セキュリティ層の確立時に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ポートを保護しないため、アクティブな攻撃者はリレー接続の試み（つまり、2つのメール転送エージェント（MTA）間の接続）をリダイレクトして提出ポート[送信]にリダイレクトする場合があります。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]メカニズムが宣伝されるたびに、ユーザーが認証を行う必要があります。したがって、そのメカニズムを使用すると、匿名の提出に対するメリットがない場合、提出サーバー[提出]が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].
実装が受動的な盗聴攻撃（[Plain]など）に対して脆弱なSASLメカニズムをサポートする場合、実装は、これらのSASLメカニズムが外部のセキュリティレイヤーの存在なしに宣伝または使用されない少なくとも1つの構成をサポートする必要があります。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 Data Encodings」、RFC 4648、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。、「Enhanced Mail System Status Codes」、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。、「Simple Mail Transfer Protocol（SMTP）サービス拡張配信ステータス通知（DSNS）」、RFC 3461、2003年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、「Simple Authentication and Security Layer（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。、「Simple Mail Transfer Protocol」、RFC 2821、2001年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。and 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、「Message Submission for Mail」、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.
[Plain] Zeilenga、K.、ed。、「The Plain Simple Authentication and Security Layer（SASL）メカニズム」、RFC 4616、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、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[PGP] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[PGP] Elkins、M。、「Pretty Good Privacy（PGP）のMIMEセキュリティ」、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.、ed。、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年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、「The Transport Layer Security（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 2195、1997年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.
編集者は、ジョン・マイヤーズとRFC 2554へのその他の貢献者の貢献を認めたいと考えています。
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.
編集者はまた、ケン・マーチソン、マーク・クリスピン、クリス・ニューマン、デビッド・ウィルソン、デイブ・クライドランド、フランク・エラーマン、ネッド・フリード、ジョン・クレンシン、トニー・フィンチ、アブヒジット・メノン・セン、フィリップ・ゲンテル、サム・ハートマン、ラス・ハウスリー、Cullen Jenningssに感謝したいと思います。、そして、彼らがこのドキュメントのレビューや受け取ったコメントのレビューに専念していたリサ・デュッセー。
This section is normative for SMTP implementations that support SASL [PLAIN] over [TLS].
このセクションは、[TLS]よりもSASL [プレーン]をサポートする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クライアントがTLSを介してSASLプレーンを使用して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]交渉が成功した後、クライアントは、中間の攻撃を防ぐために、サーバー証明書メッセージに表示されるサーバーのIDに対してサーバーのホスト名の理解を確認する必要があります。一致が失敗した場合、クライアントは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 Canonicalizationは行われていません。
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のsumbercaltname拡張が証明書に存在する場合、サーバーのIDのソースとして使用する必要があります。
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. RFC 4234を使用するためにABNFセクションを更新しました。
10. Clarified interaction with SMTP PIPELINING extension.
10. SMTP Pipelining Extensionとの相互作用を明確にしました。
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 Ampitheatre Parkway Mountain View、CA 94043、米国
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 Castle Business Village、36 Station Road、ハンプトン、ミドルセックス、TW12 2BX、英国
EMail: Alexey.Melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。