1、SMTP協議簡介

SMTP稱為簡單郵件傳輸協議（Simple Mail Transfer Protocal），目標是向用戶提供高效、可靠的郵件傳輸。它的一個重要特點是它能夠在傳送中接力傳送郵件，即郵件可以通過不同網路上的主機接力式傳送。通常它工作在兩種情況下：一是郵件從客戶機傳輸到伺服器；二是從某一個伺服器傳輸到另一個伺服器。SMTP是一個請求/響應協議，它監聽25號埠，用於接收使用者的Mail請求，並與遠端Mail伺服器建立SMTP連線。

2、SMTP協議工作機制

SMTP通常有兩種工作模式。傳送SMTP和接收SMTP。具體工作方式為：傳送SMTP在接收到使用者的郵件請求後，判斷此郵件是否為本地郵件，若是直接投送到使用者的郵箱，否則向DNS查詢遠端郵件伺服器的MX記錄，並建立與遠端接收SMTP之間的一個雙向傳送通道，此後SMTP命令由傳送SMTP發出，由接收SMTP接收，而應答則反方向傳送。一旦傳送通道建立，SMTP傳送者傳送MAIL命令指明郵件傳送者。如果SMTP接收者可以接收郵件則返回OK應答。SMTP傳送者再發出RCPT命令確認郵件是否接收到。如果SMTP接收者接收，則返回OK應答；如果不能接收到，則發出拒絕接收應答（但不中止整個郵件操作），雙方將如此反覆多次。當接收者收到全部郵件後會接收到特別的序列，入伏哦接收者成功處理了郵件，則返回OK應答。

3、SMTP的連線和傳送過程

（a）建立TCP連線

（b）客戶端傳送HELO命令以標識發件人自己的身份，然後客戶端傳送MAIL命令；

         伺服器端正希望以OK作為響應，表明準備接收

（c）客戶端傳送RCPT命令，以標識該電子郵件的計劃接收人，可以有多個RCPT行；

         伺服器端則表示是否願意為收件人接收郵件

（d）協商結束，傳送郵件，用命令DATA傳送

（e）以.表示結束輸入內容一起傳送出去

（f）結束此次傳送，用QUIT命令退出

示例如下：

1. C: telent SMTP.163.com 25  //以telenet方式連線163郵件伺服器  
2. S: 220 163.com Anti-spam GT for Coremail System //220為響應數字，其後的為歡迎資訊  
3. C: HELO SMTP.163.com //除了HELO所具有的功能外，EHLO主要用來查詢伺服器支援的擴充功能   
4. S: 250-mail  
5. S: 250-AUTH LOGIN PLAIN  
6. S: 250-AUTH=LOGIN PLAIN  
7. S: 250 8BITMIME //最後一個響應數字應答碼之後跟的是一個空格，而不是'-'   
8. C: AUTH LOGIN   //請求認證  
9. S: 334 dxNlcm5hbWU6  //伺服器的響應——經過base64編碼了的“Username”=  
10. C: Y29zdGFAYW1heGl0Lm5ldA==  //傳送經過BASE64編碼了的使用者名稱  
11. S: 334 UGFzc3dvcmQ6  //經過BASE64編碼了的"Password:"=  
12. C: MTk4MjIxNA==  //客戶端傳送的經過BASE64編碼了的密碼  
13. S: 235 auth successfully  //認證成功   
14. C: MAIL FROM: [email protected]  //傳送者郵箱  
15. S: 250 … .  //“…”代表省略了一些可讀資訊  
16. C: RCPT TO: [email protected]　//接收者郵箱  
17. S: 250 … .    // “…”代表省略了一些可讀資訊  
18. C: DATA //請求傳送資料  
19. S: 354 Enter mail, end with "." on a line by itself  
20. C: Enjoy Protocol Studing  
21. C: .  
22. S: 250 Message sent  
23. C: QUIT //退出連線   
24. S: 221 Bye  

其他命令：

VRFY——用於驗證給定使用者郵箱是否存在，以及接收關於該使用者的詳細資訊；

