RFC4467 日本語訳

Network Working Group                                         M. Crispin
Request for Comments: 4467                      University of Washington
Updates: 3501                                                   May 2006
Category: Standards Track

コメントを求めるワーキンググループM.クリスピン要求をネットワークでつないでください: 4467のワシントン大学アップデート: 3501 2006年5月のカテゴリ: 標準化過程

      Internet Message Access Protocol (IMAP) - URLAUTH Extension

インターネットメッセージアクセス・プロトコル(IMAP)--URLAUTH拡張子

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 Internet Society (2006).

Copyright(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.

このドキュメントはインターネットMessage Accessプロトコル(IMAP)(RFC3501)とIMAP URL Scheme(IMAPURL)(RFC2192)にURLAUTH拡張子について説明します。 この拡大はIMAPクライアントがIMAPサーバに関する限られたメッセージデータにアクセスするために承認を運びながらURLを使用できる手段を提供します。

   An IMAP server that supports this extension indicates this with a
   capability name of "URLAUTH".

この拡大をサポートするIMAPサーバは能力名"URLAUTH"でこれを示します。

1.  Introduction

1. 序論

   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の1つのURLで: //fred@example.com/INBOX/;uid =20はユーザID"fred"として承認を必要とします。 しかしながら、[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]).

IMAP URLが[IMAPURL]の認証だけメカニズムを置き換えるように、URLAUTH拡張子は承認メカニズムを定義します。 URLAUTHは、承認のアイデンティティ(また、[IMAP]でデフォルト名前空間を定義する)を伝えるためにURLストリング自体の承認を伝えて、[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

URLAUTH拡張子はIMAPサーバの認定ユーザがURLAUTHによって認可されたIMAP URLを作成できる手段を提供します。 URLAUTHの認可されたURLは承認(認証でない)をデータに伝えます。

Crispin                     Standards Track                     [Page 1]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[1ページ]RFC4467IMAP--URLAUTH拡大2006年5月

   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.

そのURLで、扱われます。 別のIMAPセッションのときに別の方法で承認を提供しないで認可しているユーザによって所有されていたいかなる他のデータ(URLで指定されたメールボックスの中の他のデータなどの)にもIMAPサーバに関する特定の内容にアクセスするのにこのURLを使用できます。

   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を使用できます、[BURL]で説明されるように、クライアント(限られたメモリか他のリソースがある)が前方にメッセージを提出するか、またはクライアントがそれをとって来る必要でない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を取り消す)を生成して、割り当てるよう要求できますが、それ自身の選ぶことのキーにメールボックスアクセスキーを設定できません。

1.1.  Conventions Used in this Document

1.1. このDocumentのコンベンションUsed

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in [KEYWORDS].

キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[キーワード]で定義されるように本書では解釈されることになっているべきです。

   The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation
   including the core rules defined in Appendix A of [ABNF].

正式な構文は[ABNF]のAppendix Aで定義されたコア規則を含むAugmented BN記法(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:」 ラベルが複数の系列に適用されて、そして、それらの系列の間のラインブレイクは、編集の明快だけためにあって、実際のプロトコル交換の一部ではありません。

Crispin                     Standards Track                     [Page 2]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[2ページ]RFC4467IMAP--URLAUTH拡大2006年5月

2.  Concepts

2. 概念

2.1.  URLAUTH

2.1. URLAUTH

   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によって扱われたデータにアクセスするために承認を伝える1つのURLの端で追加されたコンポーネントです。 それは認可されたアクセス識別子、承認メカニズム名、および承認トークンを含んでいます。 承認トークンはURL、認可されたアクセス識別子、承認メカニズム名、およびメールボックスアクセスキーから生成されます。

2.2.  Mailbox Access Key

2.2. メールボックスアクセスキー

   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人のユーザがそれぞれそのメールボックスのための異なったメールボックスアクセスキーを持っています、そして、また、シングルユーザーによってアクセスされた各メールボックスは異なったメールボックスアクセスキーを持っています。

2.3.  Authorized Access Identifier

2.3. 認可されたアクセス識別子

   The authorized access identifier restricts use of the URLAUTH
   authorized URL to certain users authorized on the server, as
   described in section 3.

認可されたアクセス識別子はURLAUTHの認可されたURLの使用をサーバで権限を与えられた確信しているユーザに制限します、セクション3で説明されるように。

2.4.  Authorization Mechanism

2.4. 承認メカニズム

   The authorization mechanism is the algorithm by which the URLAUTH is
   generated and subsequently verified, using the mailbox access key.

承認メカニズムはメールボックスアクセスキーを使用して、URLAUTHが生成されて、次に確かめられるアルゴリズムです。

2.4.1.  INTERNAL Authorization Mechanism

2.4.1. 内部の承認メカニズム

   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.

この仕様はINTERNALメカニズムを定義します。(それは、サーバの選ぶことのトークン世代アルゴリズムを使用して、メールボックスアクセスキーの公開にクライアントにかかわりません)。

      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]はお勧めです。

Crispin                     Standards Track                     [Page 3]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[3ページ]RFC4467IMAP--URLAUTH拡大2006年5月

      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".

INTERNALメカニズムのトークン世代アルゴリズムを変えるのが必要になるなら(例えば、現在のアルゴリズムに対する攻撃を発見してあるので)、すべての現在既存の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.

サーバ実装SHOULDはアルゴリズムを変える可能性を考えます。 いくつかの場合、トークン使用が新しいアルゴリズムであると新たに生成しましたが、新しいか古いアルゴリズムを使用する限定期間の時間トークンのために有効にすることができる道における、アルゴリズムの変化を実装するのは望ましいかもしれません。 その結果、サーバSHOULDはトークンの中でトークン世代アルゴリズムを特定するいくつかの手段を取り入れます。

   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.

他のメカニズムにおいて、この仕様は広げることができますが、なにも本書では定義されません。 メカニズム名自体に加えて、他のメカニズムには、そのメカニズムの定義に従って解釈されることであるメカニズム特有のデータがあるかもしれません。

2.5.  Authorization Token

2.5. 承認トークン

   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ビットの決定論的なストリングです。

3.  IMAP URL Extensions

3. IMAP URL拡張子

   [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.

URLAUTHは<アクセス>: <mech>: <トークン>と等しいです。「追加を許容[IMAPURL]が拡張されているすること」によって;、=<datetime>を吐き出してください 」、」、;、」 特定のメッセージかメッセージの部品を示すIMAP URLに。

   The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and
   MUST be at the end of the URL.

URLAUTHは<アクセス>: <mech>: <トークン>と等しいです。「URLAUTHは包括される」、;、」 URLの端にあるに違いありません。

   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.

「いつ」; =<datetime>を吐き出してくださいか、」、使用されていて、これはURLが有効であることの最新の日時を示します。 その日時以降、URLは期限が切れています、そして、サーバ実装はURLを拒絶しなければなりません。 =<datetime>を吐き出してください。「」、;、」 使用されないで、URLには満了が全くないということですが、以下で議論するようにまだ取り消すことができます。

Crispin                     Standards Track                     [Page 4]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[4ページ]RFC4467IMAP--URLAUTH拡大2006年5月

   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が<アクセス>: <mech>: <トークン>と等しい、」 それは3つの部品で構成されます。 <アクセス>部分は認可されたアクセス識別子を提供します。(識別子はこのURLを使用することが許可されている操作とユーザを抑制するかもしれません)。 <mech>部分は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だけがこのURLを使用することが許可されているのを示します。 IMAPサーバは、指定されたユーザIDを有効にしませんが、それを有効にします。IMAPセッションには、メッセージ服従実体として認可される承認のアイデンティティがあります。 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があとに続いた「ユーザ+」アクセス識別子接頭語は、この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"アクセス識別子は、このURLの使用がそのIMAPサーバの認定ユーザ(すなわち、認定ユーザとして承認のアイデンティティを持っている)としてログインされる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の使用がセッション承認のアイデンティティによって制限されないのを示します。 すなわち、匿名のセッションを含む認証されたか選択された州([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).

承認トークンはASCIIによってコード化された16進ストリングとして表されます。(それは、URLを認可するのに使用されます)。 承認トークンの長さと計算を使用されるメカニズムに依存します。 しかし、すべての場合では、承認トークンは少なくとも128ビット(そして、したがって、少なくとも32の16進数字)です。

Crispin                     Standards Track                     [Page 5]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[5ページ]RFC4467IMAP--URLAUTH拡大2006年5月

4.  Discussion of URLAUTH Authorization Issues

4. URLAUTH承認問題の議論

   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) それは「受信トレイ」などのユーザ特有のメールボックス経路に文脈を提供します。

      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の2番目の目的をくつがえして、デフォルトで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>」アクセス識別子はそのURLの解決を特定のユーザIDに制限します、「+ <ユーザ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"と「匿名」のアクセス識別子は、このレベルの保護を持たないで、慎重に使用されるべきです。 これらのアクセス識別子は主としてIMAPサーバからのデータの公共の輸出の役に立ちます、それがウェブか公開FTPサーバにコピーされる必要でない。その他の詳細についてSecurity Considerationsを参照してください。

5.  Generation of URLAUTH-Authorized URLs

5. URLAUTHによって認可されたURLの世代

   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.

」 : <は>: <トークン>をmechします。「終わって、初期のURLが組立している、」、;、URLAUTHが<アクセス>と等しい 」、」 コンポーネント。 承認メカニズムは、承認トークンについて計算するのに選択されて、使用されます、データとしての初期のURLとキーとしてIMAPサーバに知られている秘密で。 「URLAUTHによって認可されたURLは初期のURLと追加を取ることによって、生成される」:、」、URL承認メカニズム名、」、: 」 承認トークンのASCIIによってコード化された16進表現。

Crispin                     Standards Track                     [Page 6]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[6ページ]RFC4467IMAP--URLAUTH拡大2006年5月

      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によってコード化された16進は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.

INTERNALメカニズムでは、そのメールボックスのためのメールボックスアクセスキーはIMAPサーバに知られている秘密です、そして、サーバで選択されたアルゴリズムはセクション2.4.1で説明されるように使用されています。

6.  Validation of URLAUTH-authorized URLs

6. URLAUTHによって認可されたURLの合法化

   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.

「URLが分けられる、」、:、」 URLAUTHは<アクセス>: <mech>: <トークン>と等しいです。「それが「<mech>: <トークン>」と中に「<アクセス>」を切り離す、」、;、」 URLの一部。 「<mech>: <トークン>」部分は、承認メカニズムと承認トークンとして最初に、分析されて、節約されます。 「捨てて、URLが端が欠けている、」、:、」 「「臀部URL」を作成するために上で説明される、(URLマイナス、」 : 」 「<mech>: <トークン>」部分、) そして、臀部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承認メカニズムを使用することでIMAPサーバに知られている臀部URLと秘密で計算されます。 そのメカニズムのための計算された承認トークンは中に供給された承認トークンに合っています。「合法化がうまくいっている、唯一、」 ; URLAUTHは<アクセス>: <mech>と等しいです:、<トークン>、」

   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.

「取り外し、」 : <のmech>: 唯一の操作が臀部URLを得るURLAUTHによって認可されたURLに適用されていたなら」 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.

INTERNALメカニズムでは、そのメールボックスのためのメールボックスアクセスキーはIMAPサーバに知られている秘密として使用されます、そして、URLを生成するのに使用される同じサーバの選択されたアルゴリズムは、検証のために承認トークンについて計算するのに使用されます。

Crispin                     Standards Track                     [Page 7]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[7ページ]RFC4467IMAP--URLAUTH拡大2006年5月

7.  Additional Commands

7. 追加コマンド

   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

.6.3.RESETKEYを基礎づけてください。 RESETKEYコマンド

   Arguments:  optional mailbox name
               optional mechanism name(s)

議論: 任意のメールボックス名前任意のメカニズム名(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

結果: OK--完成したRESETKEY、新しいデータノーを含むURLMECH--RESETKEY誤り: そのメールボックス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も取り消して)も置き換えて。 デフォルトで、メールボックスアクセスキーはINTERNALメカニズムのために生成されます。 任意のメカニズム議論で他のメカニズムを指定できます。

   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).

