RFC1939-POP3

簡介

　　對于在網絡上的比較小的結點，支援消息傳輸系統（ MTS ）是不實際的。例如，一台工作站可能不具有充足的資源允許 SMTP 伺服器和相當的本地郵件傳送系統保持序駐留，并持續運作。同樣的，将一台個人計算機長時間連接配接在 IP 類型網絡上的費用也是可觀的（結點缺少的資源被稱為 " 聯絡性 " ）。

　　雖然如此，在這樣的小結點上允許管理郵件是十分有用的，并且這些結點經常支援一個使用者代理來管理郵件。為解決這一問題，能夠支援 MTS 的結點就為這些不能支援的結點提供了郵件存儲功能。郵局協定 - 版本 3就是使這樣的工作站可以用一種比較實用的方法來通路存儲于伺服器上的儲存郵件。通常，這意味着工作站可以從伺服器上取得郵件，而伺服器為它暫時儲存郵件。

　　在下文中，客戶主機指的是利用 POP3 服務的主機，而伺服器主機指的是提供 POP3 服務的主機。

2. 簡單說明

　　在此文檔中不指明客戶主機如何将郵件送入到傳送系統中去。但這裡有一個說明：當使用者代理需要将資訊送到傳送系統時，它在接力主機上建立 SMTP 連接配接（這些接力主機可以是 POP3 主機，也可以不是）。

3. 基本操作

　　初始時，伺服器通過偵聽 TCP 端口 110 開始 POP3 服務。當客戶主機需要使用服務時，它将與伺服器主機建立 TCP 連接配接。當連接配接建立後， POP3 發送确認消息。客戶和 POP3 伺服器互相（分别）交換指令和響應，這一過程一直要持續到連接配接終止。

　　 POP3 指令由一個指令和一些參數組成。所有指令以一個 CRLF 對結束。指令和參數由可列印的 ASCII 字元組成，它們之間由空格間隔。指令一般是三到四個字母，每個參數卻可達 40 個字元長。

　　 POP3 響應由一個狀态碼和一個可能跟有附加資訊的指令組成。所有響應也是由 CRLF 對結束。現在有兩種狀态碼， " 确定 " ("+OK") 和 " 失敗 " ("-ERR") 。

　　對于特定指令的響應是由許多字元組成的。在這些情況中，下面一一表述：在發送第一行響應和一個 CRLF之後，任何的附加資訊行發送，他們也由 CRLF 對結束。當所有資訊發送結束時，發送最後一行，包括一個結束字元（十進制碼 46 ，也就是 "." ）和一個 CRLF 對。如果資訊中的任何一行以結束字元開始，此行就是通過在那一行預先裝入結束而進行字元填充的。是以，多行響應由五個 CRLF.CRLF 結束。當檢測多行響應時，客戶檢測以确認此行是否以結束字元開始。如果是的，而且其後的字元不是 CRLF ，此行的第一個字元（結束字元）将被抛棄；如果其後緊跟 CRLF ，從 POP 伺服器來的響應終止，包括 .CRLF 的行也不被認為是多行響應的一部分了。

　　在生命周期中， POP3 會話有幾個不同的狀态。一旦 TCP 連接配接被打開，而且 POP3 伺服器發送了确認資訊，此過程就進入了 " 确認 " 狀态。在此狀态中，客戶必須向 POP3 伺服器确認自己是其的客戶。一旦确認成功，伺服器就擷取與客戶郵件相關的資源，此時這一過程進入了 " 操作 " 狀态。在此狀态中，客戶提出服務，當客戶發出 QUIT 指令時，此過程進入了 " 更新 " 狀态。在此狀态中， POP3 伺服器釋放在 " 操作 " 狀态中取得的資源，并發送消息，終止連接配接。

　　 POP3 伺服器可以擁有一個自動登出的記時器。此記時器必須至少可以記錄 10 分鐘。這樣從客戶發送的消息才可能重新整理此記時器。當記時器失效時， POP3 會話并不進入 " 更新 " 狀态，而是關閉 TCP 連接配接，而且不删除任何消息，不向客戶發送任何響應。

4. " 确認" 狀态

　　一時 TCP 連接配接由 POP3 客戶打開， POP3 伺服器發送一個單行的确認。這個消息可以是由 CRLF 結束的任何字元。例如，它可以是：

