電子郵件收發原理和實現(POP3, SMTP)

電子郵件的收發流程示意圖：

相對於郵件客戶端的流程就是：

郵件接收——POP3協議
POP3（Post Office Protocol 3，郵局協議版本3）主要用於支持使用客戶端遠程管理在服務器上的電子郵件。該協議是在RFC-1939中定義的，是Internet上的大多數人用來接收郵件的機制。POP3採用Client/Server工做模式，默認使用TCP 110端口。

• 在使用POP協議時，人們熟悉的不少功能，如查看收到了多少新郵件消息的功能，POP根本不支持。這些功能都內置到諸如Eudora或 Microsoft Outlook之類的郵件程序中，能爲您記住接收的上一封郵件，以及計算有多少新郵件這類信息。所以，若是想獲取這類信息，將須要由本身進行計算。
  [詳細請參考wiki的解析：http://zh.wikipedia.org/wiki/POP3 ]

<POP3狀態圖>

<POP3經常使用命令表>

• 對大小寫不敏感，以CRLF做爲結束
  [詳細可參考RFC1939協議，http://www.rfc-ref.org/RFC-TEXTS/1939/contents.html ]

命令可能的返回值

• OK <描述> 成功
• ERR <描述> 失敗

<POP3工做原理>
1) 客戶端使用TCP協議鏈接郵件服務器的110端口；
2) 客戶端使用USER命令將郵箱的帳號傳給POP3服務器；
3) 客戶端使用PASS命令將郵箱的帳號傳給POP3服務器；
4) 完成用戶認證後，客戶端使用STAT命令請求服務器返回郵箱的統計資料；
5) 客戶端使用LIST命令列出服務器裏郵件數量；
6) 客戶端使用RETR命令接收郵件，接收一封后便使用DELE命令將郵件服務器中的郵件置爲刪除狀態；
7) 客戶端發送QUIT命令，郵件服務器將將置爲刪除標誌的郵件刪除，鏈接結束。
（注：客戶端UA能夠設定將郵件在郵件服務器上保留備份，而不將其刪除。）

一個基本實現(Java)：
Pop3Test.java (見附件)

