[要約] RFC 2554は、SMTPサービス拡張のための認証に関する規格であり、SMTPサーバーとクライアント間の認証を提供する。目的は、電子メールの送信者の身元確認とセキュリティの向上を実現すること。
Network Working Group J. Myers
Request for Comments: 2554 Netscape Communications
Category: Standards Track March 1999
SMTP Service Extension
for Authentication
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 Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document defines an SMTP service extension [ESMTP] 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. This extension is a profile of the Simple Authentication and Security Layer [SASL].
この文書は、SMTPクライアントは、サーバへの認証メカニズムを示す認証プロトコル交換を実行、および必要に応じてその後のプロトコル相互作用のためのセキュリティ層を交渉することができることにより、SMTPサービス拡張[ESMTP]を定義します。この拡張機能は、簡易認証セキュリティー層[SASL]のプロフィールです。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
実施例では、「C：」および「S：」はそれぞれクライアントとサーバから送信されたラインを示します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、およびこのドキュメントの「要件レベルを示すためにRFCsにおける使用のためのキーワード」[キーワード]で定義されるように解釈されるべきである「MAY」 。
(1) the name of the SMTP service extension is "Authentication"
（1）SMTPサービス拡張の名前は「認証」され
(2) the EHLO keyword value associated with this extension is "AUTH" (3) The AUTH EHLO keyword contains as a parameter a space separated list of the names of supported SASL mechanisms.
（2）この拡張子に関連付けられているEHLOキーワード値は「AUTH」である（3）AUTH EHLOキーワードがパラメータとしてサポートされているSASLメカニズムの名前のスペースで区切られたリストを含んでいます。
(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コマンドに加え、500文字でMAIL FROMコマンドの最大の行の長さを延びています。
(6) this extension is appropriate for the submission protocol [SUBMIT].
（6）この拡張は、[登録]提出プロトコルのために適切です。
AUTH mechanism [initial-response]
AUTH機構[初期応答]
Arguments: a string identifying a SASL authentication mechanism. an optional base64-encoded response
引数：SASL認証メカニズムを識別する文字列。任意base64エンコード応答
Restrictions: After an AUTH command has 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.
AUTHコマンドは、メールトランザクション中に許可されていません。
Discussion: The AUTH command indicates an authentication mechanism to the server. If the server supports the requested authentication mechanism, it performs an authentication protocol exchange to authenticate and identify the user. Optionally, it also negotiates a security layer for subsequent protocol interactions. If the requested authentication mechanism is not supported, the server rejects the AUTH command with a 504 reply.
ディスカッション：AUTHコマンドは、サーバーへの認証機構を示しています。サーバは要求された認証メカニズムをサポートしている場合、それはユーザーを認証し、識別するために、認証プロトコル交換を行います。必要に応じて、それはまた、その後のプロトコル相互作用のためのセキュリティ層を交渉します。要求された認証メカニズムがサポートされていない場合、サーバは504回答でAUTHコマンドを拒否します。
The authentication protocol exchange consists of a series of
server challenges and client answers that are specific to the
authentication mechanism. A server challenge, otherwise known
as a ready response, is a 334 reply with the text part
containing a BASE64 encoded string. The client answer consists
of a line containing a BASE64 encoded string. If the client
wishes to cancel an authentication exchange, it issues a line
with a single "*". If the server receives such an answer, it
MUST reject the AUTH command by sending a 501 reply.
The optional initial-response argument to the AUTH command is used to save a round trip when using authentication mechanisms that are defined to send no data in the initial challenge. When the initial-response argument is used with such a mechanism, the initial empty challenge is not sent to the client and the server uses the data in the initial-response argument as if it were sent in response to the empty challenge. Unlike a zero-length client answer to a 334 reply, a zero-length initial response is sent as a single equals sign ("="). If the client uses an initial-response argument to the AUTH command with a mechanism that sends data in the initial challenge, the server rejects the AUTH command with a 535 reply.
AUTHコマンドのオプションの初期応答の引数は、初期の挑戦にデータを送信しないように定義されている認証メカニズムを使用した場合の往復を保存するために使用されます。初期応答の引数が、このような機構を使用する場合は、最初の空のチャレンジはクライアントに送信されていない、それは空のチャレンジに応答して送信されたかのようにサーバが初期応答引数にデータを使用しています。 334応答にゼロ長クライアント回答とは異なり、長さゼロの初期応答は、単一の等号（「=」）として送信されます。クライアントが初期の挑戦にデータを送り機構をAUTHコマンドへの初期応答の引数を使用している場合、サーバは535回答でAUTHコマンドを拒否します。
If the server cannot BASE64 decode the argument, it rejects the AUTH command with a 501 reply. If the server rejects the authentication data, it SHOULD reject the AUTH command with a 535 reply unless a more specific error code, such as one listed in section 6, is appropriate. Should the client successfully complete the authentication exchange, the SMTP server issues a 235 reply.
サーバはBASE64は引数をデコードすることができないなら、それは501回答でAUTHコマンドを拒否します。サーバが認証データを拒否した場合、それはセクション6に記載されている一つは、適切であるような、より具体的なエラーコードしない限り、535応答でAUTHコマンドを拒否すべきです。クライアントが正常に認証交換を完了する必要があり、SMTPサーバは235応答を発行します。
The service name specified by this protocol's profile of SASL is "smtp".
SASLのこのプロトコルのプロファイルで指定されたサービス名は「SMTP」です。
If a security layer is negotiated through the SASL authentication exchange, it takes effect immediately following the CRLF that concludes the authentication exchange for the client, and the CRLF of the success reply for the server. Upon a security layer's taking 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 argument to the EHLO command, which was not obtained from the SASL negotiation itself. 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 (with the exception that a client MAY compare the list of advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack). The client SHOULD send an EHLO command as the first command after a successful SASL negotiation which results in the enabling of a security layer.
セキュリティ層がSASL認証交換を通して交渉されている場合、それはすぐにクライアントの認証交換、およびサーバの成功リプライのCRLFを終えるCRLF次のような効果になります。 （サーバーが220サービス用意挨拶を発行した後、SMTPでの状態）のセキュリティレイヤの撮影効果の際に、SMTPプロトコルは初期状態にリセットされます。サーバーは、SASL交渉自体から得られなかったEHLOコマンドの引数として、クライアントから得た知識を捨てなければなりません。クライアントは、クライアントが前と順に認証後に広告を出してSASLメカニズムのリストを比較することができることを除いて（SASL交渉自体から得られなかったSMTPサービス拡張のリストとして、サーバから取得したすべての知識を捨てなければなりませんアクティブダウン交渉の攻撃を検出するため）。クライアントは、セキュリティ層の有効化につながる成功したSASL交渉後の最初のコマンドとしてEHLOコマンドを送るべきです。
The server is not required to support any particular authentication mechanism, nor are authentication mechanisms required to support any security layers. If an AUTH command fails, the client may try another authentication mechanism by issuing another AUTH command.
サーバーは、特定の認証機構をサポートする必要はありません、また認証機構は、任意のセキュリティレイヤをサポートするために必要とされます。 AUTHコマンドが失敗した場合、クライアントは別のAUTHコマンドを発行することによって、別の認証機構を試すことがあります。
If an AUTH command fails, the server MUST behave the same as if the client had not issued the AUTH command.
AUTHコマンドが失敗した場合、サーバーは、クライアントがAUTHコマンドを発行していなかった場合と同じ振る舞いをしなければなりません。
The BASE64 string may in general be arbitrarily long. Clients and servers MUST be able to support challenges and responses that are as long as are generated by the authentication mechanisms they support, independent of any line length limitations the client or server may have in other parts of its protocol implementation.
BASE64文字列は、一般的に任意の長さであってもよいです。クライアントとサーバーは、クライアントまたはサーバーがそのプロトコル実装の他の部分で持っている可能性のある行の長さの制限とは無関係に、それらがサポートする認証メカニズムによって生成されている限り、あるチャレンジとレスポンスをサポートすることができなければなりません。
Examples: S: 220 smtp.example.com ESMTP server ready C: EHLO jgm.example.com S: 250-smtp.example.com S: 250 AUTH CRAM-MD5 DIGEST-MD5 C: AUTH FOOBAR S: 504 Unrecognized authentication type. C: AUTH CRAM-MD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful.
例：S：220 smtp.example.com ESMTPサーバーレディC：EHLO jgm.example.com S：250-smtp.example.com S：250 AUTH CRAM-MD5 DIGEST-MD5 C：AUTH FOOBAR S：504認識できない認証タイプ。 C：AUTH CRAM-MD5 S：334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4 = C：ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ == S：235認証が成功しました。
AUTH=addr-spec
AUTH = addrのスペック
Arguments: An addr-spec containing the identity which submitted the message to the delivery system, or the two character sequence "<>" indicating such an identity is unknown or insufficiently authenticated. To comply with the restrictions imposed on ESMTP parameters, the addr-spec is encoded inside an xtext. The syntax of an xtext is described in section 5 of [ESMTP-DSN].
引数：送達システムにメッセージを送信した識別情報を含むADDR仕様、または2つの文字列「<>」は、同一性を示すが、未知の又は不十分認証されます。 ESMTPパラメータに制約を遵守するために、ADDR-specはXTEXT内部に符号化されます。 XTEXTの構文は[ESMTP - DSN]のセクション5に記載されています。
Discussion: The optional AUTH parameter to the MAIL FROM command allows cooperating agents in a trusted environment to communicate the authentication of 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
addr-spec, then the server SHOULD supply the same addr-spec in an
AUTH parameter when relaying the message to any server which
supports the AUTH extension.
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 client.
AUTH = <>のパラメータからのメールは、メッセージの元の提出者が不明であることを示しています。サーバは、元々クライアントによって提出されたとのメッセージを処理してはなりません。
If the AUTH parameter to the MAIL FROM is not supplied, the client has authenticated, and the server believes the message is an original submission by the client, the server MAY supply the client's identity in the addr-spec in an AUTH parameter when relaying the message to any server which supports the AUTH extension.
FROM MAILにAUTHパラメータが供給されていない場合は、クライアントが認証されており、サーバはメッセージがクライアントによって、元の提出であると考えてリレーするとき、サーバはAUTHパラメータでaddrのスペックで、クライアントのアイデンティティを供給することができます。 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 the 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パラメータを設定し、新しいサブミッションとして、メーリングリストの展開を扱うかもしれ。
It is conforming for an implementation to be hard-coded to treat all clients as being insufficiently trusted. 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 to which it authenticates using the AUTH extension.
それは十分に信頼できるものとして、すべてのクライアントを処理するためにハードコードされた対象の実装に準拠しています。その場合、実装は、AUTH拡張を使用して認証するための任意のサーバーにコマンドと供給AUTH = <>パラメータからMAILに構文的に有効なAUTHパラメータを解析し、捨てるより多くの何もしません。
Examples: C: MAIL FROM:<e=mc2@example.com> AUTH=e+3Dmc2@example.com S: 250 OK
例：<e=mc2@example.com> AUTH=e+3Dmc2@example.com S：250 OK C：FROM MAIL
The following error codes may be used to indicate various conditions as described.
以下のエラーコードが記載されているように様々な条件を示すために使用されてもよいです。
432 A password transition is needed
432パスワードの移行が必要とされています
This response to the AUTH command indicates that the user needs to transition to the selected authentication mechanism. This typically done by authenticating once using the PLAIN authentication mechanism.
AUTHコマンドへのこの応答はユーザが選択した認証メカニズムに移行する必要があることを示しています。これは典型的には、一度認証PLAIN認証メカニズムを使用して行います。
534 Authentication mechanism is too weak
534認証機構が弱すぎます
This response to the AUTH command indicates that the selected authentication mechanism is weaker than server policy permits for that user.
AUTHコマンドへのこの応答は、選択された認証メカニズムは、そのユーザーのサーバーのポリシーで許可さよりも弱いことを示しています。
538 Encryption required for requested authentication mechanism
要求された認証メカニズムのために必要な538の暗号化
This response to the AUTH command indicates that the selected authentication mechanism may only be used when the underlying SMTP connection is encrypted.
AUTHコマンドへのこの応答は、基礎となるSMTP接続が暗号化されているときに選択された認証メカニズムのみを使用することができることを示しています。
454 Temporary authentication failure
454一時的な認証失敗
This response to the AUTH command indicates that the authentication failed due to a temporary server failure.
AUTHコマンドへのこの応答は、認証が一時的なサーバー障害のために失敗したことを示しています。
530 Authentication required
530認証が必要
This response may be returned by any command other than AUTH, EHLO, HELO, NOOP, RSET, or QUIT. It indicates that server policy requires authentication in order to perform the requested action.
この応答はAUTH、EHLO、HELO、NOOP、RSET、またはQUIT以外のコマンドで返されてもよいです。これは、サーバーのポリシーが要求されたアクションを実行するために認証を必要とすることを示しています。
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定されるように拡張バッカスナウア記法（BNF）の表記を使用します。
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.
特記しないものを除いて、すべての英字は大文字と小文字を区別しません。トークン文字列を定義するための、大・小文字の使用は、編集上明確にするためです。実装は大文字と小文字を区別しないやり方で、これらの文字列を受け入れなければなりません。
UPALPHA = %x41-5A ;; Uppercase: A-Z
UPALPHA =％x41-5A ;;大文字：A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
LOALPHA =％x61-7A ;;小文字：-Z
ALPHA = UPALPHA / LOALPHA ;; case insensitive
ALPHA = UPALPHA / LOALPHA ;;大文字小文字を区別しません
DIGIT = %x30-39 ;; Digits 0-9
DIGIT =％x30-39 ;; 0-9
HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
16進数=％X 41-46 / DIGIT ;;進数字（大文字）
hexchar = "+" HEXDIGIT HEXDIGIT
hexchar = "+" HEXDIGITのHEXDIGIT
xchar = %x21-2A / %x2C-3C / %x3E-7E ;; US-ASCII except for "+", "=", SPACE and CTL
XCHAR =％x21-2A /％X2C-3C /％Spark Proの-7E ;; US-ASCII "+"、 "="、SPACEおよびCTLを除きます
xtext = *(xchar / hexchar)
XTEXT = *（XCHAR / hexchar）
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
AUTH_CHAR = ALPHA / DIGIT / " - " / "_"
auth_type = 1*20AUTH_CHAR
AUTH_TYPE = 1 * 20AUTH_CHAR
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")] *(CRLF [base64]) CRLF
auth_command = "AUTH" SPACEのAUTH_TYPE [SPACE（BASE64 / "="）] *（CRLF [BASE64]）CRLF
auth_param = "AUTH=" xtext ;; The decoded form of the xtext MUST be either ;; an addr-spec or the two characters "<>"
auth_param = "AUTH =" XTEXT ;; XTEXTの復号化された形式のいずれかでなければなりません;; addrのスペックまたは2つの文字「<>」
base64 = base64_terminal / ( 1*(4base64_CHAR) [base64_terminal] )
BASE64 = base64_terminal /（1 *（4base64_CHAR）base64_terminal]）
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" ;; Case-sensitive
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" ;;大文字と小文字を区別
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_terminal =（2base64_char "=="）/（3base64_char "="）
continue_req = "334" SPACE [base64] CRLF
continue_req = "334" SPACE [BASE64] CRLF
CR = %x0C ;; ASCII CR, carriage return
CR =％のx0C ;; ASCII CR、キャリッジリターン
CRLF = CR LF
CRLF = CR LF
CTL = %x00-1F / %x7F ;; any ASCII control character and DEL
CTL =％x00-1F /％x7F ;;任意のASCII制御文字とDEL
LF = %x0A ;; ASCII LF, line feed
LF =％X0A ;; ASCIIのLF、ラインフィード
SPACE = %x20 ;; ASCII SP, space
SPACE =％X20 ;; ASCIIのSP、スペース
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[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月。
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[ESMTP] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、 "SMTPサービス拡張"、RFC 1869、1995年11月。
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[ESMTP - DSN]ムーア、K、 "配送状態通知のためのSMTPサービス拡張"、RFC 1891、1996年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[SUBMIT] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC821]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
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接続をハイジャックし、どちらかのサーバが認証拡張をサポートしたり、すべてのAUTHコマンドが失敗する原因となっていないふりをして、クライアントのメールを盗むことができます。
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 completion of a SASL negotiation which results in a security layer.
SASLネゴシエーションが始まる前に、任意のプロトコル相互作用は明確に行われ、活発な攻撃者によって修正されてもよいです。このため、クライアントとサーバは、前のセキュリティ層になりSASL交渉の完了時にSASL交渉の開始に得た知識を捨てなければなりません。
This mechanism does not protect the TCP port, so an active attacker may redirect a relay connection attempt to the submission port [SUBMIT]. The AUTH=<> parameter prevents such an attack from causing an relayed message without an envelope authentication to pick up the authentication of the relay client.
このメカニズムは、TCPポートを保護しないので、アクティブな攻撃者は、サブミッションポート[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 client no benefits over anonymous submission.
メッセージ送信クライアントは、適切なSASL機構が公示されるたびに認証するためにユーザーが必要な場合があります。したがって、そのメカニズムの使用がクライアントに匿名の提出の上に何の恩恵を与えるものは存在しない時にSASLメカニズムを宣伝するために[SUBMIT]提出サーバーの望ましくないかもしれません。
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) it can give the sender some assurance the message was delivered to the next hop in the case where the sender mutually authenticates with the next hop and negotiates an appropriate security layer.
（4）送信者にメッセージを送信者が相互に次のホップを使用して認証し、適切なセキュリティ層を交渉する場合には次のホップに配信されたいくつかの保証を与えることができます。
Additional security considerations are mentioned in the SASL specification [SASL].
追加のセキュリティ上の考慮事項は、SASL仕様[SASL]に記載されています。
John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043
ジョン・ガーディナーマイヤーズネットスケープ・コミュニケーションズ501東ミドルロードメールストップMV-029マウンテンビュー、CA 94043
EMail: jgmyers@netscape.com
メールアドレス：jgmyers@netscape.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。