メールボックスを選択させるユーザがURLMECH状態応答コードで非タグ付けをされたOK応答を受けるので(URLMECH状態応答コードに関するその他の詳細に関してセクション基地の.7.1.URLMECHを見てください)、どんな現在のIMAPセッションもログインされました。

   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: a31OK AllキーはCを取り除きました: a32 RESETKEY受信トレイS: a32OK[URLMECH INTERNAL]mechs C: a33 RESETKEY INBOX XSAMPLE S: 行われたa33OK[URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg=]

Crispin                     Standards Track                     [Page 8]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[8ページ]RFC4467IMAP--URLAUTH拡大2006年5月

BASE.6.3.GENURLAUTH.  GENURLAUTH Command

.6.3.GENURLAUTHを基礎づけてください。 GENURLAUTHコマンド

      Argument:   one or more URL/mechanism pairs

議論: 1URL/メカニズム組以上

      Response:   untagged response: GENURLAUTH

応答: 非タグ付けをされた応答: GENURLAUTH

      Result:     OK - GENURLAUTH completed
                  NO - GENURLAUTH error: can't generate a URLAUTH
                  BAD - command unknown or arguments invalid

結果: OK--GENURLAUTHの完成したノー--GENURLAUTH誤り: URLAUTH BADを生成することができません--未知か議論病人を命令してください。

   The GENURLAUTH command requests that the server generate a URLAUTH-
   authorized URL for each of the given URLs using the given URL
   authorization mechanism.

