RFC2384—POP協議的URL方案

本備忘錄狀態
ThisdocumentspecifiesanInte.netstandardstrackprotocolforthe
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:APOPrgc4c9334bac560eclearcase/" target="_blank" >cc979e58001b3e22fb
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。