　　　　 S: +OK POP3 server ready

　　注意：這個消息是一個 POP3 應答。 POP3 伺服器應該給出一個 " 确定 " 響應作為确認。

　　此時 POP3 會話就進入了 " 确認 " 狀态。此時，客戶必須向伺服器證明它的身份。在文檔中介紹兩種可能的處理機制，一種是 USER 和 PASS 指令，另一種是在後面要介紹的 APOP 指令。

　　用 USER 和 PASS 指令進行确認過程，客戶必須首先發送 USER 指令，如果 POP3 伺服器以 " 确認 " 狀态碼響應，客戶就可以發送 PASS 指令以完成确認，或者發送 QUIT 指令終止 POP3 會話。如果 POP3 伺服器傳回" 失敗 " 狀态碼，客戶可以再發送确認指令，或者發送 QUIT 指令。

　　當客戶發送了 PASS 指令後，伺服器根據 USER 和 PASS 指令的附加資訊決定是否允許通路相應的存儲郵件。

　　一旦伺服器通過這些資料決定允許客戶通路儲存郵件，伺服器會在郵件上加上排它鎖，以防止在進入 " 更新 "狀态前對郵件的改變。如果成功獲得了排它鎖，伺服器傳回一個 " 确認 " 狀态碼。會話進入 " 操作狀态 " ，同時沒有任何郵件被标記為删除。如果郵件因為某種原因不能打開（例如，排它鎖不能獲得，客戶不能通路相應的郵件或者郵件不能進行文法分析），伺服器将傳回 " 失敗 " 狀态碼。在傳回 " 失敗 " 狀态碼後，伺服器會關閉連接配接。如果伺服器沒有關閉連接配接，客戶可以重新發送确認指令，重新開始，或者發送 QUIT 指令。

　　在伺服器打開郵件後，它為每個消息指定一個消息号，并以八進制表示每個消息的長度。第一個消息被指定為 1 ，第二個消息被指定為 2 ，以此類推，第 N 個消息被指定為 N 。在 POP3 指令和響應中，是以的消息号和長度以十進制表示。

　　下面是對上述三條指令的總結：

5. " 操作" 狀态

　　一旦客戶向伺服器成功地确認了自己的身份，伺服器将鎖住并打開相應的郵件，這時 POP3 會話進入 " 操作" 狀态。現在客戶可以重複下面的 POP3 指令，對于每個指令伺服器都會傳回應答。最後，客戶發送 QUIT 指令，會話進入 " 更新 " 狀态。

下面是在 " 操作 " 狀态中可用的指令：

6." 更新" 狀态

　　當客戶在 " 操作 " 狀态下發送 QUIT 指令後，會話進入 " 更新 " 狀态。（注意：如果客戶在 " 确認 " 狀态下發送 QUIT 後，會話并不進入 " 更新 " 狀态。）

　　如果會話因為 QUIT 指令以外的原因中斷，會話并不進入 " 更新 " 狀态，也不從伺服器中删除任何信件。

7. 可選的POP3 指令

　　以上讨論的指令是對 POP3 服務的最小實作。以下說明的可選指令允許客戶更友善地處理信件，這是一個比較一般的 POP3 服務實作。

　　• TOP msg n

　　【參數】一個是未被标記為删除的信件數，另一個是非負數（必須提供）

　　【限制】僅在 " 操作 " 狀态下使用。

　　【說明】

　　如果伺服器傳回 " 确認 " ，響應是多行的。在初始的 +OK 後，伺服器發送信件頭，一個空行将信件頭和信件體分開，對于多行響應要注意位元組填充終止符。

　　注意：如果客戶要求的行數比信件體中的行數大，伺服器會發送整個信件。

　　【響應】 +OK ：其後有信件頭；

　　 -ERR ：其後無類似消息。

　　【例子】

　　 C: TOP 1 10

　　 S: +OK

　　 S: < 伺服器發送消息頭，一個空行和信件的頭 10 行 >

　　 S: .

　　 ...

　　 C: TOP 100 3

　　 S: -ERR no such message

　　• UIDL [msg]

　　【參數】信件數（可選）。如果給出信件數，不包括被标記為删除的信件。

　　【限制】僅在 " 操作 " 狀态下使用。

　　【說明】

