本备忘录状态
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
版权声明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
1.介绍

[POP3]是一种广泛应用的邮件传输协议.许多程序都要访问POP3消息存储设备,因此需要了解POP3的配置信息.为了访问一个信箱,需要有若干必须的配置单元,所以使用单精度型的字符串表示法是将会很方便.

一个POP3邮箱(像[IMAP4]邮箱一样)是一种网络资源,而URLs(全球资源定位)是一种被广泛支持的网络资源的通用的表示方法。

在很多程序和协议中，一些将一个POP3信箱指定作为一个URL的方法的是很有用的.[ACAP]就是是这样一个例子,在这里,必须要有一个对需要用来访问网络服务的单元的封装.比如,在ACAP数据集中,一个[IMAP4]消息存储设备通常被指定为一个[IMAP-URL].

这个备忘录为涉及到的POP信箱定义了一个URL方案.

2.在本文当中的一些约定.

在本文当中,要害字"必须","禁止","应该","不宜","可以"和在"确定了必要标准的RFCs(请求注解)中所使用的要害字"[KEYWordS]的解释相一致.

3.POP方案

POPURL方案指定了一个POP服务器,一个端口号,身份验证机制,身份验证帐号,以及/或者说是授权账号.

除了完全的文本口令显示不被答应以外，POPURL遵循定义在RFC1738[BASIC-URL]通用的Internet方案的文法.假如:<port(端口)>被省略,默认端口将会是110.

下面是一个POPURL通常的格式:

pop://<user>;auth=<auth>@<host>:<port>

其中,<user(用户)>,<host(主机)>和<port(端口)>被定义在RFC1738,并且除了"pop://"和<host>,剩下的单元可以被部分或者全部省略.

4.POP用户名与身份验证机制

下列元素也许要被提供:对某个信箱进行访问的授权,用口令来核对的身份验证(为了简明,这里仅涉及到用户名),以及验证机制名.在与POP服务器连接之后,这些将被用于"USER","APOP","AUTH(身份验证)"[POP-AUTH]或者扩展命令.假如URL并没有提供一个验证标识符,那么解释POPURL的程序'应该'从用户那里请求一个这样的标识符.

一个身份验证机制,能够通过增加";AUTH=<enc-auth-type>(已编码的身份验证类型)"到用户名末端而表述出来.假如验证机制名的前面没有一个"+",它就是一个SASLPOP[SALS]机制.假如验证机制明前面有一个"+",它要么就是"APOP",要么就是一个扩展机制.

当一个<enc-auth-type>被指定以后,客户端'应该'请求来自那个机制的合适的证书,并且使用"AUTH","APOP"或者扩展命令来替代"USER"命令.假如没有用户名被指定,'应该'从这个机制获取或者向用户请求一个合适的用户名.

字符串";AUTH=*"指示出客户端'应该'选择一个合适的身份验证机制,它'可以'是被POP服务器支持的任何机制.

假如一个不用同于"AUTH=*"<enc-auth-type>被指定,客户端"不宜"使用一种没有明确用户答应的不同机制.

假如一个用户名没有包括身份验证机制,那么将默认";ATUH=*".

因为URLs可能来自于一个非置信信息源,所以当解析一个需要或者请求任何有某种程度的身份验证的URL的时候,我们必须非凡的小心.假如身份验证证书是由错误的服务器所提供,那也许会损害用户账号的安全.在这种情况下,解析URL的程序应当确信符合至少一个以下的准则:

(1)URL来自于一个可信赖的信息源,比如一个已经被客户所验证的指定的服务器.并且客户总是信任这个站点的政策.注重能否确认URL的用户入口是一个可信赖的信息源,依靠于用户的经验和站点政策.

(2)明确的本地站点政策答应客户端连接到URL上的服务器.举个例子,假如客户知道这个站点的域名,站点政策也许会指出任何以这个域名结束的主机名都是可信任的.

(3)用户确认连接到那个有指定证书或者验证机制的域名是答应的.

(4)在通过一个潜在的可能泄密的客户证书之前,使用某种验证机制来验证服务器.

(5)因为某些服务器可能会危及将来的连接的安全,所以使用某种不会像那种服务器暴露信息的身份验证机制.

一个包含着";AUTH=*"字样的URL应该引起非凡的注重,因为在这样的情况下,这个URL可能依靠于一种脆弱的安全机制.最终,客户会因为仅仅依靠一种有";ATUH=*"字样的简易文本密码而失望,除非这个连接有强大的加密算法(比如一个超过56比特长度的密钥).

注重,诸如""(空格)或者";"(分号)等不安全的字符或者保留字,假如它们出现在用户名或者身份验证机制中,那他们必须按照RFC1738[BASIC-URL]所描述得来编码.

5.相对性POPURLs

相对性的POPURLs被禁止.

6.跨国问题

