一：前言
如果說Web瀏覽是用戶參與次數最多的網絡活動，那麼收發郵件有可能是第二位。簡單郵件傳輸協議（SMTP）是發送郵件的標準，它被Microsoft Exchange 和Postfix等平臺使用
與HTTP一樣，SMTP由於實現方式、與客戶端/服務器兼容性相關的一些列特性的不同，在數據包結構上存在多樣性。本文只是通過在數據包層面，對郵件發送過程進行分析，來探究SMTP的一些基本功能
二：收發郵件
郵件服務架構與郵政服務類似。發信方寫了一封郵件，然後將郵件投入發信方的郵箱；郵遞員將郵件取走，並將郵件送到郵局進行分揀。從這個郵局出發，這封郵件將被投遞至由此郵局提供服務的另一個郵箱，或者轉發至另一個負責投遞這封郵件的郵局。一封郵件在投遞過程中，可能會通過多個郵局，甚至是通過專門用於特定地域內郵局間投遞的“Hub”郵局
電子郵件投遞與上面的過程非常類似，對於個人來說，電子郵箱取代了物理郵箱，爲此用戶提供郵件的存儲、發送和接受服務。用戶通過郵件用戶代理（MUA），如Microsoft Outlook訪問郵箱
當用戶發送郵件時，郵件將通過MUA發送至郵件傳輸代理（MTA），MTA通常指郵件服務器，流行的郵件服務器應用包括Microsoft Exchange 和Postfix。如果郵件的收件方和發件方域名相同，則MTA將直接發送郵件至收件人郵箱。如果郵箱被髮送至其他域名下的郵箱，則MTA將通過DNS找到對方的郵件服務器地址，並將郵件傳輸至該服務器。注意：郵件服務器通常還包含其他組件，如郵件發送代理（MDA）和郵件提交代理（MSA），但是從網絡的角度看，我們通常只關注客戶端和服務器的概念
三：跟蹤一封電子郵件
對電子郵件如何傳輸有了基本瞭解之後，查看一下這一過程中的數據包
以上場景分爲三個步驟
1 用戶從計算機 172.16.16.225 發送一封電子郵件，郵件客戶端使用SMTP協議，將郵件傳輸至本地郵件服務器（172.16.16.221）
2 本地郵件服務器接收郵件，並使用SMTP將其傳輸至遠程郵件服務器（172.16.16.231）
3 遠程郵件服務器接收郵件，並將其與適當的郵箱相關聯。收件方計算機（172.16.16.235）上的郵件客戶端通過IMAP協議取回郵件
第一步：客戶端至本地郵件服務器
從用戶在郵件客戶端上點擊“發送”按鈕開始，用戶計算機和本地郵件服務器在前三個數據包中完成握手
連接建立後，客戶端使用SMTP將郵件發送至本地郵件服務器
（由於SMTP是一種簡單的傳輸協議，並且在這個例子通信過程爲明文傳輸，因此可以跟蹤TCP流）
郵件服務器在數據包4向客戶端發送一個服務標籤，表明此服務器已經準備好接受命令，本例中服務器顯示爲運行在Ubuntu Linux系統上的Postfix服務器（1）。同時，此服務器支持接受擴展SMTP（ESMTP）命令
郵件客戶端在數據包5中通過EHLO命令進行回覆（2）。當郵件服務器支持ESMTP時，EHLO作爲“Hello”命令，讓服務器識別發信的客戶端主機。在不支持ESMTP的情況下，使用HELO命令進行發信客戶端識別。本例中發信方使用IP地址作爲識別方式，當然，域名也可以作爲識別方式
在數據包7中，服務器回覆的內容包括 VRFY 、STARTTLS和SIZE 10240000。這些內容表示此SMTP服務器支持的命令，用於告知客戶端在郵件傳輸過程中可用的命令範圍。在發送郵件之前，這個特徵協商過程會發生在每次SMTP傳輸的開始部分。郵件傳輸從數據包8開始，這個抓包文件的剩餘的大部分均爲郵件傳輸過程的數據包
SMTP由客戶端發送的簡單命令和參數值控制，服務器會回覆相應的響應碼。這種設計是爲了協議簡化，與HTTP和Telnet相似。數據包8和數據包9是一組示例請求/回覆，客戶端發送了MAIL命令，參數爲FROM:<[email protected]> SIZE=556 （4）；服務器回覆的響應碼爲250（請求的郵件操作完成），參數爲2.1.0 Ok。在這次請求中，客戶端發送了發信方的郵箱地址和郵件大小，服務器響應說明數據已經被接收，並且格式正確。類似的傳輸過程也發生在數據包10和11；客戶端發送RCPT命令，參數爲TO:<[email protected]> （5），服務器響應爲250 2.1.5 Ok
剩餘的部分是傳輸郵件內容數據，如數據包12，客戶端使用命令DATA啓動郵件內容傳輸過程。服務器響應碼爲354，並附帶信息（6），其中響應碼354代表服務器爲這封郵件創建了緩衝區，客戶端可以開始郵件傳輸；附帶信息表示客戶端需要發送一個<CR><LF>.<CR><LF> 用於標記傳輸終止
這封郵件使用明文傳輸，並且響應碼錶示傳輸成功。郵件文本中包含着一些附加信息，包括日期、內容、用戶代理（7）
傳輸完成後，在數據包18中，郵件客戶端使用了不帶參數的QUIT命令，終止了SMTP連接。在數據包19中，服務器回覆響應碼221（傳輸通道關閉），附帶參數2.0.0 Bye（8），TCP連接在20-23中正常關閉
第二步：本地郵件服務器至遠程服務器
接下來從本地郵件服務器（172.16.16.221）的角度，考慮這個傳輸場景。分析數據包可以直接從郵件服務器上抓取
剛開始，本地服務器（172.16.16.221）和遠程服務器（172.16.16.231）完成TCP握手，並開始第2步傳輸過程
在現實場景中，郵件服務器通過一種特殊的DNS記錄類型——郵件交換（MX）記錄，定位其他的郵件服務器。在進行郵件發送故障檢查時，需要考慮DNS問題及與郵件相關的特定協議問題
連接建立完成後，郵件傳輸至遠程服務器的過程使用SMTP協議。跟蹤傳輸過程的TCP流，能夠查看這個會話過程（使用tcp.stream==1作爲篩選條件）
這個傳輸過程和上一次的傳輸過程基本一致。本質上，兩者的郵件內容一致，區別在於第一次的過程發生在客戶端和服務器之間。遠程服務器被標記爲mail02（1），本地郵件服務器被標記爲mail01（2），兩個服務器共享了一系列的可用命令（3）；郵件內容（4）包括上一次傳輸過程中的完整的郵件文本，以及附加在 To: Chris Sanders <[email protected]> 之前的部分
從根本上來說，服務器不關注郵件時來自於郵件客戶端還是來自另一個SMTP服務器，所以客戶端——服務器郵件傳輸中所有的規則和過程在服務器——服務器郵件傳輸過程中也都適用（任意形式的訪問控制策略除外）。在實際情況中，本地郵件服務器和遠程郵件服務器可能並不具備相同的特徵參數集合（包括命令集和參數集），或是基於完全不同的平臺。這也是SMTP要進行初始化通信的非常重要的原因；這一過程確保了在郵件傳輸之前，收件服務器要將自身支持的命令和參數集發送給發件方，從而完成傳輸使用命令的協商。在SMTP客戶端或服務器明確了收件服務器的特徵參數後，能夠保證發件方發送的SMTP命令被收件服務器識別，並且郵件能夠正常傳輸。這一機制使SMTP能夠在大量不同的客戶端和服務器之間應用，同時，也讓我們在發送郵件時，不需要了解收件方的網絡設備信息。
第三步：遠程郵件服務器至遠程客戶端
前15個數據包很熟悉，源地址爲本地郵件服務器，目的地址變成了遠程郵件服務器
這個流程完成後，SMTP服務將郵件和指定的郵箱關聯，之後，預期的收件方就可以是通過郵件客戶端收取郵件
正如之前提到的，SMTP最主要被用來發送郵件；從服務器上的郵件收取郵件的方式更加多樣，同時，由於在收取郵件事件中不斷有新的需求，因此出現了數種用於完成郵件收取任務的協議。比較流行的是郵局協議v3（POP3）和Internet郵件訪問協議（IMAP）。本例中，遠程客戶端使用IMAP從郵件服務器中收取郵件
在數據包21中，客戶端向服務器發送了 STARTTLS命令，這個命令告訴服務器，客戶端將使用TLS加密收取郵件，雙方在數據包24-27中建立了安全信道，在餘下的數據包中，使用TLS協議完成。當查看這些數據包，或者嘗試跟蹤TCP流時，內容不具有可讀性，目的是防止郵件被惡意用戶截獲，避免數據劫持和嗅探的發生，如下圖
最後，不同域內兩個用戶之間的郵件發送過程就完成了
四：使用SMTP發送附件
在設計SMTP時，從未計劃使其稱爲一種傳輸文件的途徑，但由於使用郵件發送文件的便捷性，因此，它成爲了很多人的首選文件共享方式，本例從數據包層面分析SMTP的文件傳輸過程
用戶使用客戶端（172.16.16.225）向同一網絡內另一個用戶發送郵件，本地SMTP服務器位於172.16.16.221。這封郵件包含一些文本內容，以及一個圖片文件附件
使用SMTP發送附件與發送文本沒有太多區別。它們都只是向服務器發送數據；儘管過程中經常使用一些特殊編碼，我們仍使用DATA命令進行數據傳送
本例的通信過程在開始部分與之前的場景類似，包括服務識別和可用協議信息交換。當客戶端準備傳輸郵件信息時，它會提供發件方地址和收件方地址，併發送DATA命令，通知服務器分配用於接受郵件數據的緩衝區
在之前的例子中，客戶端將文本直接傳輸至服務器，然後傳輸完成。在本例中，除了明文文本信息外，客戶端還需要發送圖片附件的二進制數據。爲了實現這個目的，客戶端將內容類型標記爲 multipart/mixed ，以 ------------050407080301000500070000 作爲文本信息和二進制數據的分界線。這告知服務器，傳輸的郵件內容包含多種類型的數據，每種數據類型有特定的MIME類型和編碼方式，各種類型的數據使用指定的邊界值分隔。通過這種機制，當另一個郵件客戶端接收郵件時，基於分界線和每個數據塊指定的MIME類型、編碼方式，接收端能夠知道如何解析郵件數據
本例中郵件數據包含兩部分。第一部分是郵件文本，內容類型爲 text/plain （2）。在此之後，能夠看到一個分隔標記和第二部分的起始。第二部分包含圖片文件，內容類型是 image/jpeg （4），Content-Transfer-Encoding 值設爲base64 ，這表示數據需要使用base64解碼。餘下的數據包包含編碼過的圖片文件
在任何情況下都不要將編碼方式和加密方式弄混。Base 64 編碼幾乎能夠被瞬間解碼，任何截獲這一通信的攻擊者能夠毫不費力地獲得此圖片文件