Network Working Group R. Gellens
Request for Comments: 2384 QUALCOMM, Incorporated
Category: Standards Track August 1998
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.
版权所有（C）互联网协会（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]是一种需要对访问网络服务所需的元素进行字符串封装的情况。例如，[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].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照“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>
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的程序应该向用户请求一个身份验证标识符。
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>时，客户端应该从该机制请求适当的凭据，并使用“auth”、“APOP”或extension命令而不是“USER”命令。如果未指定用户名，则应根据需要从机制中获取用户名或向用户请求用户名。
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>，则未经明确的用户许可，客户端不应使用其他机制。
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) 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，应格外小心，因为它可能依赖于较弱的安全机制。最后，不鼓励客户端使用纯文本密码作为带“AUTH=*”的备用密码，除非连接具有强加密（例如，密钥长度大于56位）。
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].
由于URL中不允许使用8位字符，[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:
网址：
<pop://rg@mailsrv.qualcomm.com>
<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)
<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:
网址：
<pop://rg;AUTH=+APOP@mail.eudora.com:8110>
<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)
<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:
网址：
<pop://baz;AUTH=SCRAM-MD5@foo.bar>
<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
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)
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
achar = uchar / "&" / "=" / "~"
; see [BASIC-URL] for "uchar" definition
auth = ";AUTH=" ( "*" / enc-auth-type )
auth = ";AUTH=" ( "*" / enc-auth-type )
enc-auth-type = enc-sasl / enc-ext
enc-auth-type = enc-sasl / enc-ext
enc-ext = "+" ("APOP" / 1*achar)
;APOP or encoded extension mechanism name
enc-ext = "+" ("APOP" / 1*achar)
;APOP or encoded extension mechanism name
enc-sasl = 1*achar
;encoded version of [SASL] "auth_type"
enc-sasl = 1*achar
;encoded version of [SASL] "auth_type"
enc-user = 1*achar
;encoded version of [POP3] mailbox
enc-user = 1*achar
;encoded version of [POP3] mailbox
pop-url = "pop://" server
pop-url = "pop://" server
server = [user-auth "@"] hostport
;See [BASIC-URL] for "hostport" definition
server = [user-auth "@"] hostport
;See [BASIC-URL] for "hostport" definition
user-auth = enc-user [auth]
用户认证=加密用户[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]规范中讨论的安全注意事项是相关的。本文档第4节讨论了与经过身份验证的URL相关的安全注意事项。
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，以将该密码提供给指定的主机名。
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]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，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，“统一资源定位器（URL）”，RFC 17381994年12月。
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAP-URL]纽曼，C.，“IMAP URL方案”，RFC 2192192191997年9月。
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC20601996年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认证命令”，RFC 17341994年12月。
[POP3] Myers, J., and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.
[POP3]迈尔斯，J.和M.罗斯，“邮局协议——第3版”，STD 53，RFC 1939，1996年5月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年10月。
[URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new URL Schemes", Work in Progress.
[URL-GUIDELINES]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高通公司，成立于卢斯克大道6455号。美国加利福尼亚州圣地亚哥92121-2779。
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
Phone: +1 619 651 5115
Fax: +1 619 651 5334
EMail: Randy@Qualcomm.Com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。