GENURLAUTHはサーバがそれぞれの与えられたURLのために与えられたURL承認メカニズムを使用することでURLAUTHの認可されたURLを生成するという要求を命令します。

   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を含まなければなりません。 結果として、[IMAPURL]のiserver規則が変更されているので、iuserauthは義務的です。

             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.

以下に注意してください。 一般に、URLのサーバ成分は、ログインされたユーザIDとサーバです。まして、次に、ログインされたユーザIDとサーバで、URLのサーバ成分によって示されたユーザIDとサーバはメールボックスアクセスキーテーブルへの所有者タイプアクセスを所有しなければなりません。

      (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は必ず所有者ユーザIDが(2)で説明したのと同じであるというわけではありません。

      (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を有効にすることができません。

Crispin                     Standards Track                     [Page 9]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[9ページ]RFC4467IMAP--URLAUTH拡大2006年5月

   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を区分してください」 供給されたURL Cのa775 BADのなくなったアクセス識別子: 「imap://example.com/Shared/; uid=20/; セクションは1.2と等しいです; urlauth=は+ fredを提出する」というa776 GENURLAUTH INTERNAL S: 供給されたURL Cのa776 BADのなくなった所有者ユーザ名: 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fredを提出する」というa777 GENURLAUTH INTERNAL S: * 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred:インターナル:91354a473744909de610943775f92038を提出する」というGENURLAUTH S: OK GENURLAUTHが完成したa777

BASE.6.3.URLFETCH.  URLFETCH Command

.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はいいえ--サーバ内部エラーBADのため失敗されたurlfetch--コマンド未知か議論病人を完成しました。

   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.

サーバがテキストデータを返すというURLFETCHコマンド要求は指定されたIMAP URLと交際しました、[IMAPURL]で説明されて、このドキュメントによって広げられるように。 すべての有効にされたURLのためにデータを返します、そうでなければ、セッションがSELECTかEXAMINEを通してそのデータを含むメールボックスにアクセスできるだろうかどうかにかかわらず。

      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が選択されたメールボックスについて言及するのを必要としません。 また、それは、どんなメールボックスも選択されるのを必要としません。 また、それは何らかの方法でどんな選択されたメールボックスも妨げません。

Crispin                     Standards Track                    [Page 10]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[10ページ]RFC4467IMAP--URLAUTH拡大2006年5月

   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.

事実上、コマンドがURL(一般に、GENURLAUTHを発行したユーザIDである)のサーバ成分における、ユーザIDのアクセスで実行するURLFETCH。 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コマンドへのuntagged URLFETCH応答とタグ付けをされたOK応答も返さなければなりません。 いいえ応答は後の再試行のときに決議されるかもしれないサーバの内部の失敗を示します。

      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.

以下に注意してください。 いいえ応答の可能性は別の方法で有効な要求に応じることができないことによる致命的な誤りでuntagged BYEを発行しなければならない実装を収容することです。 理想の世界、SHOULD NOTがいいえ応答を発行するサーバで。

   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 URLのための参照の全体のIMAPサーバ、メールボックスのリスト、全体のIMAPメールボックス、またはIMAPが捜すNILにも結果を返さなければなりません。

   Example:

例:

      Note: For clarity, this example uses the LOGIN command, which
      SHOULD NOT be used over a non-encrypted communication path.

以下に注意してください。 明快ために、この例はLOGINコマンドを使用して、どのSHOULD NOTが非暗号化通信経路の上で使用されますか?

      This example is of a submit server, obtaining a message segment
      for a message that it has already validated was submitted by
      "fred".

サーバを提出して、それが既に有効にしたメッセージのためのセグメントが"fred"によって提出されたというメッセージを得ながら、この例はaのものです。

      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: * [CAPABILITY IMAP4REV1 URLAUTH]example.com IMAPサーバCを承認してください: a001 LOGIN submitserver秘密S: a001OK submitserverはCにログインしました: 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred: 内部の:91354a473744909de610943775f92038を提出する」というa002 URLFETCH S: * 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred: インターナル:91354a473744909de610943775f92038を提出する」というURLFETCH28、S: Si vis pacem、パラbellum。 S: S: OK URLFETCHが完成したa002

Crispin                     Standards Track                    [Page 11]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[11ページ]RFC4467IMAP--URLAUTH拡大2006年5月

8.  Additional Responses

8. 追加応答

   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

.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.

URL承認メカニズム名のリストはURLMECH状態応答コードのあとに続いています。 「=」とBASE64によってコード化されたフォームのメカニズムの特定のデータと共にINTERNAL以外のメカニズム名を追加するかもしれません。

   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、SELECT、またはEXAMINEコマンドに対応してこの状態応答コードは非タグ付けをされたOK応答で返されます。 RESETKEYコマンド、別々の非タグ付けをされたOK応答を必要とすることの代わりにタグ付けをされたOK応答でコードを送ることができるこの状態応答の場合で。

   Example:

例:

      C: a33 RESETKEY INBOX XSAMPLE
      S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done

C: a33 RESETKEY INBOX XSAMPLE S: 行われたa33OK[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と呼ばれるINTERNALメカニズムと実験メカニズムをサポートします("XSAMPLE"という名前は説明に役立った目的だけのためのものです)。また、XSAMPLEはいくつかのメカニズム特有のデータを保持します。

BASE.7.4.GENURLAUTH.   GENURLAUTH Response

.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: 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fredを提出する」というa777 GENURLAUTH INTERNAL S: * 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred:インターナル:91354a473744909de610943775f92038を提出する」というGENURLAUTH S: OK GENURLAUTHが完成したa777

Crispin                     Standards Track                    [Page 12]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[12ページ]RFC4467IMAP--URLAUTH拡大2006年5月

BASE.7.4.URLFETCH.  URLFETCH Response

.7.4.URLFETCHを基礎づけてください。 URLFETCH応答

   Contents:   One or more URL/nstring pairs

コンテンツ: 1URL/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応答は1つ以上のIMAP URLに関連しているメッセージ・テキストデータを返します、[IMAPURL]で説明されて、このドキュメントによって広げられるように。 この応答は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を返すなら(これは起こるべきではありません)、返されたデータ列が空のストリングである、(「「)、そして、無くない、」

      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: 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred: 内部の:91354a473744909de610943775f92038を提出する」というa002 URLFETCH S: * 「imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred: インターナル:91354a473744909de610943775f92038を提出する」というURLFETCH28、S: Si vis pacem、パラbellum。 S: S: OK URLFETCHが完成したa002

9.  Formal Syntax

9. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

以下の構文仕様は[ABNF]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。

   The following modifications are made to the Formal Syntax in [IMAP]:

[IMAP]で以下の変更をFormal Syntaxにします:

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)

genurlauth-データは「*」SP"GENURLAUTH"1*と等しいです。(いっぱいなSP url)

Crispin                     Standards Track                    [Page 13]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[13ページ]RFC4467IMAP--URLAUTH拡大2006年5月

url-full        = astring
                     ; contains authimapurlfull as defined below

いっぱいな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]で以下の拡大をFormal Syntaxにします:

authimapurl     = "imap://" enc-user [iauth] "@" hostport "/"
                     imessagepart
                     ; replaces "imapurl" and "iserver" rules for
                     ; URLAUTH authorized URLs

「authimapurlは「imap://」enc-ユーザ[iauth]「@」 hostport」/と等しく」imessagepart。 "imapurl"と"iserver"規則を置き換えます。 URLAUTHはURLを認可しました。

authimapurlfull = authimapurl iurlauth

authimapurlfullはauthimapurl iurlauthと等しいです。

authimapurlrump = authimapurl iurlauth-rump

authimapurlrumpはauthimapurl iurlauth-臀部と等しいです。

enc-urlauth     = 32*HEXDIG

enc-urlauthは32*HEXDIGと等しいです。

enc-user        = 1*achar
                     ; same as "enc_user" in RFC 2192

enc-ユーザは1*acharと等しいです。 RFC2192の「enc_ユーザ」と同じこと

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]