EXPN——用於擴充郵件列表

4、郵件的路由過程

SMTP伺服器是基於“域名服務DNS中計劃收件人的域名來路由電子郵件”。SMTP伺服器基於DNS中的MX記錄來路由電子郵件，MX記錄註冊了域名和相關的SMTP中的主機，屬於該域的電子郵件都應向該主機發送。

若SMTP伺服器mail.abc.com收到一封信要傳送到[email protected]：

a: SendMail請求DNS給出主機sh.abc.com的CNAME記錄，如有，假若CNAME到shmail.abc.com，則再次請求shmail.abc.com的CNAME記錄，直到沒有為止；

b: 假定被CNAME到shmail.abc.com，然後SendMail請求@abc.com域的DNS給出shmail.abc.com的MX記錄，

    shmail MX 5 shmail.abc.com

    10 shmail2.abc.com

c: SendMail做好請求DNS給出shmail.abc.com的A記錄，即IP地址，若返回值為1.2.3.4

d: SwndMail與1.2.3.4連線，傳送這封信給[email protected]的信到1.2.3.4這臺伺服器的SMTP後臺程式。

5、SMTP常用的命令

SMTP命令不區分大小寫，但引數區分大小寫。常用命令如下：

HELO <domain> <CRLF>——向伺服器標識使用者身份傳送者能欺騙、說謊，但一般情況下伺服器都能檢測到

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>——查詢伺服器支援什麼命令

6、SMTP常用的響應

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——操作失敗

7、使用SMTP的必要性

一般的PC資源不夠，處理能力不夠，不可能全天候地連線在因特網上來收發郵件。所以使用SMTP伺服器，可以讓多個使用者共用伺服器，有效地降低了成本。

8、SMTP和郵件格式的關係

可以用一個比較形象的例子來說明：甲與乙書信來往，甲通過郵局向乙傳送信件，郵局見轉交郵件可看成使用了SMTP協議，至於書信的格式則會因為地區習慣等的不同而不同，這個書信格式可看成是郵件格式的標準。

9、瀏覽器傳送郵件使用的協議

瀏覽器傳送郵件的過程：

例如：[email protected]可通過登陸www.126.com來收發郵件

[email protected]在www.126.com提供的郵件頁面上填寫的相應資訊（如發信人郵箱、收信人郵箱等），通過http協議被提交給126伺服器；126伺服器根據這些資訊組裝一封符合郵件規範的郵件（就像使用者代理一樣）；然後smtp.126.com通過SMTP協議將這封郵件傳送到接收端郵件伺服器。

由此可知，瀏覽器傳送郵件只是使用者代理的功能直接放到郵件伺服器上去做了，至於郵件伺服器見傳送郵件仍然採用的是SMTP協議。

SMTP協議分析

第1章.     SMTP概述

1.1.  SMTP在郵件通訊中的位置

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

圖1電子郵件的通訊過程

可以看出，SMTP是用來將客戶機上的郵件傳送到伺服器上。這裡的客戶機是指某次連線中的傳送方，伺服器是指相應的接收方。在講解發送郵件的整個通訊過程前，先解釋一下面幾個術語。

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.3.  郵件的收發過程

一般情況下，一封郵件的傳送和接收過程如下。

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

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

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

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

5)        收信人呼叫使用者代理。使用者代理用POP3協議從接收端郵件伺服器取回郵件。

6)        使用者代理解析收到的郵件，以適當的形式呈現在收信人面前。

第2章.     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: [email protected] /* 傳送者郵箱 */

S：250 … ./* “…”代表省略了一些可讀資訊 */

C：RCPT TO: [email protected]　/* 接收者郵箱 */

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操作失敗

第3章.     SMTP的擴充

3.1.  SMTP的缺點

從2.2.2的例子可以看出，SMTP至少還有如下缺點。

1)        命令過於簡單，沒提供認證等功能。

2)        只傳送7位的ASCII碼，不能傳送二進位制檔案。