郵件發送——SMTP協議
SMTP（Simple Message Transfer Protocol，簡單郵件傳輸協議）是用於傳送電子郵件的機制。該協議是在RFC-821中定義的。採用Client/Server工做模式，默認使用TCP 25端口。
[詳細請參考wiki的解析：http://zh.wikipedia.org/wiki/SMTP ]

<SMTP狀態圖>

<SMTP經常使用命令表>

• 對大小寫不敏感，以CRLF做爲結束
  [詳細可參考RFC821協議，中文版連接地址：http://www.5dmail.net/rfc/RFC821.txt ]

命令可能的返回值
500 格式錯誤，命令不可識別（此錯誤也包括命令行過長）
501 參數格式錯誤
502 命令不可實現
503 錯誤的命令序列
504 命令參數不可實現
211 系統狀態或系統幫助響應
214 幫助信息
220 <domain> 服務就緒
221 <domain> 服務關閉傳輸信道
421 <domain> 服務未就緒，關閉傳輸信道（當必須關閉時，此應答能夠做爲對任何命令的響應）
250 要求的郵件操做完成
251 用戶非本地，將轉發向<forward-path>
450 要求的郵件操做未完成，郵箱不可用（例如，郵箱忙）
550 要求的郵件操做未完成，郵箱不可用（例如，郵箱未找到，或不可訪問）
451 放棄要求的操做；處理過程當中出錯
551 用戶非本地，請嘗試<forward-path>
452 系統存儲不足，要求的操做未執行
552 過量的存儲分配，要求的操做未執行
553 郵箱名不可用，要求的操做未執行（例如郵箱格式錯誤）
354 開始郵件輸入，以<CRLF>.<CRLF>結束
554 操做失敗

1.2. 幾個術語
1.2.1. 郵件
郵件是一種消息的格式，由信封、首部和正文組成。

信封上最重要的是收信人的地址。郵件服務器用這個地址將郵件發送到收信人所在的郵件服務器上。

首部是由用戶代理或郵件服務器添加的一些信息。包括Received、Message-ID、From、Data、Reply-To、X-Phone、X-Mailer、To和Subject等字段。

正文是是發送用戶發給接收用戶報文的內容。RFC 822 規定正文爲NVT ASCII文字行。

更爲詳細的說明，請參考RFC821和RFC822等協議。

1.2.2. 用戶代理
用戶代理UA（User Agent）是用戶與電子郵件系統的交互接口，通常來講它就是咱們PC機上的一個程序。Windows上常見的用戶代理是Foxmail和Outlook Express。

用戶代理提供一個好的用戶界面，它提取用戶在其界面填寫的各項信息，生成一封符合SMTP等郵件標準的郵件，而後採用SMTP協議將郵件發送到發送端郵件服務器。

1.2.3. 郵件服務器
郵件服務器是電子郵件系統的核心，它用來發送和接收郵件。郵件服務器不一樣於普通PC的是它幾乎是全天工做的，因此它能夠在任什麼時候候爲用戶提供服務，後面將提到這正是爲何須要郵件服務器的一個重要緣由。不少ISP都提供免費的郵件服務器，如126提供smtp.126.com郵件服務器。

郵件服務器向其它郵件服務器轉發郵件也是採用SMTP協議。
1.2.4. SMTP和郵件格式的關係
如前所述，SMTP是客戶機向服務器發送郵件時所使用的協議，其核心是2.2中所述的命令和響應，至於它命令和響應中所帶的參數採用什麼格式，則是依賴於其餘標準的。例如DATA後所帶的參數，則應遵循郵件格式標準RFC822．

SMTP和郵件格式的關係可用這麼一個例子來講明。甲與乙書信往來，甲經過郵局向乙發信，郵局間轉交郵件可當作使用了SMTP協議，至於書信的格式則會由於地區習慣等的不一樣而不一樣（中國人的書信格式和美國人的書信格式不一樣），這個書信格式則可當作是郵件格式標準。

應當認識到不能孤立地看待協議，各個協議之間每每存在着耦合關係，但爲了分析方便，咱們在具體敘述某個協議時，只能抓住主要矛盾——主要闡述單個協議。

1.2.5. 瀏覽器發送郵件用的什麼協議
瀏覽器如IE、Maxthon可經過登錄用戶郵箱，來收發郵件，這是怎樣實現的？例如bripengandre@126.com可經過登錄www.126.com來收發郵件。

這個過程是這樣的：bripengandre@126.com在www.126.com提供的郵件頁面上填寫的相應信息（如發信人郵箱、收信人郵箱等），經過http協議被提交給126服務器；126服務器根據這些信息組裝一封符合郵件規範的郵件（就像用戶代理同樣）；而後smtp.126.com經過SMTP協議將這封郵件發送到接收端郵件服務器。

能夠看出，瀏覽器發送郵件只是用戶代理的功能直接放到郵件服務器上去作了，至於郵件服務器間發送郵件仍是採用的SMTP協議。咱們看問題，若是有必要仍是要適當地透過現象看本質。

1.3. 郵件的收發過程
通常狀況下，一封郵件的發送和接收過程以下。

1) 發信人在用戶代理裏編輯郵件，包括填寫發信人郵箱、收信人郵箱和郵件標題等等。

2) 用戶代理提取發信人編輯的信息，生成一封符合郵件格式標準（RFC822）的郵件。

3) 用戶代理用SMTP將郵件發送到發送端郵件服務器（即發信人郵箱所對應的郵件服務器）。

4) 發送端郵件服務器用SMTP將郵件發送到接收端郵件服務器（即收信人郵箱所對應的郵件服務器）。

5) 收信人調用用戶代理。用戶代理用POP3協議從接收端郵件服務器取回郵件。

6) 用戶代理解析收到的郵件，以適當的形式呈如今收信人面前。

第2章. SMTP詳解

<SMTP工做原理>
SMTP，即簡單郵件傳送協議，所對應RFC文檔爲RFC821。同http等多數應用層協議同樣，它工做在C/S模式下，用來實現因特網上的郵件傳送。SMTP在整個電子郵件通訊中所處的位置如圖 1所示。

能夠看出，SMTP是用來將客戶機上的郵件傳送到服務器上。這裏的客戶機是指某次鏈接中的發送方，服務器是指相應的接收方。在講解發送郵件的整個通訊過程前，先解釋一下面幾個術語。
2.1. 通訊過程
一個具體的SMTP通訊（如發送端郵件服務器與接收端服務器的通訊）的過程以下。

1) 發送端郵件服務器（如下簡稱客戶端）與接收端郵件服務器（如下簡稱服務器）的25號端口創建TCP鏈接。

2) 客戶端向服務器發送各類命令，來請求各類服務（如認證、指定發送人和接收人）。

3) 服務器解析用戶的命令，作出相應動做並返回給客戶端一個響應。

4) 2)和3)交替進行，直到全部郵件都發送完或二者的鏈接被意外中斷。

從這個過程看出，命令和響應是SMTP協議的重點，下面將予以重點講述。

2.2. 命令和響應
2.2.1. 格式
SMTP的命令很少（14個），它的通常形式是：COMMAND [Parameter] <CRLF>。其中COMMAND是ASCII形式的命令名，Parameter是相應的命令參數，<CRLF>是回車換行符(0DH, 0AH)。

SMTP的響應也不復雜，它的通常形式是：XXX Readable Illustration。XXX是三位十進制數；Readable Illustration是可讀的解釋說明，用來代表命令是否成功等。XXX具備以下的規律：以2開頭的表示成功，以4和5開頭的表示失敗，以3開頭的表示未完成（進行中）。

2.2.2. 一個例子
命令和響應的格式是語法，各命令和響應的意思則是語義，各命令和各響應在時間上的關係則是同步。下面將經過一個簡單的SMTP通訊過程來講明協議的這三個要素。

C：telnet smtp.126.com 25 /　以telnet方式鏈接126郵件服務器　/

S：220 126.com Anti-spam GT for Coremail System (126com[071018])　/ 220爲響應數字，其後的爲歡迎信息，會應服務器不一樣而不一樣/

C：HELO smtp.126.com / HELO 後用來填寫返回域名（具體含義請參閱RFC821），但該命令並不檢查後面的參數/

Ｓ：250 OK

C: MAIL FROM: bripengandre@126.com / 發送者郵箱 /

S：250 … ./ 「…」表明省略了一些可讀信息 /

C：RCPT TO: bripengandre@smail.hust.edu.cn　/ 接收者郵箱 /

S：250 … ./ 「…」表明省略了一些可讀信息 /

C：DATA / 請求發送數據 /

S：354 Enter mail, end with "." on a line by itself

C：Enjoy Protocol Studing

C：.

S：250 Message sent

C：QUIT / 退出鏈接 /

S：221 Bye

分析上面的過程可參考註釋進行，這裏要補充以下幾點。

1) 「C：」開頭的行(不包括"C：")是客戶端的輸入，而以「S：」開頭的行(不包括"S：")則是服務器的輸出。

2) 上述的命令並不必定會一次性成功，服務器會返回錯誤響應，客戶端應該按照協議規定的時序，來輸入後續的命令（或重複執行失敗的命令，或重置會話，或退出會話等等）。

2.2.3. 經常使用命令
SMTP命令不區分大小寫，但參數區分大小寫，有關這方面的詳細說明請參考RFC821。經常使用的命令以下。

HELO <domain> <CRLF>。向服務器標識用戶身份發送者能欺騙，說謊，但通常狀況下服務器都能檢測到。

MAIL FROM: <reverse-path> <CRLF>。<reverse-path>爲發送者地址，此命令用來初始化郵件傳輸，即用來對全部的狀態和緩衝區進行初始化。

RCPT TO：<forward-path> <CRLF>。　<forward-path>用來標誌郵件接收者的地址，經常使用在MAIL FROM後，能夠有多個RCPT TO。

DATA <CRLF>。將以後的數據做爲數據發送，以<CRLF>.<CRLF>標誌數據的結尾。

REST <CRLF>。重置會話，當前傳輸被取消。

NOOP <CRLF>。要求服務器返回OK應答，通常用做測試。

QUIT <CRLF>。結束會話。

VRFY <string> <CRLF>。驗證指定的郵箱是否存在，因爲安全方面的緣由，服務器大多禁止此命令。

EXPN <string> <CRLF>。驗證給定的郵箱列表是否存在，因爲安全方面的緣由，服務器大多禁止此命令。

HELP <CRLF>。查詢服務器支持什麼命令。

2.2.4. 經常使用響應
經常使用的響應以下所示，數字後的說明是從英文譯過來的。更詳細的說明請參考RFC821。

501參數格式錯誤

502命令不可實現

503錯誤的命令序列

504命令參數不可實現

211系統狀態或系統幫助響應

214幫助信息

220＜domain＞服務就緒

221＜domain＞服務關閉

421＜domain＞服務未就緒，關閉傳輸信道

250要求的郵件操做完成

251用戶非本地，將轉發向＜forward-path＞

450要求的郵件操做未完成，郵箱不可用

550要求的郵件操做未完成，郵箱不可用

451放棄要求的操做；處理過程當中出錯

551用戶非本地，請嘗試＜forward-path＞

452系統存儲不足，要求的操做未執行

552過量的存儲分配，要求的操做未執行

553郵箱名不可用，要求的操做未執行

354開始郵件輸入，以"."結束

554操做失敗

轉自：http://www.javashuo.com/article/p-rfwjddbb-hd.html
轉自：http://univasity.iteye.com/blog/1173296