第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) （C語言中\r\n）
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。