」日付「=を吐き出してください」; 期限が切れる=時間。 中で定義された日付-時間[DATETIME]

mechanism       = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
                     ; case-insensitive
                     ; new mechanisms MUST be registered with IANA

「メカニズム=「インターナル」/1*、(アルファ/ケタ/「-」/、」、」、)、。 大文字と小文字を区別しない。 新しいメカニズムをIANAに登録しなければなりません。

Crispin                     Standards Track                    [Page 14]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[14ページ]RFC4467IMAP--URLAUTH拡大2006年5月

10.  Security Considerations

10. セキュリティ問題

   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.

メールボックスアクセスキーSHOULDはエントロピー(その他の詳細について言及します[RANDOM])の少なくとも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.

トークンの中でトークン世代アルゴリズムを特定するSHOULDが、トークン世代アルゴリズムを変えるのが必要である可能性であると考えて、SHOULDがいくつかの手段を組み込むINTERNALメカニズムのサーバ実装。

   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状態応答コードはINTERNAL以外のメカニズムのためのメカニズム特有のデータの極秘データを暴露するかもしれません。 何らかのメカニズムが実装しない場合サーバ実装がURLMECH状態応答コードを返さない構成を実装しなければならない、TLSや秘密性保護を提供するSASLセキュリティ層のように詮索するのからセッションを保護します。

   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"アクセス識別子を使用するという決定をするべきです。 IMAPサーバのどんな認定ユーザも"authuser"アクセス識別子を使用できます。 したがって、このアクセス識別子の使用は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