針對缺點1)，標準化組織制定了擴充的SMTP（即ESMTP），對應的RFC文件為RFC1425。針對缺點2)，標準化組織在相容SMTP的前提下，提出了傳送非7位ASCII碼的方法，對應的RFC文件有兩個：郵件首部的擴充對應於RFC1522，郵件正文的擴充對應與RFC1521（即MIME）。

3.2.  ESMTP

ESMTP最顯著的地方是添加了使用者認證功能。如果使用者想使用ESMTP提供的新命令，則在初次與伺服器互動時，傳送的命令應該是EHLO而不是HELO。先來看一個例子。

C：telnet smtp.126.com 25   /*　以telnet方式連線126郵件伺服器　*/

S：220 126.com Anti-spam GT for Coremail System (126com[071018])　/* 220為響應數字，其後的為歡迎資訊，會應伺服器不同而不同*/

C：EHLO smtp.126.com /* 除了HELO所具有的功能外，EHLO主要用來查詢伺服器支援的擴充功能 */

S：250-mail

S：250-AUTH LOGIN PLAIN

S：250-AUTH=LOGIN PLAIN

S：250 8BITMIME /* 最後一個響應數字應答碼之後跟的是一個空格，而不是'-' */

C：AUTH LOGIN /* 請求認證 */

S：334 dxNlcm5hbWU6  /* 伺服器的響應——經過base64編碼了的“Username” */

C：Y29zdGFAYW1heGl0Lm5ldA==  /* 傳送經過BASE64編碼了的使用者名稱 */

S：334 UGFzc3dvcmQ6  /* 經過BASE64編碼了的"Password:" */

C：MTk4MjIxNA==  /* 客戶端傳送的經過BASE64編碼了的密碼 */

S：235 auth successfully　/* 認證成功 */

C: MAIL FROM: [email protected] /* 傳送者郵箱 */

S：250 … ./* “…”代表省略了一些可讀資訊 */

C：RCPT TO: [email protected]　/* 接收者郵箱 */

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)        只是一個示意性的過程，再輸入使用者名稱、密碼時需採用base64編碼，這需要專門的計算，所以在telnet終端上模擬比較麻煩。

2)        認證過程有很多種，有基於明文的認證，也有基於MD5加密的認證，這裡給出的只是一個示意性的過程。

3)        EHLO對於具體伺服器，響應會不同，關鍵字“8BITMIME”用來說明伺服器是否支援正文中傳送８位ASCII碼，而以“X”開頭的關鍵字都是指伺服器自定義的擴充（還沒納入RFC標準）

更詳細的說明，請參看RFC1425。

3.3.  郵件首部的擴充

首部通過兩種編碼方式來支援傳送非7位ASCII碼。它首先通過一個如下格式的編碼字來表明所用的編碼方式。

=?charset?encoding?encoded-text?text

charset是字符集規範。有效值是兩個字串us-ascii和iso-8859-x，其中x 是一個單個數字，例如iso-8859-1中的數字為“ 1”。

encoding是一個單個字元用來指定編碼方法，支援兩個值。

Q代表quoted-printable（可列印）編碼。任何要傳送的字元若其第8位元置1則被作為3個字元傳送：第1個是字元是“=”，後面的兩個字元對應於字元的十六進位制表示。例如對於二進位制碼11111111，其對應的十六進位制表示為“FF”，所以對應的編碼位“=FF”。為了能夠傳輸“=”，“=”的編碼方式與第８位元置１的字元相同，因為其二進位制程式碼為00111101，所以對應的編碼為“=3D”。可以看出這種編碼方式的開銷達200%，所以只適合傳送只含有少量非7位ASCII碼的文字。

B代表base64編碼。它的編碼方法是先將二進位制程式碼劃分為一個24bit長的單元，然後將這24 bit單元劃分為4個6 bit組。每個組按圖 2所示的方法轉換成ASCII碼。

圖2　base64對映表

可以看出這種對映方法是這樣的：0-25依次對映成A-Z，26-51依次對映成a-z,52-61依次對映成數字0-9，然後62對映成+，63對映成/。