因为在URLs中不答应使用8-bit字符，所以在必要的时候,[UTF8]字符将按照URL的规范来编码.

7.样例

以下的例子示范了一个POP客户端程序如何将各种各样的POPURLs转换成一系列的POP命令.从客户端发送到服务器的命令被赋予前缀"C:",从服务器发送到客户端的响应被赋予前缀"S:".

样例URL:

<pop://rg@mailsrv.qualcomm.com>

产生以下客户端命令:

<请求用户口令>
<连接到mailsrv.qualcomm.com,端口110>
S:+OKPOP3serverready(服务器待命)
<1896.697170952@mailsrv.qualcomm.com>
C:USERrg
S:+OK
C:PASSsecret(口令通过)
S:+OKrg'smailboxhas2messages(信箱中有两条消息)(320octets(字节))

样例URL:

<pop://rg;AUTH=+APOP@mail.eudora.com:8110>

产生以下客户端命令.

<客户端请求用户口令>
<连接到mail.eudora.com,端口8110>
S:+OKPOP3serverready<1896.697170952@mail.eudora.com>
C:APOPrgc4c9334bac560ecc979e58001b3e22fb
S:+OKmailboxhas1message(369octets)

样例URL:

<pop://baz;AUTH=SCRAM-MD5@foo.bar>

产生以下客户端命令:

<连接到foo.bar,端口110>

S:+OKPOP3<serverready1896.697170952@foo.bar>
C:AUTHSCRAM-MD5
AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW
Fub3IuaW5ub3NvZnQuY29tPg==
S:+dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq
aGNOWmxSdvBiemlGcCt2TFYrTkN3
C:AQAAAMg9jU8CeB4KOFk7sUhSQPs=
S:+U0odqYw3B7XIIW0oSz65OQ==
C:
S:+OKmailboxhas1message(369octets)

8.POPURL方案的ABNF(缩略语)
用[ABNF]来描述POPURL方案:

achar=UChar/"&"/"="/"~"
见[BASIC-URL]对"uchar"的定义

auth=";AUTH="("*"/enc-auth-type)

enc-auth-type=enc-sasl/enc-ext

enc-ext="+"("APOP"/1*achar)
APOP或者已编码的扩充机制名

enc-sasl=1*achar
已编码的[SASL]"auth_type"版本

enc-user=1*achar
已编码的[POP3]信箱版本

pop-url="pop://"sever

sever=[user-auth"@"]hostport
见[BASIC-URL]对"hostport"的定义

user-auth=enc-user[auth]
9.安全问题
在[POP3]规范中所讨论的安全问题和[BASIC-URL]规范中所讨论的安全问题是有关系的.有关身份验证的URLs安全问题已经在本文档的第四节讨论过.

许多电子邮件客户端软件在第一次登录到POP服务器以后,为用户存储了简单的文本口令以便用户下次登录.在没有用户明确许可对指定的主机名提供相应的口令的情况下,这样的客户端软件必须'禁止'用被存储的口令来响应一个POPURL.
10.背景知识
这篇文档大量借用了ChrisNewman's[IMAP-URL]规范,并且力争符合[URL-GUIDELINES]中的参考说明.

11.参考文献

[ANBF]Crocker,D.,andP.Overell,"AugmentedBNFfor
SyntaxSpecifications:ABNF",RFC2234,November
1997.

[ACAP]Newman,C.,andJ.Myers,"ACAP--Application
ConfigurationAccessProtocol",RFC2244,November
1997.

[BASIC-URL]Berners-Lee,T.,Masinter,L.,andM.McCahill,
"UniformResourceLocators(URL)",RFC1738,
December1994.

[IMAP-URL]Newman,C.,"IMAPURLScheme",RFC2192,September1997.

[IMAP4]Crispin,M.,"InternetMessageAccessProtocol-
Version4rev1",RFC2060,December1996.

[KEYWORDS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.

[POP-AUTH]Myers,J.,"POP3AUTHenticationcommand",RFC1734,
December1994.

[POP3]Myers,J.,andM.Rose,"PostOfficeProtocol--
Version3",STD53,RFC1939,May1996.

[SASL]Myers,J.,"SimpleAuthenticationandSecurityLayer
(SASL)",RFC2222,October1997.

[URL-GUIDELINES]Masinter,Alvestrand,Zigmond,"Guidelinesfornew
URLSchemes",WorkinProgress.

[UTF8]Yergeau,F.,"UTF-8,atransformationformatofISO
10646",RFC2279,January1998.

12．作者地址：
RandallGellens
QUALCOMM,Incorporated
6455LuskBlvd.
SanDiego,CA92121-2779
U.S.A.

Phone:+16196515115
Fax:+16196515334
EMail:Randy@Qualcomm.Com
13．完整版权声明：
Copyright(C)TheInternetSociety(1998).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE。