POP3

RFC 1939個定義的POP3是一個極為簡單的郵件訪問協議。正因為它過于簡單，其功能也相當有限。POP3開始于用戶代理(客戶)打開一個到POP3服務器(服務器)端口號110的TCP連接。POP3服務器與郵件服務器運行在相同的服務器主機上，前者從用戶的郵箱中讀取并可能刪除郵件消息，后者往用戶的郵箱中寫入郵件消息。TCP連接建立好之后，POP3依次經歷授權隊證、處理和更新3個階段。在授權階段，用戶代理分別發出一個用戶名和一個口令以認證下載郵件消息的用戶。在處理階段，用戶代理獲取郵件消息，并可以標記待刪除的郵件消息或去掉這些標記，獲取郵件統計信息。更新階段發生在用戶代理發出quit命令以結束當前POP3會話之后，期間POP3服務器刪除己加過刪除標記的郵件消息。

在POP3會話期間，用戶代理發出命令，PoP3服務器則對每個命令響應以一個應答。可能的應答有兩個:指出剛才的命令執行成功的+oK(有時后跟一個解釋性消息)和指出剛才的命令執行有誤的-ERR。

授權階段共有兩個基本命令:user <用戶名>和pass<口令>。我們可以便用telnet工具指定使用POP端口號110直接登錄到某臺POP3服務器主機，并發出這些命令來展示它們的用法。假設mailserver是你的郵件服務器主機的名字，這個過程大體如下;

telnet mailserver 110

+OK POP3 server ready

user alice

+OK

pass password

+OK user successfully logged on

當然要是寫錯了某個命令，POP3服務器將返回一個-ERR應答。

下面查看一下處理階段。使用POP3的用戶代理可由用戶配置成“下載并刪除”或“下載并保留”兩種模式之一。POP3用尸代理發出的一系列命令取決于自己運行在哪種模式。在下載井刪除模式中，用戶代理會發出list，retr和dele命令。作為例子，我們假設用戶的郵箱中已存有兩個郵件消息，共POP3處理階段大體如下(其中前面標以“C:”的是用戶代理發出的命令，前面標以“S:”的是POP3服務器返回的應答):

C:list

S:1 498

S:2 912

S:.

C:retr 1

S:(blab ......

S: ............

S: ......)

S:.

C:dele 1

C:retr 2

S:(... ...

S:...

S:......)

S:.

C:dele 2

C:quit

S:+OK POP3 server signing off

用戶代理首先要求POP3服務器列出存放在自己的郵箱中的每個郵件消息的大小，接著依次取回并刪除每個郵件消息。需注意的是，授權階段結束之后，用戶代理只能發出4個命令:list，retr，deie，quitt。這些命令的具體語法定義在RFC 1939中。處理完quit命令后，POP3服務器進入更新階段，把郵件消息1和2從相應的郵箱中刪除。

下載并刪除模式存在一個問題，也就是收信人可能希望從不止一臺主機訪問自已的郵箱，如既能從辦公室PC機訪問.也能從家庭PC機訪問，還能從使攜機訪問。下裁并刪除模式將導致同一用戶的郵件消息散布到他的多臺主機上;例如，要是他先在家里的PC機上閱讀了某個郵件消息，以后就沒法在使攜機上閱讀同一個郵件消息了。下裁并保留模式則恰好相反，用戶代理把己從POP3服務器下載的郵件消息繼續保留在郵件服務器中。這種模式下，用戶可以在不同的時間從不向的主機訪問同樣的郵件消息。

在用戶代理和郵件服務器之間的POP3會話期間，POP3務器維護一定的狀態信息:具體地說，它跟蹤哪些郵件消息己被標記成待刪除。不過POP3服務器不會跨會話保存狀態信息。例如，每次會話開始之時沒有任何郵件消息被標記成待刪除。這種不跨會話保存狀態信息的處理辦法極大地簡化了PoP3服務器軟件的實現。

IMAP

收信人使用POP3把郵件消息下載到本地機之后，就可以把它們移入現行的或新創建的郵件夾中。他然后可以刪除郵件消息，跨郵件夾轉移郵件消息，按發信人名字或消息主題搜索郵件消息，等等。然而，這種郵件夾和郵件消息都存放在本地機上的模式對于游動用戶卻構成了問題。游動用戶更愿意在遠程郵件服務器主機上維護郵件夾，這樣從任何主機都可以訪問它。使用POP3是不可能做到達一點的。

RFC 2060中定義的IMAP協議正是為解決本問題和其他一些問題而發明的。IMAP提供的特性比POP3多出不少，不過也復雜得多，其客戶端和服務器端的實現也相應地更為復雜。IMAP設計成允許用戶象對待本地郵箱那樣操縱遠程郵箱。具體地說，IMAP使得收信人能夠在自己的郵件服務器主機中創建并維護多個存放郵件消息的郵件夾。他們可以把郵件消息存入郵件夾，也可以從一個郵件夾到另一個郵件夾轉移郵件，還可以在這些遠程郵件夾中搜索匹配特定準則的郵件消息。IMAP的實現比POP3的實現復雜得多，原因之一就是IMAP服務器必須為每個用戶維護一個郵件夾層次結構。某個用戶相繼訪問自己的IMAP服務器時，這個IMAP服務器為該用戶維護的狀態信息跨這些相繼的訪問保持一致。POP3服務器則相反，一旦用戶退出當前的POP3會話，它們就不再為他們維護狀態信息。

IMAP的另一個重要特性是，它有一些允許用戶代理獲取郵件消息部件的命令。例如，用戶代理可以只獲取郵件消息的信頭，或者只獲取多部分MIME消息的某個部分。這個特性在用戶代理和郵件服務器主機之間為低帶寬連接(例如無線連接或低速調制解調器撥號連接)時非常有用。通過低帶寬連接訪問郵件時，用戶很可能不希望下載自己的郵箱中的所有郵件消息，特別是可能含有音頻或視頻剪輯的長消息。

IMAP會話過程首先是用戶代理(客戶)發起建立…個到IMAP服務器(服務器)端口號143的TCP連接，然后是服務器返回初始問候消息，接著就是客戶和服務器之間的交互了。客戶和服務器的交互與POP3的類似，不過要豐富些，由客戶發出的命令、服務器返回的數據或命令完成結果響應構成。IMAP服務器在會話期間總是處于以下4個狀態之一:未認證(nonauthenticated)、已認證(authenticated)、已選擇(selected)和注銷(1ogout)。未認證狀態是連接剛建立時的初始狀合，這種狀態下，用戶必須提供一個用戶名和口令對才能發出更多的命令。在已認證狀態下，用戶必須選擇一個郵件夾才能發出作用于郵件消息的命令。在已選擇狀態下，用戶可以發出作用于郵件消息的任何命令(獲取、轉移、刪除、獲取多部分消息的某個部分，等等)。最后的注銷狀態是會話即將終止時的狀態。IMAP命令是按照每個狀態下分別能夠執行哪些命令來組織的。在IMAP的官方站點可以找到關十IMAP的所有內容。

HTTP郵件

今天，越來越多的用戶轉向使用基于瀏覽器的電子郵件服務，例如Hotmail和Yahoo!Mall。使用提供這種服務的服務器時，用戶代理是普通的web瀏覽器，用戶與存放在郵件服務器主機上的郵箱之間的交互相應地經由HTTP完成。當收信人(例如Bob)想要查看自己的郵箱中的郵件消息時，這些消息是通過HTTP協議(而不是POP3或IMAP協議)從郵件服務器主機傳送到他的瀏覽器的。當發信人(例如Alice)想要發送電子郵件消息時，這些消息也是通過HTTP(而不是SMTP)從她的瀏覽器傳送到她的郵件服務器主機的。不過郵件消息在郵件服務器主機之間的中轉仍然通過SMTP。這種郵件訪問辦法對于游動用戶來說極為方便。游動用戶只要能使用瀏覽器，就能收發郵件消息，而瀏覽器可以在網吧、朋友家、裝有Web Tv的旅館等地方找到。與IMAP一樣，用戶可以在遠程服務器主機中使用一個郵件夾層次結構組織郵件消息。基于Web的電子郵件既然如此方便，在未來幾年內替換掉POP3或IMAP訪問辦法也是有可能的。它的主要不足之處在于速度比較慢，因為其服務器主機往往遠離客戶主機，而且用戶的瀏覽器是通過CGl腳本與郵件服務器間接交互的。

持續媒體電子郵件

持續媒體(continuous-media，簡稱CM)電子郵件是包含音頻或視頻數據的電子郵件系統，它對于朋友之間和家庭成員之間的異步交流很有吸引力。例如，學齡前兒童更愿意使用CM電子郵件給祖父母發送郵件消息。CM電子郵件在公司也可能受歡迎，因為辦公室工作人員錄制CM郵件消息的速度要比輸入文本消息的速度快許多(使用英語每分鐘可以說180個單詞，但是普通辦公室工作人員每分鐘只能輸入20一40個單詞)。CM電子郵件在某些方面類似電話語音留言，不過功能要強大得多。它不僅給用戶提供一個訪問郵箱的圖形界面，而且允許用戶評注并回復CM郵件消息，或者把CM郵件消息轉發給多個收信人。

CM電子郵件與傳統文本電子郵件在許多方面存在差異。CM電子郵件可能有大得多的郵件消息，對于端到端延遲有更嚴格的要求，對于收傳人干差萬別的因特網訪問速率和本地存儲容量也更為敏感。不幸的是，當前的電子郵件設施存在一些妨礙CM電于郵件推廣的不足之處。首先，許多現有的郵件服務器沒有存放大的郵件消息的容量;它們一般拒絕接收或中轉CM郵件消息，因此不可能給依附它們的收傳人發送這樣的消息。其次，收信人的用戶代理只在取得完整的郵件消息后才表達其內容，對于CM電子郵件，這會導致網絡帶寬和本地主機存儲容量的過度浪費。事實上，倉儲的CM郵件消息往往不是完整地表達的，因此接收未作表達的數據顯然浪費了網絡帶寬和本地存儲容量(例如，當某人收到來自相當嘮叨的同事的長篇語音郵件消息后，可能只聽上前15秒就決定不再聽，要刪除還剩20分鐘內容的整個消息)。再次，當前使用的郵件訪問協議(POP3，IMAP，HTTP)不適合為收信人流播放CM郵件消息。

具體地說，這些郵件訪問協議沒有提供這樣的功能:允許用戶暫停/恢復播放郵件消息內容，或者在郵件消息內重新定位播放點;另外，在TCP上實現流播放往往導致糟糕的接收效果。這些不足之處有望在未來的幾年內得到解決。不過近來超大郵箱開始流行起來，如GMAIL等，郵箱容量的限制問題正在得到解決。