Network Working Group M. Crispin
Request for Comments: 4467 University of Washington
Updates: 3501 May 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) - URLAUTH Extension
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.
このドキュメントは、インターネットメッセージアクセスプロトコル（IMAP）（RFC 3501）およびIMAP URLスキーム（IMAPURL）（RFC 2192）にURLAUTH拡張を説明しています。この拡張は、IMAPクライアントがIMAPサーバー上の制限されたメッセージデータにアクセスするための許可を運ぶURLを使用することができる手段を提供します。
An IMAP server that supports this extension indicates this with a capability name of "URLAUTH".
この拡張機能をサポートしているIMAPサーバは、「URLAUTH」の機能名でこれを示します。
In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20 requires authorization as userid "fred". However, [IMAPURL] implies that it only supports authentication and confuses the concepts of authentication and authorization.
【IMAPURL]において、フォームIMAPのURL：//fred@example.com/INBOX/は、UID = 20は、ユーザID「フレッド」として認可を必要とします。ただし、[IMAPURL]それが唯一の認証をサポートし、認証と認可の概念を混乱させることを意味します。
The URLAUTH extension defines an authorization mechanism for IMAP URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH conveys authorization in the URL string itself and reuses a portion of the syntax of the [IMAPURL] authentication mechanism to convey the authorization identity (which also defines the default namespace in [IMAP]).
URLAUTH拡張は[IMAPURL]の認証のみのメカニズムを交換するIMAP URLの許可メカニズムを定義します。 URLAUTHは、URL文字列自体に許可を搬送し、（また、[IMAP]のデフォルトの名前空間を定義）承認のアイデンティティを伝達する[IMAPURL】認証機構の構文の一部を再利用します。
The URLAUTH extension provides a means by which an authorized user of an IMAP server can create URLAUTH-authorized IMAP URLs. A URLAUTH-authorized URL conveys authorization (not authentication) to the data addressed by that URL. This URL can be used in another IMAP session to access specific content on the IMAP server, without otherwise providing authorization to any other data (such as other data in the mailbox specified in the URL) owned by the authorizing user.
URLAUTH拡張は、IMAPサーバの許可されたユーザがURLAUTH許可IMAP URLを作成することができる手段を提供します。 URLAUTH認可URLはそのURLによってアドレス指定されたデータへの認可（ない認証）を伝えます。このURLは、そうでない場合は認可ユーザーが所有している（たとえば、URLで指定されたメールボックス内の他のデータなど）の任意の他のデータに許可を与えることなく、IMAPサーバー上の特定のコンテンツにアクセスするために別のIMAPセッションで使用することができます。
Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn ticket" that carries no authentication information and can be redeemed by whomever presents it. However, unlike a pawn ticket, URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-authorized URL. Using these mechanisms, URLAUTH-authorized URLs can be usable by:
概念的には、URLAUTH認可URLは認証情報を運ばないし、それを提示誰によって償還することができる「ポーンチケット」と考えることができます。しかし、ポーンチケットとは異なり、URLAUTHはURLAUTH許可URLの使用を制限するには、オプションの仕組みを持っています。これらのメカニズムを使用して、URLAUTH許可URLはによって使用可能であることができます。
. anonymous (the "pawn ticket" model) . authenticated users only . a specific authenticated user only . message submission acting on behalf of a specific user only
。匿名（「ポーンチケット」モデル）。認証されたユーザーのみ。特定の認証されたユーザーのみ。特定のユーザーに代わって動作するメッセージ送信のみ
There is also a mechanism for expiration.
有効期限のメカニズムもあります。
A URLAUTH-authorized URL can be used in the argument to the BURL command in message composition, as described in [BURL], for such purposes as allowing a client (with limited memory or other resources) to submit a message forward or to resend from an IMAP mailbox without requiring the client to fetch that message data.
【BURL]に記載されているようにURLAUTH許可URLは、順方向メッセージを送信するか、から再送する（限られたメモリ又は他のリソースとの）クライアントを許可するような目的のために、メッセージの組成物中のバール・コマンドの引数に使用することができますそのメッセージデータをフェッチするために、クライアントを必要とせずにIMAPメールボックス。
The URLAUTH is generated using an authorization mechanism name and an authorization token, which is generated using a secret mailbox access key. An IMAP client can request that the server generate and assign a new mailbox access key (thus effectively revoking all current URLs using URLAUTH with the old mailbox access key) but cannot set the mailbox access key to a key of its own choosing.
URLAUTHは、認可メカニズム名と秘密のメールボックスのアクセスキーを使用して生成された認証トークンを使用して生成されます。 IMAPクライアントは、（効果的に古いメールボックスへのアクセスキーでURLAUTHを使用して、すべての現在のURLを取り消す）サーバが生成し、新しいメールボックスのアクセスキーを割り当てることを要求することができますが、その自身の選択のキーへのメールボックスのアクセスキーを設定することはできません。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
[KEYWORDS]で定義されるようにキーワード "MUST" は、 "MUST NOT"、 "SHOULD NOT"、および本書で解釈されるべきである、 "MAY"、 "SHOULD"。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation including the core rules defined in Appendix A of [ABNF].
正式な構文は、[ABNF]の付録Aで定義されたコア・ルールを含めた拡張バッカス - ナウアフォーム（ABNF）の表記を使用します。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。シングル「C：」場合や「S：」ラベルは複数行に適用され、その後、これらの線の間の改行は編集上明確にするためであり、実際のプロトコル交換の一部ではありません。
The URLAUTH is a component, appended at the end of a URL, that conveys authorization to access the data addressed by that URL. It contains an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, the authorization mechanism name, and a mailbox access key.
URLAUTHはそのURLによってアドレス指定されたデータにアクセスするための許可を伝えるURLの末尾に追加コンポーネント、です。これは、許可されたアクセス識別子、認証機構名、および認証トークンが含まれています。許可トークンは、URL、許可されたアクセス識別子、認証機構名、およびメールボックスのアクセスキーから生成されます。
The mailbox access key is a random string with at least 128 bits of entropy. It is generated by software (not by the human user) and MUST be unpredictable.
メールボックスアクセスキーは、エントロピーの少なくとも128ビットのランダムな文字列です。これは（ない人間のユーザによって）ソフトウェアによって生成され、予測不可能でなければなりません。
Each user has a table of mailboxes and an associated mailbox access key for each mailbox. Consequently, the mailbox access key is per-user and per-mailbox. In other words, two users sharing the same mailbox each have a different mailbox access key for that mailbox, and each mailbox accessed by a single user also has a different mailbox access key.
各ユーザは、メールボックスのテーブルと各メールボックスに関連付けられたメールボックスアクセスキーを有しています。そのため、メールボックスのアクセスキーは、ユーザー単位およびメールボックスです。換言すれば、それぞれ同じメールボックスを共有する2人のユーザがそのメールボックスの別のメールボックスへのアクセスキーを持ち、単一のユーザがアクセスする各メールボックスは、異なるメールボックスアクセスキーを有しています。
The authorized access identifier restricts use of the URLAUTH authorized URL to certain users authorized on the server, as described in section 3.
許可アクセス識別子は、セクション3に記載されているように、サーバ上の許可特定のユーザーにURLAUTH許可URLの使用を制限します。
The authorization mechanism is the algorithm by which the URLAUTH is generated and subsequently verified, using the mailbox access key.
認証メカニズムはURLAUTHがメールボックスのアクセスキーを使用して、生成され、その後に検証されるアルゴリズムです。
This specification defines the INTERNAL mechanism, which uses a token generation algorithm of the server's choosing and does not involve disclosure of the mailbox access key to the client.
この仕様は、サーバーの選択したトークン生成アルゴリズムを使用し、クライアントへのメールボックスのアクセスキーの開示を必要としない内部機構を、定義されています。
Note: The token generation algorithm chosen by the server implementation should be modern and reasonably secure. At the time of the writing of this document, an [HMAC] such as HMAC-SHA1 is recommended.
注：サーバーの実装によって選ばれたトークンの生成アルゴリズムは、近代的かつ合理的に安全である必要があります。このドキュメントの執筆時点では、そのようなHMAC-SHA1など[HMAC]は推奨されます。
If it becomes necessary to change the token generation algorithm of the INTERNAL mechanism (e.g., because an attack against the current algorithm has been discovered), all currently existing URLAUTH-authorized URLs are invalidated by the change in algorithm. Since this would be an unpleasant surprise to applications that depend upon the validity of a URLAUTH-authorized URL, and there is no good way to do a bulk update of existing deployed URLs, it is best to avoid this situation by using a secure algorithm as opposed to one that is "good enough".
それは（現在のアルゴリズムに対する攻撃が発見されているので、例えば、）内部機構のトークン生成アルゴリズムを変更する必要が生じた場合、すべての現存URLAUTH許可URLはアルゴリズムの変化によって無効化されます。これはURLAUTH許可URLの有効性に依存するアプリケーションに不快な驚きだろう、と既存の展開のURLの一括更新を行うには良い方法はありませんので、それは安全なアルゴリズムを使用することによって、この状況を回避するのが最善です「十分」であるものに反対しました。
Server implementations SHOULD consider the possibility of changing the algorithm. In some cases, it may be desirable to implement the change of algorithm in a way that newly-generated tokens use the new algorithm, but that for a limited period of time tokens using either the new or old algorithm can be validated. Consequently, the server SHOULD incorporate some means of identifying the token generation algorithm within the token.
サーバ実装は、アルゴリズムの変更の可能性を検討すべきです。いくつかのケースでは、新たに生成されたトークンは、新しいアルゴリズムを使用する方法で、アルゴリズムの変更を実施することが望ましいかもしれないが、それは新しいか古いアルゴリズムのいずれかを使用してタイムトークンの限られた期間のために有効にすることができます。したがって、サーバは、トークン内のトークン生成アルゴリズムを識別する何らかの手段を組み込むべきです。
Although this specification is extensible for other mechanisms, none are defined in this document. In addition to the mechanism name itself, other mechanisms may have mechanism-specific data, which is to be interpreted according to the definition of that mechanism.
本明細書は、他の機構のために拡張可能であるが、いずれも本文書で定義されていません。機構名自体に加えて、他の機構は、その機構の定義に従って解釈されるべきである機構固有のデータを有していてもよいです。
The authorization token is a deterministic string of at least 128 bits that an entity with knowledge of the secret mailbox access key and URL authorization mechanism can use to verify the URL.
許可トークンは、秘密のメールボックスアクセスキーとURL認可メカニズムの知識を持つエンティティはURLを確認するために使用することができ、少なくとも128ビットの決定論的文字列です。
[IMAPURL] is extended by allowing the addition of ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP URLs that refer to a specific message or message parts.
【IMAPURL]の添加を可能にすることによって拡張される「; EXPIRE = <日時>」と「; URLAUTH = <アクセス>：<メック>：<トークン>」は、特定のメッセージまたはメッセージ部分を指すIMAPするためのURL。
The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and MUST be at the end of the URL.
「; <トークン>：<メカ> <アクセス> URLAUTH =」とURLの末尾でなければならないURLAUTHが構成されています。
URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL that refers to an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
URLAUTHはには適用されません、全体IMAPサーバ、メールボックスの一覧、全体のIMAPメールボックス、またはIMAPの検索結果を参照する任意のIMAPのURLと共に使用してはいけません。
When ";EXPIRE=<datetime>" is used, this indicates the latest date and time that the URL is valid. After that date and time, the URL has expired, and server implementations MUST reject the URL. If ";EXPIRE=<datetime>" is not used, the URL has no expiration, but still can be revoked as discussed below.
ときに「; = <日時>がEXPIRE」が使用され、これは、URLが有効で最新の日付と時刻を示しています。その日付と時刻の後、URLの有効期限が切れている、とサーバーの実装は、URLを拒絶しなければなりません。もし「; EXPIRE = <日時>」使用されていない、URLには有効期限がありませんが、以下に説明するように、まだ取り消すことができます。
The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>". It is composed of three parts. The <access> portion provides the authorized access identifiers, which may constrain the operations and users that are permitted to use this URL. The <mech> portion provides the authorization mechanism used by the IMAP server to generate the authorization token that follows. The <token> portion provides the authorization token.
URLAUTHは形式をとる "; URLAUTH = <アクセス>：<メカ>：<トークン>"。これは、3つの部分で構成されています。 <アクセス>部分は、このURLを使用することが許可される操作とユーザを制限することができる許可されたアクセス識別子を、提供します。 <メカ>部分は、以下の認証トークンを生成するために、IMAPサーバによって使用される認証メカニズムを提供します。 <トークン>の部分は、認証トークンを提供します。
The "submit+" access identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. The IMAP server does not validate the specified userid but does validate that the IMAP session has an authorization identity that is authorized as a message submission entity. The authorized message submission entity MUST validate the userid prior to contacting the IMAP server.
ユーザーIDに続いて「提出+」アクセスIDプレフィックスは、指定されたユーザーIDの代わりにメッセージ送信エンティティとして認定のみユーザーIDは、このURLを使用することが許可されていることを示します。 IMAPサーバは、指定されたユーザーIDを検証しませんが、IMAPセッションがメッセージ送信エンティティとして認可された認可IDを持っていることを検証しません。認可メッセージ送信エンティティは、IMAPサーバーに接続する前にユーザーIDを検証する必要があります。
The "user+" access identifier prefix, followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid (that is, have authorization identity as that userid).
「ユーザー+」のユーザーIDに続いてアクセスIDプレフィックスは、このURLを使用すると、指定したユーザーID（つまり、そのユーザーIDとして認証アイデンティティを持っている）としてログインしているIMAPセッションに制限されていることを示しています。
Note: If a SASL mechanism that provides both authorization and authentication identifiers is used to authenticate to the IMAP server, the "user+" access identifier MUST match the authorization identifier.
注意：両方の許可および認証識別子を提供SASL機構はIMAPサーバへの認証に使用されている場合は、「ユーザー+」アクセス識別子は、認可識別子と一致しなければなりません。
The "authuser" access identifier indicates that use of this URL is limited to IMAP sessions that are logged in as an authorized user (that is, have authorization identity as an authorized user) of that IMAP server. Use of this URL is prohibited to anonymous IMAP sessions.
「AUTHUSER」アクセス識別子は、IMAPサーバーの（許可されたユーザとして認証アイデンティティを持っていることがある、）このURLの使用が許可されたユーザとしてログインしているIMAPセッションに制限されていることを示しています。このURLの使用は匿名のIMAPセッションに禁止されています。
The "anonymous" access identifier indicates that use of this URL is not restricted by session authorization identity; that is, any IMAP session in authenticated or selected state (as defined in [IMAP]), including anonymous sessions, may issue a URLFETCH using this URL.
「匿名」アクセス識別子は、このURLの使用は、セッション認可IDによって制限されていないことを示しています。つまり、匿名のセッションを含む（[IMAP]で定義されるように）、認証済みまたは選択された状態で任意のIMAPセッションは、このURLを使用してのURLfetchを発行することができます。
The authorization token is represented as an ASCII-encoded hexadecimal string, which is used to authorize the URL. The length and the calculation of the authorization token depends upon the mechanism used; but, in all cases, the authorization token is at least 128 bits (and therefore at least 32 hexadecimal digits).
許可トークンは、URLを認証するために使用されるASCIIエンコード進文字列として表されます。長さと許可トークンの計算が使用されるメカニズムに依存します。しかし、すべての場合において、許可トークンは、少なくとも128ビット（したがって、少なくとも32桁の16進数）です。
In [IMAPURL], the userid before the "@" in the URL has two purposes:
[IMAPURL]では、URLの「@」の前に、ユーザーIDは、2つの目的があります。
1) It provides context for user-specific mailbox paths such as "INBOX".
1）それは、「INBOX」などのユーザ固有のメールボックスのパスのためのコンテキストを提供します。
2) It specifies that resolution of the URL requires logging in as that user and limits use of that URL to only that user.
2）これは、URLの解像度は、そのユーザとそのユーザのみに制限するURLの使用をとしてログインする必要があることを指定します。
An obvious limitation of using the same field for both purposes is that the URL can only be resolved by the mailbox owner.
両方の目的のために同じフィールドを使用しての明らかな制限は、URLのみがメールボックスの所有者によって解決することができるということです。
URLAUTH overrides the second purpose of the userid in the IMAP URL and by default permits the URL to be resolved by any user permitted by the access identifier.
URLAUTHは、IMAPのURLで、デフォルトではユーザーIDの第二の目的は、アクセス識別子で許可され、任意のユーザーによって解決されるURLを許可する上書きされます。
The "user+<userid>" access identifier limits resolution of that URL to a particular userid, whereas the "submit+<userid>" access identifier is more general and simply requires that the session be authorized by a user that has been granted a "submit" role within the authentication system. Use of either of these access identifiers makes it impossible for an attacker, spying on the session, to use the same URL, either directly or by submission to a message submission entity.
「ユーザー+ <ユーザーID>」特定のユーザーIDにそのURLのアクセス識別子の限界解像度、「提出+ <ユーザID>」アクセス識別子は、より一般的であり、単にセッションは、「提出付与されたユーザーによって許可されている必要があり、一方、認証システム内での「役割。これらのアクセス識別子のいずれかの使用が直接またはメッセージ送信エンティティへの提出により、同じURLを使用するために、セッションをスパイ、攻撃者のためにそれを不可能にします。
The "authuser" and "anonymous" access identifiers do not have this level of protection and should be used with caution. These access identifiers are primarily useful for public export of data from an IMAP server, without requiring that it be copied to a web or anonymous FTP server. Refer to the Security Considerations for more details.
「AUTHUSER」と「匿名」アクセス識別子は、このレベルの保護を持っていないと注意して使用する必要があります。これらのアクセス識別子は、それがウェブまたは匿名FTPサーバにコピーされることを必要とせずに、IMAPサーバからのデータの公開輸出のために主に便利です。詳細については、セキュリティに関する考慮事項を参照してください。
A URLAUTH-authorized URL is generated from an initial URL as follows:
次のようにURLAUTH認可URLは、最初のURLから生成されます。
An initial URL is built, ending with ";URLAUTH=<access>" but without the ":<mech>:<token>" components. An authorization mechanism is selected and used to calculate the authorization token, with the initial URL as the data and a secret known to the IMAP server as the key. The URLAUTH-authorized URL is generated by taking the initial URL and appending ":", the URL authorization mechanism name, ":", and the ASCII-encoded hexadecimal representation of the authorization token.
コンポーネント "<トークン>：<メカ>" が、なし; "URLAUTH = <アクセス>" で終わる、URLが構築されている最初の。認証メカニズムが選択されたデータとキーとしてIMAPサーバに知られている秘密のように最初のURLと、認証トークンを計算するために使用されます。 「：」、URLの認可メカニズム名、「：」URLAUTH許可URLは、最初のURLを取得し、追加することにより生成され、認証トークンのASCIIでエンコードされた16進表現。
Note: ASCII-encoded hexadecimal is used instead of BASE64 because a BASE64 representation may have "=" padding characters, which would be problematic in a URL.
注：BASE64表現がURLで問題となる「=」パディング文字を有することができるので、ASCIIエンコード進代わりにBASE64で使用されています。
In the INTERNAL mechanism, the mailbox access key for that mailbox is the secret known to the IMAP server, and a server-selected algorithm is used as described in section 2.4.1.
内部機構では、そのメールボックスのメールボックスアクセスキーは、IMAPサーバに知られている秘密であり、セクション2.4.1に記載したように、サーバ選択アルゴリズムが使用されます。
A URLAUTH-authorized URL is validated as follows:
次のようにURLAUTH許可URLが検証されています。
The URL is split at the ":" that separates "<access>" from "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of the URL. The "<mech>:<token>" portion is first parsed and saved as the authorization mechanism and the authorization token. The URL is truncated, discarding the ":" described above, to create a "rump URL" (the URL minus the ":" and the "<mech>:<token>" portion). The rump URL is then analyzed to identify the mailbox.
"; <メカ>：<トークン> URLAUTH = <アクセス>" URLの部分に "：" それは分離 "<アクセス>" から "<トークン> <メカ>" URLがで分割されています。 「<メック>：<トークン>」の部分は、第1の解析され、認可機構と許可トークンとして保存されます。 URLは、廃棄、切り捨てられる「：」「尻URL」を作成するために、上述した（URLマイナス「：」および「<メック>：<トークン>」部分）。臀部のURLは、メールボックスを識別するために分析されます。
If the mailbox cannot be identified, an authorization token is calculated on the rump URL, using random "plausible" keys (selected by the server) as needed, before returning a validation failure. This prevents timing attacks aimed at identifying mailbox names.
メールボックスが特定できない場合は、許可トークンは、検証の失敗を返す前に、必要に応じて（サーバによって選択された）ランダム「もっともらしい」キーを使用して、臀部URLに基づいて計算されます。これは、メールボックス名を同定することを目的とした攻撃のタイミング防ぎます。
If the mailbox can be identified, the authorization token is calculated on the rump URL and a secret known to the IMAP server using the given URL authorization mechanism. Validation is successful if, and only if, the calculated authorization token for that mechanism matches the authorization token supplied in ";URLAUTH=<access>:<mech>:<token>".
メールボックスが特定できる場合は、許可トークンは、臀部のURLと指定したURLの認証メカニズムを使用してIMAPサーバに知られている秘密に基づいて計算されます。 、そのメカニズムの計算の認証トークンがで供給される許可トークンと一致する場合にのみ、検証は成功している「; <アクセス>をURLAUTH = <メカ>：<トークン>」。
Removal of the ":<mech>:<token>" portion of the URL MUST be the only operation applied to the URLAUTH-authorized URL to get the rump URL. In particular, URL percent escape decoding and case-folding (including to the domain part of the URL) MUST NOT occur.
除去「：<メカ>：<トークン>」URLの一部が動作のみが臀部URLを取得するにはURLAUTH許可URLに適用されなければなりません。具体的には、（URLのドメイン部分に含む）URLパーセントエスケープ復号とケース折りが発生してはいけません。
In the INTERNAL mechanism, the mailbox access key for that mailbox is used as the secret known to the IMAP server, and the same server-selected algorithm used for generating URLs is used to calculate the authorization token for verification.
内部機構では、そのメールボックスのメールボックスのアクセスキーは、IMAPサーバに知られている秘密として使用され、URLを生成するために使用したのと同じサーバ選択アルゴリズムは、検証のために認証トークンを計算するために使用されます。
These commands are extensions to the [IMAP] base protocol.
これらのコマンドは、[IMAP]ベースプロトコルの拡張機能です。
The section headings of these commands are intended to correspond with where they would be located in the base protocol document if they were part of that document.
これらのコマンドのセクションの見出しは、それらがその文書の一部であった場合、彼らはベースプロトコル文書に配置される場所に対応するように意図されています。
BASE.6.3.RESETKEY. RESETKEY Command
BASE.6.3.RESETKEY。 RESETKEYコマンド
Arguments: optional mailbox name optional mechanism name(s)
引数：オプションのメールボックス名、オプションのメカニズム名（複数可）
Responses: none other than in result
回答：結果の中にほかなりません
Result: OK - RESETKEY completed, URLMECH containing new data NO - RESETKEY error: can't change key of that mailbox BAD - command unknown or arguments invalid
結果：OF - 完成RESETKEY、URLMECHではなく、新しいデータを含む - KEYエラーをリセットします。そのメールボックスBADのキーを変更することはできません - 無効なコマンド不明または引数
The RESETKEY command has two forms.
RESETKEYコマンドは、2つの形式があります。
The first form accepts a mailbox name as an argument and generates a new mailbox access key for the given mailbox in the user's mailbox access key table, replacing any previous mailbox access key (and revoking any URLs that were authorized with a URLAUTH using that key) in that table. By default, the mailbox access key is generated for the INTERNAL mechanism; other mechanisms can be specified with the optional mechanism argument.
最初の形式は、引数として、メールボックス名を受け付け、ユーザのメールボックスへのアクセスキーテーブル内の指定されたメールボックスの新しいメールボックス・アクセス・キーを生成し、以前のメールボックスアクセス鍵を交換（およびその鍵を使用してURLAUTHで承認されたすべてのURLを取り消します）そのテーブルインチデフォルトでは、メールボックスのアクセスキーは内部機構のために生成されます。他の機構は、オプション機構の引数で指定することができます。
The second form, with no arguments, removes all mailbox access keys in the user's mailbox access key table, revoking all URLs currently authorized using URLAUTH by the user.
2番目の形式は、引数なしで、ユーザが現在URLAUTHを使用して、許可すべてのURLを取り消し、ユーザーのメールボックスにアクセスキーテーブル内のすべてのメールボックスのアクセスキーを削除します。
Any current IMAP session logged in as the user that has the mailbox selected will receive an untagged OK response with the URLMECH status response code (see section BASE.7.1.URLMECH for more details about the URLMECH status response code).
任意の現在のIMAPセッションがURLMECHステータス応答コード（URLMECHステータス応答コードに関する詳細については、セクションBASE.7.1.URLMECHを参照）タグなしOK応答を受信する選択したメールボックスを持つユーザとしてログイン。
Example:
例：
C: a31 RESETKEY S: a31 OK All keys removed C: a32 RESETKEY INBOX S: a32 OK [URLMECH INTERNAL] mechs C: a33 RESETKEY INBOX XSAMPLE S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
C：A31 RESETKEY S：A32 RESETKEY INBOX S：A32 OK [URLMECH INTERNAL]メックC：A33 RESETKEY INBOX XSAMPLE S：A33 OK [URLMECH INTERNAL XSAMPLE = P34OKhO7VEkCbsiYY8rGEgの==]完了A31 OKすべてのキーがCを除去しました
BASE.6.3.GENURLAUTH. GENURLAUTH Command
BASE.6.3.GENURLAUTH。 GENURLAUTHコマンド
Argument: one or more URL/mechanism pairs
引数：一つ以上のURL /メカニズムのペア
Response: untagged response: GENURLAUTH
回答：タグなし応答：GENURLAUTH
Result: OK - GENURLAUTH completed NO - GENURLAUTH error: can't generate a URLAUTH BAD - command unknown or arguments invalid
結果：URLAUTH BAD生成することはできません - 不明なコマンドまたは引数無効を：OK - GENURLAUTHエラー - GENURLAUTHが完了NO
The GENURLAUTH command requests that the server generate a URLAUTH-authorized URL for each of the given URLs using the given URL authorization mechanism.
サーバーは、指定されたURLの認証メカニズムを使用して、指定されたURLのそれぞれについてURLAUTH許可URLを生成GENURLAUTHのコマンド要求。
The server MUST validate each supplied URL as follows:
次のようにサーバがそれぞれ提供されたURLを検証しなければなりません：
(1) The mailbox component of the URL MUST refer to an existing mailbox.
（1）URLのメールボックスコンポーネントは、既存のメールボックスを参照しなければなりません。
(2) The server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH-authorized URL. As a consequence, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory.
（2）URLのサーバコンポーネントはURLAUTH許可URLを生成するために使用されるメールボックスアクセスキーテーブルの所有者を識別し、有効なユーザーIDを含まなければなりません。 iuserauthは必須であるように、結果として、[IMAPURL]のiserverルールが変更されます。
Note: the server component of the URL is generally the
logged in userid and server. If not, then the logged in
userid and server MUST have owner-type access to the
mailbox access key table owned by the userid and server
indicated by the server component of the URL.
(3) There is a valid access identifier that, in the case of "submit+" and "user+", will contain a valid userid. This userid is not necessarily the same as the owner userid described in (2).
（3）「提出」と「利用者」の場合には、有効なユーザーIDが含まれます、有効なアクセス識別子があります。このユーザIDは、必ずしも（2）に記載の所有者のユーザーIDと同じではありません。
(4) The server MAY also verify that the iuid and/or isection components (if present) are valid.
（4）サーバは、IUID及び/又はのISection成分（存在する場合）が有効であることを検証することができます。
If any of the above checks fail, the server MUST return a tagged BAD response with the following exception. If an invalid userid is supplied as the mailbox access key owner and/or as part of the access identifier, the server MAY issue a tagged OK response with a generated mailbox key that always fails validation when used with a URLFETCH command. This exception prevents an attacker from validating userids.
上記のチェックのいずれかが失敗した場合、サーバーは、以下の例外を除いてタグ付けされたBAD応答を返さなければなりません。無効なユーザーIDがメールボックスへのアクセスキーの所有者および/またはアクセス識別子の一部としてとして供給されている場合、サーバーはUrlFetchのコマンドで使用する場合、常に検証に失敗した生成されたメールボックスのキーでタグ付けされたOK応答を発行することができます。この例外は、検証のユーザーIDからの攻撃を防ぐことができます。
If there is currently no mailbox access key for the given mailbox in the owner's mailbox access key table, one is automatically generated. That is, it is not necessary to use RESETKEY prior to first-time use of GENURLAUTH.
現在、所有者のメールボックスへのアクセスキーテーブル内の指定されたメールボックスには、メールボックスのアクセスキーが存在しない場合は、1が自動的に生成されます。つまり、前GENURLAUTHを初めて使用するRESETKEYを使用する必要はありません。
If the command is successful, a GENURLAUTH response code is returned listing the requested URLs as URLAUTH-authorized URLs.
コマンドが成功した場合は、GENURLAUTH応答コードはURLAUTH許可URLとして要求されたURLをリストが返されます。
Examples:
例：
C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2" INTERNAL S: a775 BAD missing access identifier in supplied URL C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/ ;section=1.2;urlauth=submit+fred" INTERNAL S: a776 BAD missing owner username in supplied URL C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred" INTERNAL S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038" S: a777 OK GENURLAUTH completed
C：a775 GENURLAUTH "IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2、" INTERNAL S：a776 GENURLAUTH「IMAP：供給されたURLのCでa775 BAD欠落アクセス識別子//example.com /共有/; UID = 20 /;セクション= 1.2; urlauth =提出+フレッド "INTERNAL S：指定のURL Cにa776 BAD欠落所有者ユーザー名：A777 GENURLAUTH" IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2; urlauth =提出+フレッド "INTERNAL S：* GENURLAUTH" IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2; urlauth = +フレッド提出：内部：91354a473744909de610943775f92038を「S：A777 OK GENURLAUTHが完成しました
BASE.6.3.URLFETCH. URLFETCH Command
BASE.6.3.URLFETCH。 UrlFetchのコマンド
Argument: one or more URLs
引数：1つの以上のURL
Response: untagged response: URLFETCH
回答：タグなし応答：URLFetchの
Result: OK - urlfetch completed NO - urlfetch failed due to server internal error BAD - command unknown or arguments invalid
結果：OK - UrlFetchのはNOを完了 - UrlFetchに起因するサーバー内部エラーBADに失敗しました - 無効不明または引数コマンド
The URLFETCH command requests that the server return the text data associated with the specified IMAP URLs, as described in [IMAPURL] and extended by this document. The data is returned for all validated URLs, regardless of whether or not the session would otherwise be able to access the mailbox containing that data via SELECT or EXAMINE.
【IMAPURL]で説明し、この文書によって拡張ように、サーバは、指定されたIMAPのURLに関連付けられたテキストデータを返すのURLfetchコマンド要求。データは、そうでない場合はSELECTを介してデータまたは確認することを含むメールボックスにアクセスできるようになるかどうかにかかわらず、セッションの、すべての検証済みのURLのために返されます。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注意：このコマンドは、URLが選択されたメールボックスを参照することを必要としません。またそれは、任意のメールボックスを選択する必要がありません。また、どのような方法で任意の選択されたメールボックスを妨げることはありません。
The URLFETCH command effectively executes with the access of the userid in the server component of the URL (which is generally the userid that issued the GENURLAUTH). By itself, the URLAUTH does NOT grant access to the data; once validated, it grants whatever access to the data is held by the userid in the server component of the URL. That access may have changed since the GENURLAUTH was done.
UrlFetchのコマンドは、効果的に（一般的にGENURLAUTHを発行したユーザーIDである）URLのサーバーコンポーネントでのユーザーIDのアクセスを実行します。それ自体で、URLAUTHは、データへのアクセス権を付与するものではありません。一度検証し、それがデータへのアクセスは、URLのサーバーコンポーネントにユーザーIDによって保持されているものは何でも与えます。 GENURLAUTHが行われていたので、そのアクセスが変更されている可能性があります。
The URLFETCH command MUST return an untagged URLFETCH response and a tagged OK response to any URLFETCH command that is syntactically valid. A NO response indicates a server internal failure that may be resolved on later retry.
UrlFetchのコマンドは、タグなしのURLfetch応答と構文的に有効な任意のURLfetchコマンドへのタグ付きOK応答を返さなければなりません。 NO応答は、後で再試行で解決することができる、サーバ内部障害を示していません。
Note: The possibility of a NO response is to accommodate implementations that would otherwise have to issue an untagged BYE with a fatal error due to an inability to respond to a valid request. In an ideal world, a server SHOULD NOT issue a NO response.
注意：NO応答の可能性はそうでないため、有効な要求に応えることができないため、致命的なエラーとタグなしBYEを発行しなければならないの実装に対応するためにあります。理想的な世界では、サーバーはNO応答を発行するべきではありません。
The server MUST return NIL for any IMAP URL that references an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
サーバー全体IMAPサーバ、メールボックス、全体のIMAPメールボックス、またはIMAPの検索結果の一覧を参照するすべてのIMAP URLのNILを返さなければなりません。
Example:
例：
Note: For clarity, this example uses the LOGIN command, which SHOULD NOT be used over a non-encrypted communication path.
注：明確にするために、この例では、非暗号化通信経路上で使用されるべきではないloginコマンドを使用します。
This example is of a submit server, obtaining a message segment for a message that it has already validated was submitted by "fred".
この例では、すでに「フレッド」により提出された検証したメッセージのメッセージセグメントを取得し、提出するサーバーです。
S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server C: a001 LOGIN submitserver secret S: a001 OK submitserver logged in C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred:internal :91354a473744909de610943775f92038" S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 ;urlauth=submit+fred:internal :91354a473744909de610943775f92038" {28} S: Si vis pacem, para bellum. S: S: a002 OK URLFETCH completed
S：* OK [CAPABILITY IMAP4rev1のURLAUTH] example.com IMAPサーバC：A001 LOGINのsubmitserver秘密S：A001 CログインOK submitserver：A002のURLfetch「IMAP：//joe@example.com/INBOX/; UID = 20 /。セクション= 1.2; urlauth =提出+フレッド：内部：91354a473744909de610943775f92038" S *のURLfetch「IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2; urlauth = +提出フレッド：内部：91354a473744909de610943775f92038 "{28} S：汝平和を欲さば、パラbellum。 S：S：完成A002 OKのURLfetch
These responses are extensions to the [IMAP] base protocol.
これらの応答は、[IMAP]ベースプロトコルの拡張機能です。
The section headings of these responses are intended to correspond with where they would be located in the base protocol document if they were part of that document.
これらの応答のセクションの見出しは、それらがその文書の一部であった場合、彼らはベースプロトコル文書に配置される場所に対応するように意図されています。
BASE.7.1.URLMECH. URLMECH Status Response Code
BASE.7.1.URLMECH。 URLMECHステータス応答コード
The URLMECH status response code is followed by a list of URL authorization mechanism names. Mechanism names other than INTERNAL may be appended with an "=" and BASE64-encoded form of mechanism-specific data.
URLMECHステータス応答コードは、URLの承認メカニズム名のリストが続いています。 INTERNAL以外のメカニズム名は「=」機構固有のデータのBase64で符号化された形式で添付されてもよいです。
This status response code is returned in an untagged OK response in response to a RESETKEY, SELECT, or EXAMINE command. In the case of the RESETKEY command, this status response code can be sent in the tagged OK response instead of requiring a separate untagged OK response.
このステータス応答コードは、RESETKEYに応じて、タグなしOK応答で返さSELECT、またはコマンドを調べています。 RESETKEYコマンドの場合には、このステータス応答コードが代わりに別タグ無しOK応答を必要とするタグ付けされたOK応答で送信することができます。
Example:
例：
C: a33 RESETKEY INBOX XSAMPLE S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
C：A33 RESETKEY INBOX XSAMPLE S：A33 OK [URLMECH INTERNAL XSAMPLE = P34OKhO7VEkCbsiYY8rGEg ==]完了
In this example, the server supports the INTERNAL mechanism and an experimental mechanism called XSAMPLE, which also holds some mechanism-specific data (the name "XSAMPLE" is for illustrative purposes only).
この例では、サーバは、内部機構およびまた、いくつかの機構固有のデータを保持XSAMPLE呼ばれる実験的な機構をサポート（名称「XSAMPLE」は、例示の目的のみのためです）。
BASE.7.4.GENURLAUTH. GENURLAUTH Response
BASE.7.4.GENURLAUTH。 GENURLAUTHレスポンス
Contents: One or more URLs
内容量：1つの以上のURL
The GENURLAUTH response returns the URLAUTH-authorized URL(s) requested by a GENURLAUTH command.
GENURLAUTH応答はGENURLAUTHコマンドで要求URLAUTH認可URL（複数可）を返します。
Example:
例：
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred" INTERNAL S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 ;urlauth=submit+fred:internal:91354a473744909de610943775f92038" S: a777 OK GENURLAUTH completed
C：A777 GENURLAUTH "IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2; urlauth =提出+フレッド" INTERNAL S：* GENURLAUTH「IMAP：//joe@example.com/INBOX /;uid=20/;section=1.2; urlauth = +フレッドを提出：内部：91354a473744909de610943775f92038" S：完成A777 OK GENURLAUTH
BASE.7.4.URLFETCH. URLFETCH Response
BASE.7.4.URLFETCH。 UrlFetchのレスポンス
Contents: One or more URL/nstring pairs
内容量：1つのまたは複数のURL / nstringペア
The URLFETCH response returns the message text data associated with one or more IMAP URLs, as described in [IMAPURL] and extended by this document. This response occurs as the result of a URLFETCH command.
URLfetch応答は、このドキュメントによって[IMAPURL]に記載の拡張として、一つ以上のIMAPのURLに関連付けられたメッセージ・テキスト・データを返します。この応答はUrlFetchのコマンドの結果として起こります。
The returned data string is NIL if the URL is invalid for any reason (including validation failure). If the URL is valid, but the IMAP fetch of the body part returned NIL (this should not happen), the returned data string should be the empty string ("") and not NIL.
URLは（検証の失敗を含む）何らかの理由で無効である場合、返されるデータ列がNILです。 （これは起こるべきではありません）URLは有効ですが、IMAPは、身体の一部のフェッチNILを返した場合は、返されたデータ列が空の文字列（「」）ではなくNILでなければなりません。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注意：このコマンドは、URLが選択されたメールボックスを参照することを必要としません。またそれは、任意のメールボックスを選択する必要がありません。また、どのような方法で任意の選択されたメールボックスを妨げることはありません。
Example:
例：
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/ ;section=1.2;urlauth=submit+fred:internal :91354a473744909de610943775f92038" S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2 ;urlauth=submit+fred:internal :91354a473744909de610943775f92038" {28} S: Si vis pacem, para bellum. S: S: a002 OK URLFETCH completed
C：A002のURLfetch "IMAP：//joe@example.com/INBOX/; UID = 20 /;セクション= 1.2; urlauth =提出+フレッド：内部：91354a473744909de610943775f92038" S：* URLFetchの「IMAP例：@ //ジョー。 COM / INBOX /; UID = 20 /;セクション= 1.2; urlauth =提出+フレッド：内部：91354a473744909de610943775f92038" {28} S：汝平和を欲さば、パラbellum。 S：S：完成A002 OKのURLfetch
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下の構文仕様は、[ABNF]で指定された拡張バッカス・ナウアフォーム（ABNF）の表記を使用します。
The following modifications are made to the Formal Syntax in [IMAP]:
以下の変更は、[IMAP]で正式な構文になされます。
resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
resetkey = "RESETKEY" [SPメールボックス*（SP機構）]
capability =/ "URLAUTH"
機能= / "URLAUTH"
command-auth =/ resetkey / genurlauth / urlfetch
コマンド-AUTH = / resetkey / genurlauth / UrlFetchの
resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
RESPテキストコード= / "URLMECH" SP "内部" *（SP機構[ "=" BASE64]）
genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism)
genurlauth = "GENURLAUTH" 1 *（SP-URL臀部のSPメカニズム）
genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full) url-full = astring ; contains authimapurlfull as defined below
genurlauthデータ= "*" SP "GENURLAUTH" 1 *（SPのurl-フル）のurl-フル=のAString。以下に定義するauthimapurlfull含まれてい
url-rump = astring ; contains authimapurlrump as defined below
URL-臀部=のAString。以下に定義するauthimapurlrump含まれてい
urlfetch = "URLFETCH" 1*(SP url-full)
UrlFetchの= "URLFetchの" 1 *（SP URLフル）
urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
UrlFetchのデータ= "*" SP "のURLfetch" 1 *（SPのURLフルSPのnstring）
The following extensions are made to the Formal Syntax in [IMAPURL]:
次の拡張子は[IMAPURL]で正式な構文に作られています：
authimapurl = "imap://" enc-user [iauth] "@" hostport "/" imessagepart ; replaces "imapurl" and "iserver" rules for ; URLAUTH authorized URLs
authimapurl = "IMAP：//" ENC-ユーザー[iauth] "@" ホスト側 "/" imessagepart。 「imapurl」とは「iserver」のルールを置き換えます。 URLAUTH許可するURL
authimapurlfull = authimapurl iurlauth
afthimapyrlfyll = afthimapyrl ivrlafti
authimapurlrump = authimapurl iurlauth-rump
afthimapyrlromp = afthimapyrl ivrlafti、ロブ
enc-urlauth = 32*HEXDIG
ENC-urlauth = 32 * HEXDIG
enc-user = 1*achar ; same as "enc_user" in RFC 2192
ENC-ユーザー= 1 *のACHAR。 RFC 2192で「enc_user」と同じ
iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
iurlauth = iurlauth-尻 "：" 仕組み "：" ENC-urlauth
iurlauth-rump = [expire] ";URLAUTH=" access
臀部-iurlauth = [有効期限が切れる] "; URLAUTH =" アクセス
access = ("submit+" enc-user) / ("user+" enc-user) / "authuser" / "anonymous"
アクセス=（ "+提出する" ENC-ユーザー）/（ "ユーザー+" ENC-ユーザー）/ "AUTHUSER" / "匿名"
expire = ";EXPIRE=" date-time ; date-time defined in [DATETIME]
=有効期限が切れ "; = EXPIRE" 日時を。 [DATETIME]で定義された日時
mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".") ; case-insensitive ; new mechanisms MUST be registered with IANA
メカニズム= "内部" / 1 *（ALPHA / DIGIT / " - " / ""）;大文字小文字を区別しません ;新しいメカニズムは、IANAに登録しなければなりません
Security considerations are discussed throughout this memo.
セキュリティの考慮事項は、このメモ中で議論されています。
The mailbox access key SHOULD have at least 128 bits of entropy (refer to [RANDOM] for more details) and MUST be unpredictable.
メールボックスアクセスキーは、エントロピー（詳細については[ランダム]を参照）の少なくとも128ビットを有するべきであり、予測不可能でなければなりません。
The server implementation of the INTERNAL mechanism SHOULD consider the possibility of needing to change the token generation algorithm, and SHOULD incorporate some means of identifying the token generation algorithm within the token.
内部機構のサーバの実装は、トークン生成アルゴリズムを変更する必要の可能性を考慮すべきであり、トークン内のトークン生成アルゴリズムを識別する何らかの手段を組み込むべきです。
The URLMECH status response code may expose sensitive data in the mechanism-specific data for mechanisms other than INTERNAL. A server implementation MUST implement a configuration that will not return a URLMECH status response code unless some mechanism is provided that protects the session from snooping, such as a TLS or SASL security layer that provides confidentiality protection.
URLMECHステータス応答コードは、内部以外のメカニズムのための機構固有データ内の機密データを公開してもよいです。サーバーの実装は、いくつかのメカニズムは、そのような機密性保護を提供TLSやSASLセキュリティ層として、スヌーピングからセッションを保護が提供されていない限り、URLMECHステータス応答コードを返さない構成を実装しなければなりません。
The calculation of an authorization token with a "plausible" key if the mailbox can not be identified is necessary to avoid attacks in which the server is probed to see if a particular mailbox exists on the server by measuring the amount of time taken to reject a known bad name versus some other name.
メールボックスが特定できない場合は、「もっともらしい」キーで認証トークンの計算は、特定のメールボックスが拒否するのにかかる時間の量を測定することにより、サーバー上に存在するかどうかを確認するために、サーバーがプローブされる攻撃を回避する必要があります他のいくつかの名前対既知の不正な名前。
To protect against a computational denial-of-service attack, a server MAY impose progressively longer delays on multiple URL requests that fail validation.
計算サービス拒否攻撃から保護するために、サーバーは徐々に長く検証に失敗し、複数のURL要求の遅延を課すことができます。
The decision to use the "authuser" access identifier should be made with caution. An "authuser" access identifier can be used by any authorized user of the IMAP server; therefore, use of this access identifier should be limited to content that may be disclosed to any authorized user of the IMAP server.
「AUTHUSER」アクセス識別子を使用するという決定は慎重になされるべきです。 「AUTHUSER」アクセス識別子はIMAPサーバの任意の許可されたユーザによって使用することができます。したがって、このアクセス識別子の使用は、IMAPサーバの任意の許可されたユーザに公開することができるコンテンツに限定されるべきです。
The decision to use the "anonymous" access identifier should be made with extreme caution. An "anonymous" access identifier can be used by anyone; therefore, use of this access identifier should be limited to content that may be disclosed to anyone. Many IMAP servers do not permit anonymous access; in this case, the "anonymous" access identifier is equivalent to "authuser", but this MUST NOT be relied upon.
「匿名」アクセス識別子を使用するという決定は、細心の注意を払って行ってください。 「匿名」アクセス識別子は、誰でも使用することができます。したがって、このアクセス識別子を使用することは、誰にも開示されていることができる内容に限定されるべきです。多くのIMAPサーバは、匿名アクセスを許可していません。この場合には、「匿名」アクセス識別子は、「AUTHUSER」と同等ですが、これは当てにしてはなりません。
Although this specification does not prohibit the theoretical capability to generate a URL with a server component other than the logged in userid and server, this capability should only be provided when the logged in userid/server has been authorized as equivalent to the server component userid/server, or otherwise has access to that userid/server mailbox access key table.
この仕様は、ユーザーIDとサーバにログイン以外のサーバー・コンポーネントとURLを生成するための理論的な機能を禁止するものではありませんが、この機能はユーザーIDでログインしたときに/サーバは、サーバコンポーネントのユーザーIDに相当するものとして許可された提供されなければなりません/そうでない場合は、サーバー、またはそのユーザーID /サーバーメールボックスへのアクセスキーテーブルへのアクセス権を持っています。
This document constitutes registration of the URLAUTH capability in the imap4-capabilities registry.
この文書は、IMAP4、能力のレジストリにURLAUTH機能の登録を構成しています。
URLAUTH authorization mechanisms are registered by publishing a standards track or IESG-approved experimental RFC. The registry is currently located at:
URLAUTHの承認メカニズムは、標準トラックまたはIESGが承認した実験的RFCを公開することにより、登録されています。レジストリは、現在の場所にあります。
http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／うｒぁうｔｈーあうてょりざちおんーめちゃにｓｍーれぎｓｔｒｙ
This registry is case-insensitive.
このレジストリは、大文字と小文字を区別しません。
This document constitutes registration of the INTERNAL URLAUTH authorization mechanism.
このドキュメントは、内部URLAUTH認証機構の登録を構成しています。
IMAP URLAUTH Authorization Mechanism Registry
IMAP URLAUTH認証メカニズムレジストリ
Mechanism Name Reference
-------------- ---------
INTERNAL [RFC4467]
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]ニューマン、C.、 "メッセージ提出BURL拡張"、RFC 4468、2006年5月。
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[DATETIME] Klyne、G.とC.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年7月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAPURL]ニューマン、C.、 "IMAP URLスキーム"、RFC 2192、1997年9月。
[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月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
Author's Address
著者のアドレス
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
マーク・R.クリスピン・ネットワークとワシントン4545の分散コンピューティング大学第15回アベニューNEシアトル、WA 98105から4527
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
電話：（206）543-5762 Eメール：MRC@CAC.Washington.EDU
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。