對於二進位制程式碼01001001 00110001 01111001，先將其劃分成4個6 bit組，即010010 0100011 000101 111001。接著按圖 2所示的對映表，可得到base64編碼為：STF5。可以看出，這種編碼方式的開銷是25%，相對quoted-printable編碼來說，它更適合用來傳送含大量非7位ASCII碼的二進位制檔案。

3.4.  正文的擴充

正文的擴充主要是使正文不僅可以傳輸NVT ASCII字元，而且可以傳輸任意字元，對應的文件為RFC1511（即MIME）。

MIME全稱為“Multiple Internet Mail Extensions”, 比較確切的中文名稱為“多用途網際網路郵件擴充套件”。它通過新增一些郵件首部欄位、郵件內容格式和傳送編碼，使得其成為一種應用很廣泛的可以傳輸多媒體的電子郵件規範。

更詳細的說明請參看另一篇文章《MIME協議分析》和RFC1511。

第4章.     常見的疑問

4.1.  為什麼需要SMTP伺服器

一般的PC資源不夠，處理能力不夠，不可能全天候地連線在因特網上來收發郵件。所以使用SMTP伺服器，可以讓多個使用者共用伺服器，有效地降低了成本。

4.2.  SMTP和郵件格式的關係

如前所述，SMTP是客戶機向伺服器傳送郵件時所使用的協議，其核心是2.2中所述的命令和響應，至於它命令和響應中所帶的引數採用什麼格式，則是依賴於其他標準的。例如DATA後所帶的引數，則應遵循郵件格式標準RFC822．

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

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

4.3.  瀏覽器傳送郵件用的什麼協議

瀏覽器如IE、Maxthon可通過登陸使用者郵箱，來收發郵件，這是怎樣實現的？例如[email protected]可通過登陸www.126.com來收發郵件。

這個過程是這樣的：[email protected]在www.126.com提供的郵件頁面上填寫的相應資訊（如發信人郵箱、收信人郵箱等），通過http協議被提交給126伺服器；126伺服器根據這些資訊組裝一封符合郵件規範的郵件（就像使用者代理一樣）；然後smtp.126.com通過SMTP協議將這封郵件傳送到接收端郵件伺服器。

可以看出，瀏覽器傳送郵件只是使用者代理的功能直接放到郵件伺服器上去做了，至於郵件伺服器間傳送郵件還是採用的SMTP協議。我們看問題，如果有必要還是要適當地透過現象看本質。

4.4.  如何用實驗驗證SMTP的通訊過程

1)        可以通過ethereal等協議分析軟體來抓包分析協議。

2)        可以利用socket程式設計實現SMTP的通訊過程。

3)        可以利用使用者代理來檢視一封郵件的原始編碼。例如在Foxmail中，可以選擇郵件列表右鍵選單的“原始資訊”進行檢視。

第5章.     分析方案

表1 協議分析要求

表 1給出了協議分析要求。容易看出，獲取各個欄位是比較容易的。我們可以抓取客戶端與伺服器端的互動資訊，然後根據各命令字或響應字來提取出我們想要的欄位。例如，要獲取user name，我們只需檢測到伺服器端要求客戶端傳送使用者名稱這個時候，然後提取這之後客戶端的傳送資訊即可。需要說明的是，雖然客戶端與服務端互動的資訊可能經過了編碼或加密，但我們仍能夠通過解碼或解密來獲得所需要的資訊。

第6章.     參考資料

[1]      RFC文件：RFC821對應SMTP協議，RFC822對應郵件標準，RFC1425對應ESMTP，RFC1522對應郵件首部的擴充，RFC1521對應郵件正文的擴充，RFC1939對應POP3協議。

[2]      http://www.faqs.org/rfcs/，上面有全面的英文RFC文件

[3]      http://www.cnpaf.net/，上面有不少有用的協議分析文件，也有中文RFC文件，但質量不是特別高

[4]      Stevens, W.R., TCP/IP Illustrated, Vol1. Addision-Wesley, 機械工業出版社，2002