RFC4954 日本語訳
4954 SMTP Service Extension for Authentication. R. Siemborski, Ed., A.Melnikov, Ed.. July 2007. (Format: TXT=43493 bytes) (Obsoletes RFC2554) (Updates RFC3463) (Updated by RFC5248) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループR.Siemborski、エドをネットワークでつないでください。コメントのために以下を要求してください。 4954 Google Inc.は以下を時代遅れにします。 2554 エドA.メリニコフ、アップデート: 3463年のIsode株式会社カテゴリ: 標準化過程2007年7月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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クライアントが認証機構をサーバに示して、認証プロトコル交換を実行して、セキュリティ層を任意に交渉するかもしれないSimpleメールTransportプロトコル(SMTP)拡大を定義します。 この拡大はSMTPのためのSimple AuthenticationとSecurity Layer(SASL)のプロフィールを含んでいます。
This document obsoletes RFC 2554.
このドキュメントはRFC2554を時代遅れにします。
Siemborski & Melnikov Standards Track [Page 1] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[1ページ]。
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. 序論…2 2. どうこのドキュメントを読むか…2 3. 認証サービス拡大…3 4. AUTHは命令します…3 4.1. 例…7 5. MAIL FROMへのAUTH Parameterは命令します…9 5.1. 例…10 6. 状態コード…11 7. サーバに関する追加要件…12 8. 正式な構文…13 9. セキュリティ問題…14 10. IANA問題…15 11. 標準の参照…15 12. 有益な参照…16 13. 承認…17 14. 単にTLSの上の追加要件いつ使用SASL…17 15. RFC2554以来の変化…18
1. Introduction
1. 序論
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クライアントが認証機構をサーバに示して、認証プロトコル交換を実行して、その後のプロトコル相互作用のために任意に今会期中にセキュリティ層を交渉して、郵便配達システムにメッセージを提出したアイデンティティに関連しているメールボックスを任意に指定するかもしれないSimpleメールTransportプロトコル(SMTP)拡大を定義します。
This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
この拡大はSMTPのためのSimple AuthenticationとSecurity Layer(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.
RFC2554と比べると、このドキュメントは、SMTP PIPELINING[PIPELINING]拡張子で538応答コードの使用を非難して、新しいEnhanced Status Codeを加えて、SASLprepが承認のアイデンティティを準備するために輪郭を描くサポートに要件を加えて、RFC3848トランスミッションの使用がReceived跡のヘッダーフィールドをタイプすることを勧めて、相互作用をはっきりさせます。
2. How to Read This Document
2. このドキュメントを読む方法
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[キーワード]で説明されるように本書では解釈されることであるべきですか?
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
Siemborski & Melnikov Standards Track [Page 2] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[2ページ]。
3. The Authentication Service Extension
3. 認証サービス拡大
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. "AUTH"という新しい[SMTP]動詞は定義されます。
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. 服従プロトコル[SUBMIT]に、この拡大は適切です。
4. The AUTH Command
4. AUTHコマンド
AUTH mechanism [initial-response]
AUTHメカニズム[初期の応答]
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コマンドを全く発行しないかもしれません。 後aうまくいっている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コマンドはメールトランザクションの間、受入れられません。 503回答でメールトランザクションの間に発行されたAUTHコマンドを拒絶しなければなりません。
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交換を実行します。
Siemborski & Melnikov Standards Track [Page 3] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[3ページ]。
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]拡大をサポートして、それはSHOULDリターンa5.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コマンドへの任意の初期の応答議論は、初期のクライアント応答をサポートする認証機構を使用する往復のaを保存するのに使用されます。 初期の応答議論が省略されて、選ばれたメカニズムが初期のクライアント応答を必要とするなら、サーバは[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]で定義された行長制限を受けることがあることに注意してください。 初期の応答議論の使用がこの長さを超えるAUTHコマンドを引き起こすなら、クライアントは初期の応答パラメタを使用してはいけません(代わりに[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コマンドに使用するなら、サーバは拒絶されなければなりません。
Siemborski & Melnikov Standards Track [Page 4] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[4ページ]。
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.
AUTHは501回答で命令します。 高められたステータスコード拡大[ESMTP-CODES]SHOULDを使用するサーバがこの場合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回答でAUTHコマンドを拒絶しなければならない、(5.5の高められたステータスコード、.2)。 クライアントがそうすることができないなら、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の八重奏が配布している認証機構の取り扱いのための十分な行長限界であると考えられます。) サーバが認証交換の間、サーバの認証バッファより長い台詞を受けるなら、500回答に応じて、サーバはAUTHコマンドに失敗します。 高められたステータスコード拡大[ESMTP-CODES]SHOULDを使用するサーバがこの場合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]で定義された意味における)です、そして、クライアントとサーバSHOULD(*)の両方がトランスミッションか比較のためにこれらの名前を準備するのに[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
サーバはクライアントを認証できないで、それは、より特定のエラーコードが適切でない場合AUTHが535回答で命令するSHOULD廃棄物です。 クライアントが首尾よく交換を終了するなら、SMTPサーバーは235回答を発行します。 (SMTPプロトコルが帰り追加することのSASLの特徴をサポートしないことに注意してください。
Siemborski & Melnikov Standards Track [Page 5] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[5ページ]。
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プロトコルは初期状態にリセットされます(サーバの後のSMTPの州は220のサービスの持ち合わせの挨拶を発行します)。 サーバはクライアントから得られたどんな知識も捨てなければなりません、EHLO議論などのように。(それは、SASL交渉自体から得られませんでした)。 同様に、クライアントはサーバから得られたどんな知識も捨てなければなりません、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.
クライアントSHOULDはセキュリティ層を可能にすることをもたらすうまくいっている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コマンドが失敗するなら、クライアントは認証なしで続くかもしれません。 あるいはまた、クライアントは、別の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]コマンドが交渉されたか、またはパスワード詮索からセッションを保護するある他のメカニズムが提供されていない場合。 サーバサイトSHOULD NOTはパスワード詮索に対してそのような保護メカニズムなしで平文パスワードメカニズムを可能にするどんな構成も使用します。
Siemborski & Melnikov Standards Track [Page 6] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[6ページ]。
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コマンドが[PIPELINING]拡大と共に使用されるとき、それはコマンドのpipelinedグループで持続コマンドであるに違いありません。 この規則への唯一の例外はAUTHコマンドがクライアントが発信できるSASLメカニズムのための初期の応答を含むとき、最初に1つの往復の層、およびセキュリティ層の中で完成するSASLメカニズムが知られているデータがクライアントによって交渉されないということです。 そのようなSASLメカニズムに関する2つの例が、PLAIN[PLAIN]とEXTERNAL[SASL]です。
4.1. Examples
4.1. 例
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
S: 220-smtp.example.com ESMTPサーバC: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPIダイジェスト-MD5 S: 250-ENHANCEDSTATUSCODES S: 250STARTTLS C: STARTTLS S: 220 TLSを始動するのにおいて準備ができる… TLS交渉は続いて、TLSによって保護されたさらなるコマンドは層にされます… C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPIダイジェスト-MD5平野C: AUTHの明瞭なdGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 認証うまくいきます。
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層が確立される前に交渉の部品は省略されました:
Siemborski & Melnikov Standards Track [Page 7] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[7ページ]。
... 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交渉は続いて、TLSによって保護されたさらなるコマンドは層にされます… C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTH GSSAPIダイジェスト-MD5平野C: AUTH PLAIN(以下に注意してください、そして、334に続くシングルスペースが以下の系列にある)S: 334C: dGVzdAB0ZXN0ADEyMzQ= S: 235 2.7.0 認証うまくいきます。
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サーバC: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTHダイジェスト-MD5一夜漬け-MD5 S: 250-ENHANCEDSTATUSCODES S: 250STARTTLS C: AUTH一夜漬け-MD5 S: 334 PDQxOTI5NDIzNDEuMTI4Mjg0NzJAc291cmNlZm91ci5hbmRyZXcuY211LmVk dT4はCと等しいです: cmpzMyBlYzNhNTlmZWQzOTVhYmExZWM2MzY3YzRmNGI0MWFjMA== S: 235 2.7.0 認証うまくいきます。
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の下でAUTH EXTERNALを試みるクライアントの例があります、派生している承認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サーバC: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250-AUTH GSSAPIダイジェスト-MD5 S: 250-ENHANCEDSTATUSCODES S: 250STARTTLS C: STARTTLS S: 220 TLSを始動するのにおいて準備ができる… TLS交渉は続いて、TLSによって保護されたさらなるコマンドは層にされます… C: EHLO client.example.com S: 250-smtp.example.com Hello client.example.com S: 250 AUTHの外部のGSSAPIダイジェスト-MD5平野C: AUTHの外部の=S: 235 2.7.0 認証うまくいきます。
Siemborski & Melnikov Standards Track [Page 8] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[8ページ]。
5. The AUTH Parameter to the MAIL FROM command
5. MAIL FROMコマンドへのAUTH Parameter
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].
議論: 配送システムにメッセージを提出したアイデンティティ、またはそのようなアイデンティティが未知であることを示す2キャラクタシーケンス「<>」に関連づけられるか、または不十分に認証される<メールボックス>(.2セクション4.1[SMTP]を見ます)。 ESMTPパラメタに課された制限に従うために、<メールボックス>は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.
議論: 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.
AUTH拡張子をサポートするいかなる他のサーバにもメッセージをリレーするとき、サーバがメッセージが元々供給された<メールボックス>によって提出されたと断言するためにクライアントの認証されたアイデンティティを信じるなら、サーバSHOULDは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.
この理由で、クライアントがサーバにそれ自体を認証してさえいないとき、この拡大のサポートの広告を出すサーバは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パラメタ=>は、メッセージのオリジナルのsubmitterが知られていないのを示します。 サーバは元々AUTHコマンドから生じた認証されたアイデンティティで提出したとしてメッセージを扱ってはいけません。
Siemborski & Melnikov Standards Track [Page 9] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[9ページ]。
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パラメタであるなら供給されません、とクライアントが認証して、サーバは信じています。メッセージがオリジナルの服従である、サーバは<メールボックスが>であるとメッセージをリレーするときのAUTHパラメタにおける使用のためのユーザの認証されたアイデンティティからAUTH拡張子をサポートするどんなサーバまでも生成するかもしれません。 発生している<メールボックス>は実装特有ですが、それは[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.
サーバがクライアントの認証されたアイデンティティを十分信じないか、またはクライアントが認証されないなら、サーバはまるで<>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パラメタをMAIL FROMコマンドにただ分析して、捨てて、それが認証するどんなサーバへの>パラメタもAUTH=<に提供します。
5.1. Examples
5.1. 例
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: メールFROM:<eが mc2@example.com と等しい、gt;、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:
送付者のアイデンティティが信じられないか、またはそうでなければクライアントが抑圧されている1つの例:
C: MAIL FROM:<john+@example.org> AUTH=<> S: 250 OK
C: MAIL FROM:<john+@example.org> AUTH=<> S: 250 OK
Siemborski & Melnikov Standards Track [Page 10] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[10ページ]。
6. Status Codes
6. ステータスコード
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]SHOULD使用に高められたコードを返すサーバがここに示されました。
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]認証機構を使用しながら、通常一度認証することによって、これをします。 そして、選択されたメカニズムSHOULDはその後のセッションにおける認証のために働いています。
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.
AUTHコマンドへのこの応答は、認証が一時的なサーバ失敗のため失敗したのを示します。 クライアントSHOULD NOTはこの場合別のパスワードのためにユーザをうながします、そして、代わりに、サーバ失敗についてユーザに通知するべきです。
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コマンドへのこの応答は、そのユーザには、選択された認証機構がサーバ方針許可証より弱いのを示します。 クライアントSHOULDは新しい認証機構で再試行します。
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).
AUTHコマンドへのこの応答は、認証が無効の、または、不十分な認証資格証明書のため失敗したのを示します。 この場合、クライアントSHOULDは、新しい資格証明書(パスワードダイアログボックスを提示などなどの)を供給するようにユーザに頼みます。
500 5.5.6 Authentication Exchange line is too long
500 5.5.6 Exchangeが裏打ちする認証は長過ぎます。
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コマンドへのこの応答は、認証が現在選択されたSASLメカニズムに有効な最大のバッファサイズより長い[BASE64]応答を送るクライアントのため失敗したのを示します。
Siemborski & Melnikov Standards Track [Page 11] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[11ページ]。
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以外のどんなコマンドでもこの応答SHOULDを返して、サーバ方針が要求された動作と認証を実行するために認証を必要とする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接続が暗号化されているときだけ、選択された認証機構が使用されるかもしれないのを示します。 この応答コードが歴史的な目的だけのためにここに記録されることに注意してください。 近代的な実装SHOULD NOTは暗号化の不足のため受入れられないメカニズムの広告を出します、十分な力の暗号化層が現在使われていない場合。
This document adds several new enhanced status codes to the list defined in [ENHANCED]:
このドキュメントは[ENHANCED]で定義されたリストにいくつかの新しい高められたステータスコードを追加します:
The following 3 Enhanced Status Codes were defined above:
以下の3Enhanced Status Codesが以下の上で定義されました。
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.9Authenticationメカニズムは.11暗号化が要求された認証機構のために必要とした弱過ぎる5.7です。
X.5.6 Authentication Exchange line is too long
Exchangeが裏打ちする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.
これはステータスコードSHOULDを高めました。サーバが現在選択されたSASLメカニズムに有効な最大のバッファサイズより長い[BASE64]応答を送りながらクライアントによるAUTHコマンドに失敗したら、返してください。 これは永久的なものと同様に永続的な一時的エラーの役に立ちます。
7. Additional Requirements on Servers
7. サーバに関する追加要件
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サーバーは「受け取ったこと」を挿入しなければなりません。 メールの文頭の内容におけるヘッダーフィールド。 このドキュメントは「受け取りました」であると生成されたaの内容に追加要件を置きます。 ヘッダーフィールド。 うまくいっている認証、サーバSHOULD使用の"ESMTPA"か容認されたヘッダーフィールドの“with"節の"ESMTPSA"[SMTP-TT](適切であるときに)キーワード。
Siemborski & Melnikov Standards Track [Page 12] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[12ページ]。
8. Formal Syntax
8. 正式な構文
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]の指定されるとしてのAugmentedバッカス記法記法を使用します。 [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-3とC/%x3E-7E等しいです。 「+」、「=」、SP、およびCTLを除いた米国-ASCII
xtext = *(xchar / hexchar)
;; non-US-ASCII is only allowed as hexchar
xtextは*(xchar / hexchar)と等しいです。 非米国のASCIIはhexcharとして許容されているだけです。
auth-command = "AUTH" SP sasl-mech [SP initial-response]
*(CRLF [base64]) [CRLF cancel-response]
CRLF
;; <sasl-mech> is defined in [SASL]
"AUTH"SP sasl-mech[SPの初期の応答]*(CRLF[base64])[CRLFキャンセル応答]auth-コマンド=CRLF。 >が定義される<sasl-mech[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と等しいです。 MAIL FROMコマンドへのパラメタ。 ;; この非端末が従う、。 esmtp-param[SMTP]によって定義された構文。 ;; ;; xtextの解読されたフォームはそうであるに違いありません。 1か2<メールボックス>のどちらか。 キャラクタ「<>」
base64 = base64-terminal /
( 1*(4base64-char) [base64-terminal] )
base64はbase64-端末/と等しいです。(1*(4base64-炭)[base64端末の])
base64-char = ALPHA / DIGIT / "+" / "/"
;; Case-sensitive
「base64-炭=アルファー/ DIGIT /「+」/」/、」、。 大文字と小文字を区別
base64-terminal = (2base64-char "==") / (3base64-char "=")
base64-端末=(2base64-炭の「=」)/(3base64-炭の「=」)
continue-req = "334" SP [base64] CRLF
;; Intermediate response to the AUTH
;; command.
;; This non-terminal complies with
;; syntax defined by Reply-line [SMTP].
reqが継続的な=「334」SP[base64]CRLF。 AUTHへの中間的応答。 命令してください。 ;; この非端末が従う、。 Reply-系列[SMTP]によって定義された構文。
Siemborski & Melnikov Standards Track [Page 13] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[13ページ]。
initial-response= base64 / "="
初期の応答はbase64/「=」と等しいです。
cancel-response = "*"
キャンセル応答は「*」と等しいです。
9. Security Considerations
9. セキュリティ問題
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]接続をハイジャックして、サーバが、Authenticationが拡大であるとサポートしないふりをするか、または失敗するすべての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 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人のメール配達エージェント(MTAs)の間の接続)を服従ポート[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.
サーバは接続が多くの失敗した認証試みの後に下げられる政策を実施するかもしれません。 彼らはそうして、それらはSHOULD NOTです。認証する少なくとも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にサポートするなら、実装は[TLS]などの対外安全保障層の存在なしでこれらのSASLメカニズムを広告を出しもしませんし、使用もしないところで少なくとも1つの構成をサポートしなければなりません。
Siemborski & Melnikov Standards Track [Page 14] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[14ページ]。
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メカニズムに特定の追加担保問題は関連仕様で説明されます。 [TLS]の上の[PLAIN]のための追加担保問題はこのドキュメントのセクション15で言及されます。
10. IANA Considerations
10. IANA問題
IANA updated the entry for the "smtp" SASL protocol name to point at this document.
"smtp"SASLプロトコル名がこのドキュメントを指し示すように、IANAはエントリーをアップデートしました。
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で定義されるようにAuthentication SMTPサービス拡張子の登録をアップデートしました。 この登録は現在、<http://www.iana.org/課題/メールパラメタ>に位置しています。
11. Normative References
11. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[BASE64]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[ESMTP-CODES] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
解放された[ESMTP-コード]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[ENHANCED] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[高められます] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、2003年1月。
Siemborski & Melnikov Standards Track [Page 15] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[15ページ]。
[ESMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[ESMTP-DSN] ムーア、K.、「シンプルメールトランスファプロトコル(SMTP)サービス拡大配送状態通知(DSNs)」、RFC3461、2003年1月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[SMTP] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
over Transport Layer Security", RFC 3207, February
2002.
[SMTP-TLS]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[StringPrep] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[提出します] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
[SMTP-TT] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, July 2004.
[SMTP-TT] ニューマン、C.、「ESMTPとLMTPトランスミッションは登録をタイプする」RFC3848、2004年7月。
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August
2006.
[明瞭な] Zeilenga、K.、エド、「明瞭な簡易認証とセキュリティ層(SASL)のメカニズム」、RFC4616、8月2006日
[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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
12. Informative References
12. 有益な参照
[PGP] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[PGP]エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、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.、エド、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1は仕様を通信する」RFC3851、7月2004日
Siemborski & Melnikov Standards Track [Page 16] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[16ページ]。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
解放された[パイプライン処理]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、STD60、RFC2920、2000年9月。
[CRAM-MD5] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
AUTHorize Extension for Simple Challenge/Response", RFC
2195, September 1997.
[一夜漬け-MD5] Klensin、J.、Catoe、R.、およびP.Krumviede、「/が飛び出させるIMAPは簡単な挑戦/応答のための拡大を認可する」RFC2195、1997年9月。
13. Acknowledgments
13. 承認
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.
また、エディタは、彼らがこのドキュメントを再検討するのに注ぐ、そして/または、コメントのために受信したのを時間のケン・マーチソン、マーク・クリスピン、クリス・ニューマン、デヴィッド・ウィルソン、デーヴCridland、フランクEllermann、ネッド・フリード、ジョンKlensin、トニーFinch、Abhijitメノン-銭、フィリップ・グンサー、サム・ハートマン、ラスHousley、Cullenジョニングス、およびリサDusseaultに感謝したがっています。
14. Additional Requirements When Using SASL PLAIN over TLS
14. 単にTLSの上の追加要件いつ使用SASL
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クライアントがそうなら、[X509]の規則に従って、TLSの上でSASL PLAINを使用することを望んでいるのがSMTPサーバー、クライアントに認証するサーバ証明書について確かめます。 サーバがどんな証明書も提供していないか、または証明書検証が失敗するなら、クライアントは失敗しなければなりません。SASL PLAINメカニズムを使用する認証する試みでない。
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]交渉の後に、クライアントはサーバCertificateメッセージに示されるようにサーバのアイデンティティに対してサーバホスト名の理解をチェックしなければなりません、介入者攻撃を防ぐために。 マッチが失敗するなら、クライアントは失敗しなければなりません。SASL PLAINメカニズムを使用する認証する試みでない。 以下の規則に従って、マッチングは実行されます:
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
クライアントはそれがサーバ証明書で言い表されるようにサーバー名に対して比較するために値として接続を開くのに使用したサーバホスト名を使用しなければなりません。 クライアントは使用してはいけません。
Siemborski & Melnikov Standards Track [Page 17] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[17ページ]。
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の拡大はsubjectAltNameであるなら証明書に存在していて、それはSHOULDです。サーバのアイデンティティの源として、使用されます。
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.
証明書が複数の名前(例えば、1つ以上のdNSName分野)を含んでいるなら、分野のどれかとのマッチは許容できると考えられます。
15. Changes since RFC 2554
15. RFC2554以来の変化
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の使用をサポートしなければならないのはMAIL FROMへのメールボックスパラメタと等しいです、クライアントが認証さえされないとき。
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 PLAIN(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. RFC4234を使用するためにABNF部をアップデートしました。
10. Clarified interaction with SMTP PIPELINING extension.
10. SMTP PIPELINING拡張子との相互作用をはっきりさせました。
11. Added a reference to RFC 3848.
11. RFC3848の参照を加えました。
Siemborski & Melnikov Standards Track [Page 18] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[18ページ]。
12. Added a new Enhanced Status Code for "authentication line too
long" case.
12. 「認証はあまりに長い間、立ち並んでいる」ケースのために新しいEnhanced Status Codeを加えました。
13. Other general editorial clarifications.
13. 他の一般的な編集の明確化。
Editors' Addresses
エディタのアドレス
Robert Siemborski Google, Inc. 1600 Ampitheatre Parkway Mountain View, CA 94043, USA
ロバートSiemborski Google Inc.1600Ampitheatre Parkwayマウンテンビュー、カリフォルニア 94043、米国
Phone: +1 650 623 6925 EMail: robsiemb@google.com
以下に電話をしてください。 +1 6925年の650 623メール: robsiemb@google.com
Alexey Melnikov Isode Limited 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, UK
AlexeyメリニコフIsode株式会社5城のビジネス村、36駅の道路、ハンプトン、ミドルセックスTW12 2BX、イギリス
EMail: Alexey.Melnikov@isode.com
メール: Alexey.Melnikov@isode.com
Siemborski & Melnikov Standards Track [Page 19] RFC 4954 SMTP Service Extension for Authentication July 2007
SiemborskiとメリニコフStandardsは2007年7月に認証のためのRFC4954SMTPサービス拡張子を追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Siemborski & Melnikov Standards Track [Page 20]
Siemborskiとメリニコフ標準化過程[20ページ]
一覧
スポンサーリンク
