[要約] RFC 2384は、POP URLスキームの仕様を定義しており、POP3サーバーへのアクセスを簡単にするための方法を提供しています。このRFCの目的は、POP3プロトコルを使用して電子メールを取得するための統一された方法を提供することです。
Network Working Group R. Gellens
Request for Comments: 2384 QUALCOMM, Incorporated
Category: Standards Track August 1998
POP URL Scheme
POP URLスキーム
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
[POP3] is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient.
[POP3]は広く展開されているメールアクセスプロトコルです。多くのプログラムはPOP3メッセージストアにアクセスするため、POP3構成情報が必要です。メールボックスにアクセスするために必要な複数の構成要素があるため、単一の文字列表現が便利です。
A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources.
POP3メールボックス（[IMAP4]メールボックスなど）はネットワークリソースであり、URLはネットワークリソースの広くサポートされている一般化された表現です。
A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. [ACAP] is one case where a string encapsulation of elements required to access network services is needed. For example, an [IMAP4] message store is usually specified in ACAP datasets as an [IMAP-URL].
POP3メールボックスをURLとして指定する方法は、多くのプログラムやプロトコルで役立つ可能性があります。 [ACAP]は、ネットワークサービスへのアクセスに必要な要素の文字列カプセル化が必要な場合の1つです。たとえば、[IMAP4]メッセージストアは通常、ACAPデータセットで[IMAP-URL]として指定されます。
This memo defines a URL scheme for referencing a POP mailbox.
このメモは、POPメールボックスを参照するためのURLスキームを定義します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、「要件レベルを示すRFCで使用するキーワード」[キーワード]で定義されているように解釈されます。 。
The POP URL scheme designates a POP server, and optionally a port number, authentication mechanism, authentication ID, and/or authorization ID.
POP URLスキームは、POPサーバーを指定し、オプションでポート番号、認証メカニズム、認証ID、認証IDを指定します。
The POP URL follows the common Internet scheme syntax as defined in RFC 1738 [BASIC-URL] except that clear text passwords are not permitted. If :<port> is omitted, the port defaults to 110.
POP URLは、クリアテキストパスワードが許可されていないことを除いて、RFC 1738 [BASIC-URL]で定義されている一般的なインターネットスキーム構文に従います。 ：<port>を省略した場合、ポートのデフォルトは110です。
The POP URL is described using [ABNF] in Section 8.
POP URLについては、セクション8で[ABNF]を使用して説明しています。
A POP URL is of the general form:
POP URLは一般的な形式です。
pop://<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in RFC 1738, and some or all of the elements, except "pop://" and <host>, may be omitted.
<user>、<host>、および<port>はRFC 1738で定義されているとおりであり、「pop：//」と<host>を除く一部またはすべての要素は省略できます。
An authorization (which mailbox to access) and authentication (whose password to check against) identity (referred to as "user name" for simplicity) and/or authentication mechanism name may be supplied. These are used in a "USER", "APOP", "AUTH" [POP-AUTH], or extension command after making the connection to the POP server. If the URL doesn't supply an authentication identifier, the program interpreting the POP URL SHOULD request one from the user.
承認（どのメールボックスにアクセスするか）および認証（パスワードをチェックするかどうか）の識別情報（簡単にするために「ユーザー名」と呼びます）および/または認証メカニズム名を指定できます。これらは、POPサーバーに接続した後、「USER」、「APOP」、「AUTH」[POP-AUTH]、または拡張コマンドで使用されます。 URLが認証識別子を提供しない場合、POP URLを解釈するプログラムはユーザーからの識別子を要求する必要があります（SHOULD）。
An authentication mechanism can be expressed by adding ";AUTH=<enc-auth-type>" to the end of the user name. If the authentication mechanism name is not preceded by a "+", it is a SASL POP [SASL] mechanism. If it is preceded by a "+", it is either "APOP" or an extension mechanism.
認証メカニズムは、ユーザー名の末尾に「; AUTH = <enc-auth-type>」を追加することで表現できます。認証メカニズム名の前に「+」がない場合、それはSASL POP [SASL]メカニズムです。 「+」が前に付いている場合は、「APOP」または拡張メカニズムです。
When an <enc-auth-type> is specified, the client SHOULD request appropriate credentials from that mechanism and use the "AUTH", "APOP", or extension command instead of the "USER" command. If no user name is specified, one SHOULD be obtained from the mechanism or requested from the user as appropriate.
<enc-auth-type>が指定されている場合、クライアントはそのメカニズムに適切な資格情報を要求し、「USER」コマンドの代わりに「AUTH」、「APOP」、または拡張コマンドを使用する必要があります（SHOULD）。ユーザー名が指定されていない場合、必要に応じて、メカニズムから1つを取得するか、ユーザーから要求する必要があります。
The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism. It MAY use any mechanism supported by the POP server.
文字列「; AUTH = *」は、クライアントが適切な認証メカニズムを選択する必要があることを示します。 POPサーバーでサポートされているメカニズムを使用できます。
If an <enc-auth-type> other than ";AUTH=*" is specified, the client SHOULD NOT use a different mechanism without explicit user permission.
"; AUTH = *"以外の<enc-auth-type>が指定されている場合、クライアントはユーザーの明示的な許可なしに別のメカニズムを使用してはなりません（SHOULD NOT）。
If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed.
ユーザー名が認証メカニズムなしで含まれている場合、「; AUTH = *」が想定されます。
Since URLs can easily come from untrusted sources, care must be taken when resolving a URL which requires or requests any sort of authentication. If authentication credentials are supplied to the wrong server, it may compromise the security of the user's account. The program resolving the URL should make sure it meets at least one of the following criteria in this case:
URLは信頼できないソースから簡単に取得できるため、何らかの認証が必要または要求されるURLを解決する場合は注意が必要です。認証資格情報が間違ったサーバーに提供されると、ユーザーのアカウントのセキュリティが低下する可能性があります。この場合、URLを解決するプログラムは、次の基準の少なくとも1つを満たしていることを確認する必要があります。
(1) The URL comes from a trusted source, such as a referral server which the client has validated and trusts according to site policy. Note that user entry of the URL may or may not count as a trusted source, depending on the experience level of the user and site policy.
（1）URLは、クライアントが検証し、サイトのポリシーに従って信頼する参照サーバーなどの信頼できるソースからのものです。 URLのユーザーエントリは、ユーザーのエクスペリエンスレベルとサイトポリシーに応じて、信頼できるソースとしてカウントされる場合とカウントされない場合があります。
(2) Explicit local site policy permits the client to connect to the server in the URL. For example, if the client knows the site domain name, site policy may dictate that any hostname ending in that domain is trusted.
（2）明示的なローカルサイトポリシーにより、クライアントはURLでサーバーに接続できます。たとえば、クライアントがサイトのドメイン名を知っている場合、サイトのポリシーにより、そのドメインで終わるすべてのホスト名を信頼するように指示できます。
(3) The user confirms that connecting to that domain name with the specified credentials and/or mechanism is permitted.
（3）ユーザーは、指定された資格情報やメカニズムを使用してそのドメイン名への接続が許可されていることを確認します。
(4) A mechanism is used which validates the server before passing potentially compromising client credentials.
（4）侵害の可能性のあるクライアント資格情報を渡す前にサーバーを検証するメカニズムが使用されます。
(5) An authentication mechanism is used which will not reveal information to the server which could be used to compromise future connections.
（5）将来の接続を危険にさらすために使用される可能性のある情報をサーバーに明らかにしない認証メカニズムが使用されます。
A URL containing ";AUTH=*" should be treated with extra care since it might fall back on a weaker security mechanism. Finally, clients are discouraged from using a plain text password as a fallback with ";AUTH=*" unless the connection has strong encryption (e.g., a key length of greater than 56 bits).
「; AUTH = *」を含むURLは、より弱いセキュリティメカニズムにフォールバックする可能性があるため、細心の注意を払って処理する必要があります。最後に、接続に強力な暗号化（56ビットを超えるキーの長さなど）がない限り、クライアントは、「; AUTH = *」を使用したフォールバックとしてプレーンテキストのパスワードを使用しないでください。
Note that if unsafe or reserved characters such as " " or ";" are present in the user name or authentication mechanism, they MUST be encoded as described in RFC 1738 [BASIC-URL].
「」や「;」などの安全でない文字や予約文字がある場合は注意してください。ユーザー名または認証メカニズムに存在する場合は、RFC 1738 [BASIC-URL]で説明されているようにエンコードする必要があります。
Relative POP URLs are not permitted.
相対POP URLは許可されていません。
Since 8-bit characters are not permitted in URLs, [UTF8] characters are encoded as required by the URL specification [BASIC-URL].
8ビット文字はURLで許可されていないため、[UTF8]文字は、URL仕様[BASIC-URL]の要求に従ってエンコードされます。
The following examples demonstrate how a POP client program might translate various POP URLs into a series of POP commands. Commands sent from the client to the server are prefixed with "C:", and responses sent from the server to the client are prefixed with "S:".
次の例は、POPクライアントプログラムがさまざまなPOP URLを一連のPOPコマンドに変換する方法を示しています。クライアントからサーバーに送信されるコマンドには「C：」のプレフィックスが付き、サーバーからクライアントに送信される応答には「S：」のプレフィックスが付きます。
The URL:
URL：
<pop://rg@mailsrv.qualcomm.com>
Results in the following client commands:
次のクライアントコマンドが生成されます。
<request password from user>
<connect to mailsrv.qualcomm.com, port 110>
S: +OK POP3 server ready <1896.697170952@mailsrv.qualcomm.com>
C: USER rg
S: +OK
C: PASS secret
S: +OK rg's mailbox has 2 messages (320 octets)
The URL:
URL：
<pop://rg;AUTH=+APOP@mail.eudora.com:8110>
Results in the following client commands:
次のクライアントコマンドが生成されます。
<client requests password from user>
<connect to mail.eudora.com, port 8110>
S: +OK POP3 server ready <1896.697170952@mail.eudora.com>
C: APOP rg c4c9334bac560ecc979e58001b3e22fb
S: +OK mailbox has 1 message (369 octets)
The URL:
URL：
<pop://baz;AUTH=SCRAM-MD5@foo.bar>
Results in the following client commands:
次のクライアントコマンドが生成されます。
<connect to foo.bar, port 110>
<foo.bar、ポート110に接続>
S: +OK POP3 server ready <1896.697170952@foo.bar>
C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
Fub3IuaW5ub3NvZnQuY29tPg==
S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq
aGNOWmxSdVBiemlGcCt2TFYrTkN3
C: AQAAAMg9jU8CeB4KOfk7sUhSQPs=
S: + U0odqYw3B7XIIW0oSz65OQ==
C:
S: +OK mailbox has 1 message (369 octets)
The POP URL scheme is described using [ABNF]:
POP URLスキームは、[ABNF]を使用して記述されます。
achar = uchar / "&" / "=" / "~"
; see [BASIC-URL] for "uchar" definition
auth = ";AUTH=" ( "*" / enc-auth-type )
enc-auth-type = enc-sasl / enc-ext
enc-ext = "+" ("APOP" / 1*achar)
;APOP or encoded extension mechanism name
enc-sasl = 1*achar
;encoded version of [SASL] "auth_type"
enc-user = 1*achar
;encoded version of [POP3] mailbox
pop-url = "pop://" server
server = [user-auth "@"] hostport
;See [BASIC-URL] for "hostport" definition
user-auth = enc-user [auth]
user-auth = enc-user [auth]
Security considerations discussed in the [POP3] specification and the [BASIC-URL] specification are relevant. Security considerations related to authenticated URLs are discussed in section 4 of this document.
[POP3]仕様と[BASIC-URL]仕様で説明されているセキュリティの考慮事項が関連します。認証済みURLに関連するセキュリティの考慮事項は、このドキュメントのセクション4で説明されています。
Many email clients store the plain text password for later use after logging into a POP server. Such clients MUST NOT use a stored password in response to a POP URL without explicit permission from the user to supply that password to the specified host name.
多くの電子メールクライアントは、POPサーバーにログインした後で使用するためにプレーンテキストのパスワードを保存します。そのようなクライアントは、指定されたホスト名にそのパスワードを提供するユーザーからの明示的な許可なしに、POP URLに応答して保存されたパスワードを使用してはなりません（MUST NOT）。
This document borrows heavily from Chris Newman's [IMAP-URL] specification, and has attempted to follow the advice in [URL-GUIDELINES].
このドキュメントは、Chris Newmanの[IMAP-URL]仕様を大いに取り入れており、[URL-GUIDELINES]のアドバイスに従うことを試みました。
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[ACAP] Newman, C., and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]ニューマン、C。、およびJ.マイヤーズ、「ACAP-Application Configuration Access Protocol」、RFC 2244、1997年11月。
[BASIC-URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[BASIC-URL] Berners-Lee、T.、Masinter、L。、およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAP-URL]ニューマン、C。、「IMAP URLスキーム」、RFC 2192、1997年9月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]マイヤーズJ。、「POP3 AUTHentication command」、RFC 1734、1994年12月。
[POP3] Myers, J., and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J。、およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、May 1996。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new URL Schemes", Work in Progress.
[URLガイドライン] Masinter、Alvestrand、Zigmond、「新しいURLスキームのガイドライン」、作業中。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
Randall Gellens QUALCOMM, Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A.
Randall Gellens QUALCOMM、Incorporated 6455 Lusk Blvd. San Diego、CA 92121-2779 U.S.A.
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。