　　如果給出了參數，且 POP3 伺服器傳回包括上述資訊的 " 确認 " ，此行稱為資訊的 " 獨立 -ID 表 " 。

　　如果沒有參數，伺服器傳回 " 确認 " 響應，此響應便以多行給出。在初的 +OK 後，對于每個信件，伺服器均給出相應的響應。此行叫做信件的 " 獨立 -ID 表 " 。

　　為簡化文法分析，所有伺服器要求使用獨立 -ID 表的特定格式。它包括空格和信件的獨立 -ID 。

　　信件的獨立 -ID 由 0x21 到 0x7E 字元組成，這個符号在給定的存儲郵件中不會重複。

　　注意：信件不包括被标記為删除的信件。

　　【響應】 +OK ：其後是獨立 -ID 表；

　　 -ERR ：其後無類似信件。

　　【例子】

　　 C: UIDL

　　 S: +OK

　　 S: 1 whqtswO00WBw418f9t5JxYwZ

　　 S: 2 QhdPYR:00WBw1Ph7x7

　　 S: .

　　 ...

　　 C: UIDL 2

　　 S: +OK 2 QhdPYR:00WBw1Ph7x7

　　 ...

　　 C: UIDL 3

　　 S: -ERR no such message, only 2 messages in maildrop

　　• APOP name digest

　　【參數】指定郵箱的字串和 MD5 摘要串。

　　【限制】僅在 POP3 确認後的 " 确認 " 狀态中使用。

　　【說明】通常，每個 POP3 會話均以 USER/PASS 互換開始。這導緻了使用者名和密碼在網絡上的顯式傳送，這不會造成什麼危險。但是，許多客戶經常連接配接到服務檢查信件。通常間隔時間比較短，這就加大了洩密的可能性。

另一種提供 " 确認 " 過程的方法是使用 APOP 指令。

　　實作 APOP 指令的伺服器包括一個标記确認的時間戳。例如：在 UNIX 上使用 APOP 指令的文法為：[email protected] ，其中程序 -ID 是程序的十進制的數，時鐘是系統時鐘的十進制表示，主機名與POP3 伺服器名一緻。

　　客戶記錄下此時間戳，然後以送 APOP 指令。 name 文法和 USER 指令一緻。 Digest 是采用 MD5 算法産生的包括時間戳和共享密鑰的字串。此密鑰是客戶和伺服器共知的，應該注意保護此密鑰，如果洩密，任何人都能夠以使用者身份進入伺服器。

　　如果伺服器接到 APOP 指令，它驗證 digest ，如果正确，伺服器傳回 " 确認 " ，進入 " 操作 " 狀态；否則，給出 " 失敗 " 并停留在 " 确認 " 狀态。

　　注意：共享密鑰的長度增加，解讀它的難度也相應增加，這個密鑰應該是長字元串。

　　【響應】 +OK ：郵件鎖住并準備好；

　　 -ERR ：拒絕請求。

　　【例子】

　　 S: +OK POP3 server ready <[email protected]>

　　 C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

　　 S: +OK maildrop has 1 message (369 octets)

　　在此例子中，共享密鑰 <[email protected]>tanstaaf 由 MD5 算法生成，它産生了 digest值， c4c9334bac560ecc979e58001b3e22fb

8. POP3 指令總結

基礎的 POP3 指令：

USER name 在 " 确認 " 狀态有效

PASS string

QUIT

　

STAT 在 " 操作 " 狀态有效

LIST [msg]

RETR msg

DELE msg

NOOP

RSET

　

QUIT 在 " 更新 " 狀态有效

　

可選的 POP3 指令：

APOP name digest 在 " 确認 " 狀态有效

TOP msg n 在 " 操作 " 狀态有效

UIDL [msg]

　

POP3 響應：

+OK

-ERR

　

注意：除了 STAT ， LIST 和 UIDL 的響應外，其它指令的響應均為 "+OK" 和 "-ERR" 。響應後的所有文本将被客戶略去。

9. POP3 會話執行個體

S: < 等待連接配接到 TCP 端口 110>

C: < 打開連接配接 >

S: +OK POP3 server ready <[email protected]>

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: +OK mrose's maildrop has 2 messages (320 octets)

C: STAT

S: +OK 2 320

C: LIST

S: +OK 2 messages (320 octets)

S: 1 120

S: 2 200

