RFC2554 日本語訳
2554 SMTP Service Extension for Authentication. J. Myers. March 1999. (Format: TXT=20534 bytes) (Obsoleted by RFC4954) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Myers Request for Comments: 2554 Netscape Communications Category: Standards Track March 1999
コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 2554年のネットスケープ・コミュニケーションズカテゴリ: 1999年の標準化過程行進
SMTP Service Extension
for Authentication
認証のためのSMTPサービス拡張子
Status of this Memo
この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 Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Introduction
1. 序論
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]を定義します。 この拡大はSimple AuthenticationとSecurity Layer[SASL]のプロフィールです。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
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"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。
3. The Authentication service extension
3. Authenticationサービス拡張子
(1) the name of the SMTP service extension is "Authentication"
(1) SMTPサービス拡張子の名前は「認証」です。
(2) the EHLO keyword value associated with this extension is "AUTH"
(2) この拡大に関連しているEHLOキーワード価値は"AUTH"です。
Myers Standards Track [Page 1] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[1ページ]。
(3) The AUTH EHLO keyword contains as a parameter a space separated
list of the names of supported SASL mechanisms.
(3) AUTH EHLOキーワードはパラメタとしてサポートしているSASLメカニズムの名前のスペースの切り離されたリストを含んでいます。
(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:
a string identifying a SASL authentication mechanism.
an optional base64-encoded response
議論: a 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コマンドを全く発行しないかもしれません。 後aうまくいっている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.
認証プロトコル交換は一連の認証機構に特定のサーバ挑戦とクライアント答えから成ります。 別の方法で持ち合わせの応答として知られているサーバ挑戦はテキスト部分がBASE64を含んでいる334回答がストリングをコード化したということです。 クライアント答えはコード化されたBASE64を含んでいると結ばれる系列から成ります。 クライアントが認証交換を中止したいなら、それは単一の「*」で系列を発行します。 サーバがそのような答えを受けるなら、それは、501回答を送ることによって、AUTHコマンドを拒絶しなければなりません。
Myers Standards Track [Page 2] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[2ページ]。
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で記載されたものなどの、より特定のエラーコードが適切でない場合AUTHが535回答で命令するSHOULD廃棄物です。 クライアントが首尾よく認証交換を終了するなら、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に続いて、それは効きます。セキュリティ層が実施するとき、SMTPプロトコルは初期状態にリセットされます(サーバの後のSMTPの州は220のサービスの持ち合わせの挨拶を発行します)。 サーバはクライアントから得られたどんな知識も捨てなければなりません、EHLOコマンドへの議論などのように。(コマンドはSASL交渉自体から得られませんでした)。 クライアントはサーバから得られたどんな知識も捨てなければなりません、SMTPサービス拡張子のリストなどのように(クライアントがそうする例外に認証の前後に活発な下がっている交渉攻撃を検出するために広告を出しているSASLメカニズムのリストをたとえてください)。(拡張子はSASL交渉自体から得られませんでした)。 クライアントSHOULDはセキュリティ層を可能にすることをもたらすうまくいっている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コマンドを発行することによって、別の認証機構を試すかもしれません。
Myers Standards Track [Page 3] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[3ページ]。
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一夜漬け-MD5ダイジェスト-MD5C: AUTH FOOBAR S: 504 認識されていない認証タイプ。 C: AUTH一夜漬け-MD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4はCと等しいです: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 認証うまくいきます。
5. The AUTH parameter to the MAIL FROM command
5. MAIL FROMコマンドへのAUTHパラメタ
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].
議論: 配送システムにメッセージを提出したアイデンティティ、またはそのようなアイデンティティが未知か不十分に認証されているのを示す2キャラクタシーケンス「<>」を含むaddr-仕様。 ESMTPパラメタに課された制限に従うために、addr-仕様は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.
AUTH拡張子をサポートするどんなサーバにもメッセージをリレーするとき、サーバが元々供給されたaddr-仕様でメッセージを提出したと断言するためにクライアントの認証されたアイデンティティを信じるなら、サーバSHOULDはAUTHパラメタで同じaddr-仕様を提供します。
Myers Standards Track [Page 4] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[4ページ]。
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のMAIL FROMパラメタ=>は、メッセージのオリジナルのsubmitterが知られていないのを示します。 サーバは元々クライアントによって提出されたとしてメッセージを扱ってはいけません。
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.
MAIL FROMへのAUTHパラメタは提供されません、とクライアントが認証して、サーバは信じています。メッセージがクライアントによるオリジナルの服従である、AUTH拡張子をサポートするどんなサーバにもメッセージをリレーするとき、サーバはAUTHパラメタのaddr-仕様のクライアントのアイデンティティを供給するかもしれません。
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.
それは、実装が不十分に信じられるとしてすべてを扱うために一生懸命コード化されたクライアントであるために従っています。 その場合、実装は、MAIL FROMコマンドへのシンタクス上有効なAUTHパラメタとどんなサーバへの<>供給AUTH=パラメタもAUTH拡張子を使用することでそれが認証するものにただ分析して、捨てます。
Examples:
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
Myers Standards Track [Page 5] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[5ページ]。
6. Error Codes
6. エラーコード
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以外のどんなコマンドでもこの応答を返すかもしれません。 それは、サーバ方針が要求された動作を実行するために認証を必要とするのを示します。
Myers Standards Track [Page 6] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[6ページ]。
7. Formal Syntax
7. 正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [ABNF].
以下の構文仕様は[ABNF]の指定されるとしての増大しているBN記法(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。 以下を大文字してください。 1Zです。
LOALPHA = %x61-7A ;; Lowercase: a-z
LOALPHA=%x61-7A。 小文字で印刷します: 1zです。
ALPHA = UPALPHA / LOALPHA ;; case insensitive
アルファーはUPALPHA / LOALPHAと等しいです。 大文字と小文字を区別しない
DIGIT = %x30-39 ;; Digits 0-9
ケタ=%x30-39。 ケタ0-9
HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase)
HEXDIGIT=%x41-46/ケタ。 hexidecimalケタ(大文字する)です。
hexchar = "+" HEXDIGIT HEXDIGIT
hexcharは「+」 HEXDIGIT HEXDIGITと等しいです。
xchar = %x21-2A / %x2C-3C / %x3E-7E
;; US-ASCII except for "+", "=", SPACE and CTL
xcharは%x21-2A/%x2C-3とC/%x3E-7E等しいです。 「+」、「=」、スペース、およびCTLを除いた米国-ASCII
xtext = *(xchar / hexchar)
xtextは*と等しいです。(xchar / hexchar)
AUTH_CHAR = ALPHA / DIGIT / "-" / "_"
AUTH_炭はアルファ/ケタ/「-」/"_"と等しいです。
auth_type = 1*20AUTH_CHAR
auth_タイプは1*20AUTH_CHARと等しいです。
auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64]) CRLF
"AUTH"auth_コマンド=スペースauth_は[スペース(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の解読されたフォームはどちらかであるに違いありません。 キャラクタ「<>」という1か2つのaddr-仕様
base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64はbase64_端末/と等しいです。(1*(4base64_炭)[base64_端末])
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
「base64_炭=UPALPHA / LOALPHA / DIGIT /「+」/」/、」、。 大文字と小文字を区別
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_端末=(2base64_炭の「=」)/(3base64_炭の「=」)
continue_req = "334" SPACE [base64] CRLF
「334」スペース[base64]_req=CRLFを続けてください。
Myers Standards Track [Page 7] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[7ページ]。
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
スペース=%x20。 ASCII SP、スペース
8. References
8. 参照
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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月。
[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サービス拡張子」、RFC1869、1995年11月。
[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[ESMTP-DSN] ムーア、K、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年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] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[SASL] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC
2476, December 1998.
[提出します] GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[RFC821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
Myers Standards Track [Page 8] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[8ページ]。
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 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メカニズムの広告を出すときはいつも、ユーザが認証するのを要求するかもしれないメッセージ。 したがって、そのメカニズムの使用が匿名の服従の上で利益を全くクライアントに与えないとき、服従サーバ[SUBMIT]がSASLメカニズムの広告を出すのは、望ましくないかもしれません。
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) それはメッセージが送付者が互いに適切なセキュリティ層を次のホップで認証して、交渉する場合における次のホップに提供されたという何らかの保証を送付者に与えることができます。
Myers Standards Track [Page 9] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[9ページ]。
Additional security considerations are mentioned in the SASL specification [SASL].
追加担保問題はSASL仕様[SASL]で言及されます。
10. Author's Address
10. 作者のアドレス
John Gardiner Myers Netscape Communications 501 East Middlefield Road Mail Stop MV-029 Mountain View, CA 94043
マウンテンビュー、ジョンガーディナーマイアーズネットスケープ・コミュニケーションズ501の東Middlefield道路メール停止MV-029カリフォルニア 94043
EMail: jgmyers@netscape.com
メール: jgmyers@netscape.com
Myers Standards Track [Page 10] RFC 2554 SMTP Authentication March 1999
マイアーズ規格は1999年のSMTP認証行進のときにRFC2554を追跡します[10ページ]。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Myers Standards Track [Page 11]
マイアーズ標準化過程[11ページ]
一覧
スポンサーリンク