この仕様はログインされたユーザIDとサーバ以外のサーバコンポーネントでURLを生成する理論上の能力を禁止しませんが、この能力を提供するだけであるべきです。

Crispin                     Standards Track                    [Page 15]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[15ページ]RFC4467IMAP--URLAUTH拡大2006年5月

   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/サーバがサーバコンポーネントユーザID/サーバに同じくらい同等な状態で認可されたか、またはそうでなければ、そのユーザID/サーバメールボックスアクセスキーテーブルに近づく手段を持っているとき。

11.  IANA Considerations

11. IANA問題

   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

http://www.iana.org/assignments/urlauth-authorization-mechanism-registry

   This registry is case-insensitive.

この登録は大文字と小文字を区別しないです。

   This document constitutes registration of the INTERNAL URLAUTH
   authorization mechanism.

このドキュメントはINTERNAL URLAUTH承認メカニズムの登録を構成します。

   IMAP URLAUTH Authorization Mechanism Registry

IMAP URLAUTH承認メカニズム登録

      Mechanism Name           Reference
      --------------           ---------
      INTERNAL                 [RFC4467]

メカニズム名前参照-------------- --------- 内部[RFC4467]

Crispin                     Standards Track                    [Page 16]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[16ページ]RFC4467IMAP--URLAUTH拡大2006年5月