S: .

C: RETR 1

S: +OK 120 octets

S: < 伺服器發送信件 1>

S: .

C: DELE 1

S: +OK message 1 deleted

C: RETR 2

S: +OK 200 octets

S: < 伺服器發送信件 2>

S: .

C: DELE 2

S: +OK message 2 deleted

C: QUIT

S: +OK dewey POP3 server signing off (maildrop empty)

C: < 關閉連接配接 >

S: < 等待下一次連接配接 >

10. 消息格式

　　在會話過程中的消息格式都假定與 Internet 文本消息格式标準一緻。應該注意的是，由于各個伺服器對于換行符的處理不同，是以計數不一定相同。通常，在 " 确認 " 狀态中，伺服器能夠以八進制計算信件的大小。例如，如果在打開儲存郵件時伺服器内部認定換行符代表一個字元，一般伺服器在計算它時作為兩個字元計。注意，以終止符開始的消息行不被計數兩次，因為客戶将在接收到多行響應後删除所有位元組填充。

11. 安全性考慮

　　可以推測，使用 APOP 指令可以提供會話期間的保護。相應的，同時實作 PASS 和 APOP 指令的伺服器隻允許使用者以一種方式通路；也就是說要麼使用 USER/PASS 組合，要麼使用 APOP 指令，不能同時使用兩個。

而且，注意随着共享密鑰長度的增加，解讀的難度也就上升了。伺服器要提供使用者名時不給出任何響應，不給出任何暗示此使用者名是否正确。而密碼卻在網絡上顯式傳送；使用 RETR 和 TOP 指令在網絡上顯式傳送信件。

12. 參考資料

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

821, USC/Information Sciences Institute, August 1982.

[RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text

Messages", STD 11, RFC 822, University of Delaware, August 1982.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,

MIT Laboratory for Computer Science, April 1992.

[RFC1730] Crispin, M., "Internet Message Access Protocol - Version

4", RFC 1730, University of Washington, December 1994.

[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,

Carnegie Mellon, December 1994.

14. 緻謝

The POP family has a long and checkered history. Although primarily

a minor revision to RFC 1460, POP3 is based on the ideas presented in

RFCs 918, 937, and 1081.

In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff

provided significant comments on the APOP command.

15. 作者位址

John G. Myers

Carnegie-Mellon University

5000 Forbes Ave

Pittsburgh, PA 15213

EMail: [email protected]

Marshall T. Rose

Dover Beach Consulting, Inc.

420 Whisman Court

Mountain View, CA 94043-2186

EMail: [email protected]

Appendix A. Differences from RFC 1725

This memo is a revision to RFC 1725, a Draft Standard. It makes the

following changes from that document:

- clarifies that command keywords are case insensitive.

- specifies that servers must send "+OK" and "-ERR" in

upper case.

- specifies that the initial greeting is a positive response,

instead of any string which should be a positive response.

- clarifies behavior for unimplemented commands.

- makes the USER and PASS commands optional.

- clarified the set of possible responses to the USER command.

- reverses the order of the examples in the USER and PASS

commands, to reduce confusion.

- clarifies that the PASS command may only be given immediately

after a successful USER command.

- clarified the persistence requirements of UIDs and added some

implementation notes.

- specifies a UID length limitation of one to 70 octets.

- specifies a status indicator length limitation

of 512 octets, including the CRLF.

- clarifies that LIST with no arguments on an empty mailbox

returns success.

- adds a reference from the LIST command to the Message Format

section

- clarifies the behavior of QUIT upon failure

- clarifies the security section to not imply the use of the

USER command with the APOP command.

- adds references to RFCs 1730 and 1734

- clarifies the method by which a UA may enter mail into the

transport system.

- clarifies that the second argument to the TOP command is a

number of lines.

- changes the suggestion in the Security Considerations section

for a server to not accept both PASS and APOP for a given user

from a "must" to a "should".

- adds a section on scaling and operational considerations

組織： 中國互動出版網（ http://www.china-pub.com/ ）

RFC 文檔中文翻譯計劃（ http://www.china-pub.com/compters/emook/aboutemook.htm ）

E-mail ： [email protected]

譯者： 顧國飛（ ggfei [email protected] ）

譯文釋出時間： 2001-4-10

版權： 本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本文檔的翻譯及版權資訊。