組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：（sbook   ssx@tech.com.cn）
譯文發布時間：2001-4-2
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權信息。

Network Working Group                                        R. Gellens
Request for Comments: 2384                       QUALCOMM, Incorporated
Category: Standards Track                                   August 1998


RFC2384—POP協議的URL方案
（RFC2384----POP URL Scheme）

本備忘錄狀態
   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.
版權聲明
   Copyright (C) The Internet Society (1998).  All Rights Reserved.



目錄
1.介紹................................................. ..........................................	2
2. 在本文當中的一些約定...................................................................	2
3. POP方案................................................. ....................................	2
4. POP用戶名與身份驗證機制.............................................................	3
5.  相對性POP URLS........................................................................	4
6 . 跨國問題.....................................................................................	4
7 . 樣例...........................................................................................	4
8. POP URL  方案的ABNF(縮略語) ....................................................	6
9. 安全問題................................................. ....................................	6
10. 背景知識....................................................................................	7
11. 參考文獻....................................................................................	7
12．作者地址....................................................................................	8
13．完整版權聲明..............................................................................	8






























1.介紹
    
     [POP3]是一種廣泛應用的郵件傳輸協議.許多程序都要訪問POP3消息存儲設備,因此需要了解POP3的配置信息.為了訪問一個信箱,需要有若干必須的配置單元,所以使用單精度型的字符串表示法是將會很方便.

      一個POP3郵箱(像[IMAP4]郵箱一樣)是一種網絡資源,而URLs(全球資源定位)是一種被廣泛支持的網絡資源的通用的表示方法。
  
      在很多程序和協議中，一些將一個POP3信箱指定作為一個URL的方法的是很有用的.[ACAP]就是是這樣一個例子,在這里,必須要有一個對需要用來訪問網絡服務的單元的封裝.比如,在ACAP數據集中,一個[IMAP4]消息存儲設備通常被指定為一個[IMAP-URL].
  
       這個備忘錄為涉及到的POP信箱定義了一個URL方案.

2. 在本文當中的一些約定.
	
    在本文當中,關鍵字"必須","禁止","應該","不宜","可以"和在"確定了必要標準的RFCs(請求注解)中所使用的關鍵字"[KEYWORDS]的解釋相一致.

3. POP方案

      POP URL方案指定了一個POP服務器,一個端口號,身份驗證機制,身份驗證帳號,以及/或者說是授權賬號.

      除了完全的文本口令顯示不被允許以外，POP URL遵循定義在RFC 1738[BASIC-URL]通用的Internet方案的文法.假如:<port(端口)>被省略,默認端口將會是110.

      下面是一個POP URL通常的格式:

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

      其中,<user(用戶)>,<host(主機)>和<port(端口)>被定義在RFC 1738,并且除了"pop://"和<host>,剩下的單元可以被部分或者全部省略.

4. POP用戶名與身份驗證機制

     下列元素也許要被提供:對某個信箱進行訪問的授權,用口令來核對的身份驗證(為了簡明,這里僅涉及到用戶名),以及驗證機制名.在與POP服務器連接之后,這些將被用于"USER","APOP","AUTH(身份驗證)"[POP-AUTH]或者擴展命令.假如URL并沒有提供一個驗證標識符,那么解釋POP URL的程序'應該'從用戶那里請求一個這樣的標識符.

      一個身份驗證機制,能夠通過增加";AUTH=<enc-auth-type>(已編碼的身份驗證類型)"到用戶名末端而表述出來.假如驗證機制名的前面沒有一個"+",它就是一個SASL POP[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比特長度的密鑰).

      注意,諸如" "(空格)或者";"(分號)等不安全的字符或者保留字,假如它們出現在用戶名或者身份驗證機制中,那他們必須按照RFC 1738[BASIC-URL]所描述得來編碼.

5.  相對性POP URLs

      相對性的POP URLs被禁止.

6 . 跨國問題

     因為在URLs中不允許使用8-bit字符，所以在必要的時候,[UTF8]字符將按照URL的規范來編碼.

7 . 樣例

     以下的例子示范了一個POP客戶端程序如何將各種各樣的POP URLs 轉換成一系列的POP命令.從客戶端發送到服務器的命令被賦予前綴"C:",從服務器發送到客戶端的響應被賦予前綴"S:".
     
      樣例URL:
      
           <pop://rg@mailsrv.qualcomm.com>

      產生以下客戶端命令:
          
           <請求用戶口令>
           <連接到 mailsrv.qualcomm.com,端口 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(字節)) 

      樣例URL:

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

      產生以下客戶端命令.

            <客戶端請求用戶口令>
            <連接到mail.eudora.com,端口8110>
            S:+OK POP3 server ready<1896.697170952@mail.eudora.com>
            C:APOP rg c4c9334bac560ecc979e58001b3e22fb
            S:+OK mailbox has 1 message (369 octets)

       樣例URL:

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

        產生以下客戶端命令:
      
             <連接到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)

8. POP URL  方案的ABNF(縮略語)
     用[ABNF]來描述POP URL方案:

          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服務器以后,為用戶存儲了簡單的文本口令以便用戶下次登錄.在沒有用戶明確許可對指定的主機名提供相應的口令的情況下,這樣的客戶端軟件必須'禁止'用被存儲的口令來響應一個POP URL .
10. 背景知識
    這篇文檔大量借用了Chris Newman's [IMAP-URL]規范,并且力爭符合[URL-GUIDELINES]中的參考說明.

11. 參考文獻

     [ANBF]          Crocker, D.,and P. Overell, "Augmented BNF for
                         Syntax Specifications: ABNF", RFC 2234,November
                         1997  .
    
     [ACAP]             Newman, C., and J. Myers, "ACAP -- Application
                          Configuration Access Protocol", RFC 2244, November
                          1997.

     [BASIC-URL]      Berners-Lee, T., Masinter, L., and M. McCahill,
                    "Uniform Resource Locators (URL)", RFC 1738,
                    December 1994.

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

   [IMAP4]          Crispin, M., "Internet Message Access Protocol -
                    Version 4rev1", RFC 2060, December 1996.

   [KEYWORDS]       Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

   [POP-AUTH]       Myers, J., "POP3 AUTHentication command", RFC 1734,
                    December 1994.

   [POP3]           Myers, J., and M. Rose, "Post Office Protocol --
                    Version 3", STD 53, RFC 1939, May 1996.

   [SASL]           Myers, J., "Simple Authentication and Security Layer
                    (SASL)", RFC 2222, October 1997.

   [URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new
                    URL Schemes", Work in Progress.

   [UTF8]           Yergeau, F., "UTF-8, a transformation format of ISO
                    10646", RFC 2279, January 1998.

12．作者地址：  
   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
13．完整版權聲明：
   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   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。
 RFC2384    POP URL Scheme                                 POP協議的URL方案

1


1
ＲＦＣ文檔中文翻譯計劃