12.  Normative References

12. 引用規格

   [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。

   [BURL]     Newman, C., "Message Submission BURL Extension", RFC 4468,
              May 2006.

ニューマン、C.、「メッセージ服従節拡張子」という[節](RFC4468)は2006がそうするかもしれません。

   [DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, July 2002.

[DATETIME]Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。

   [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
              4rev1", RFC 3501, March 2003.

[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」

   [IMAPURL]  Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.

[IMAPURL] ニューマン、C.、「IMAP URL体系」、RFC2192、1997年9月。

   [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月。

13.  Informative References

13. 有益な参照

   [HMAC]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February
              1997.

[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、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.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。

Author's Address

作者のアドレス

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   4545 15th Avenue NE
   Seattle, WA  98105-4527

マークR.クリスピンネットワークと第15分散コンピューティングワシントン大学4545アベニューNeシアトル、ワシントン98105-4527

   Phone: (206) 543-5762
   EMail: MRC@CAC.Washington.EDU

以下に電話をしてください。 (206) 543-5762 メールしてください: MRC@CAC.Washington.EDU

Crispin                     Standards Track                    [Page 17]

RFC 4467                IMAP - URLAUTH Extension                May 2006

クリスピン標準化過程[17ページ]RFC4467IMAP--URLAUTH拡大2006年5月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントは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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Crispin                     Standards Track                    [Page 18]

クリスピン標準化過程[18ページ]