SMTP協議是TCP/IP協議族中的一員，主要對如何將電子郵件從發送方地址傳送到接收方地址，也即是對傳輸的規則做了規定。SMTP協議的通信模型并不復雜，主要工作集中在發送SMTP和接收SMTP上：首先針對用戶發出的郵件請求，由發送SMTP建立一條連接到接收SMTP的雙工通訊鏈路，這里的接收SMTP是相對于發送SMTP而言的，實際上它既可以是最終的接收者也可以是中間傳送者。發送SMTP負責向接收SMTP發送SMTP命令，而接收SMTP則負責接收并反饋應答。可大致用下面的通訊模型示意圖來表示：
從前面的通訊模型可以看出SMTP協議在發送SMTP和接收SMTP之間的會話是靠發送SMTP的 SMTP命令和接收SMTP反饋的應答來完成的。在通訊鏈路建立后，發送SMTP發送MAIL命令指令郵件發送者，若接收SMTP此時可以接收郵件則作出OK的應答，然后發送SMTP繼續發出RCPT命令以確認郵件是否收到，如果接收到就作出OK的應答，否則就發出拒絕接收應答，但這并不會對整個郵件操作造成影響。雙方如此反復多次，直至郵件處理完畢。SMTP協議共包含10個SMTP命令，列表如下：
| SMTP命令 | 命令說明 |
| HELLO ＜domain＞ ＜CRLF＞ | 識別發送方到接收SMTP的一個HELLO命令 |
| MAIL FROM:＜reverse-path＞＜CRLF＞ | ＜reverse-path＞為發送者地址。此命令告訴接收方一個新郵件發送的開始，并對所有的狀態和緩沖區進行初始化。此命令開始一個郵件傳輸處理，最終完成將郵件數據傳送到一個或多個郵箱中。 |
| RCPT TO:＜forward-path＞＜CRLF＞ | ＜forward-path＞標識各個郵件接收者的地址 |
| DATA ＜CRLF＞ |
接收SMTP將把其后的行為看作郵件數據去處理，以＜CRLF＞.＜CRLF＞標識數據的結尾。 |
| REST ＜CRLF＞ | 退出/復位當前的郵件傳輸 |
| NOOP ＜CRLF＞ | 要求接收SMTP僅做OK應答。（用于測試） |
| QUIT ＜CRLF＞ | 要求接收SMTP返回一個OK應答并關閉傳輸。 |
| VRFY ＜string＞ ＜CRLF＞ | 驗證指定的郵箱是否存在，由于安全因素，服務器多禁止此命令。 |
| EXPN ＜string＞ ＜CRLF＞ | 驗證給定的郵箱列表是否存在，擴充郵箱列表，也常禁止使用。 |
| HELP ＜CRLF＞ | 查詢服務器支持什么命令 |
注：＜CRLF＞為回車、換行，ASCII碼分別為13、10（十進制）。
SMTP協議的每一個命令都會返回一個應答碼，應答碼的每一個數字都是有特定含義的，如第一位數字為2時表示命令成功；為5表失敗；3表沒有完成。一些較復雜的郵件程序利用該特點，首先檢查應答碼的首數字，并根據其值來決定下一步的動作。下面將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 | 操作失敗 |
SMTP協議的會話流程
在進行程序設計之前有必要弄清SMTP協議的會話流程，其實前面介紹的內容已經可以大致勾勒出用SMTP發送郵件的框架了，對于一次普通的郵件發送，其過程大致為：先建立TCP連接，隨后客戶端發出HELLO命令以標識發件人自己的身份，并繼續由客戶端發送MAIL命令，如服務器應答為"OK"，可繼續發送RCPT命令來標識電子郵件的收件人，在這里可以有多個RCPT行，而服務器端則表示是否愿意為收件人接受該郵件。在雙方協商結束后，用命令DATA將郵件發送出去，其中對表示結束的"."也一并發送出去。隨后結束本次發送過程，以QUIT命令退出。下面通過一個實例，從langrui@sohu.com發送郵件到renping@sina.com來更詳細直觀地描述此會話流程：
|
R:220 sina.com Simple Mail Transfer Service Ready
S:HELLO sohu.com R:250 sina.com S:MAIL FROM:＜langrui@sohu.com＞ R:250 OK S:RCPT TO:＜renping@sina.com＞ R:250 OK S:DATA R:354 Start mail input;end with "＜CRLF＞.＜CRLF＞" S:…… R:250 OK S:QUIT R:221 sina.com Service closing transmission channel |
郵件的格式化
由于電子郵件結構上的特殊性，在傳輸時是不能當作簡單的文本來直接處理的，而必須按照一定的格式對郵件頭和郵件體進行格式化處理之后才可以被發送。需要進行格式化的部分主要有：發件人地址、收件人地址、主題和發送日期等。在RFC文檔的RFC 822里對郵件的格式化有詳盡的說明，有關詳情請參閱該文檔。下面通過VC++6.0按照RFC 822文檔規定將格式化郵件的部分編寫如下（部分代碼）：
|
//郵件頭準備
strTemp = _T( "From: " ) + m_strFrom; file://發件人地址 add_header_line( (LPCTSTR)strTemp ); strTemp = _T( "To: " ) + m_strTo; file://收件人地址 add_header_line( (LPCTSTR)strTemp ); m_tDateTime = m_tDateTime.GetCurrentTime();//發送時間 strTemp = _T( "Data: " ); strTemp += m_tDateTime.Format( "%a, %d %b %y %H:%M:%S %Z" ); add_header_line( (LPCTSTR)strTemp ); strTemp = _T( "Subject: " ) + m_strSubject; file://主題 add_header_line( (LPCTSTR)strTemp ); file://郵件頭結束 m_strHeader += _T( ""r"n" ); file://郵件體準備 if( m_strBody.Right( 2 ) != _T( ""r"n" ) ) file://確認最后以回車換行結束 m_strBody += _T( ""r"n" ); |
其中add_header_line(LPCTSTR szHeaderLine)函數用于把szHeaderLine指向的字串追加到m_strHeader后面。其中，格式化后的郵件頭保存在m_strHeader里，格式化后的郵件體保存在m_strBody中。
由Socket套接字為SMTP提供網絡通訊基礎
許多網絡程序都是采用Socket套接字實現的，對于一些標準的網絡協議如HTTP、FTP和SMTP等協議的編程也是基于套接字程序的，只是端口號不再是隨意設定而要由協議來指定，比如HTTP端口在80、FTP是21，而SMTP則是25。Socket只是提供在指定的端口上同指定的服務器從事網絡上的通訊能力，至于客戶和服務器之間是如何通訊的則由網絡協議來規定，這對于套接字是完全透明的。因此可以使用Socket套接字為程序提供網絡通訊的能力，而對于網絡通訊連路建立好之后采取什么樣的通訊應答則要按SMTP協議的規定去執行了。Socket套接字網絡編程方面的文章資料非常豐富，限于本文篇幅，在此不再贅述，有關詳情請參閱相關文檔。為簡便起見，沒有采用編寫較復雜的Windows Sockets API進行編程，而是使用經過較好封裝的MFC 的CSocket類。在正式使用套接字之前，也要先用AfxSocketInit()函數對套接字進行初始化，然后用Create()創建套接字對象，并由該套接字通過Connect（）建立同郵件服務器的連接。如果一切正常，再后續的工作中就是遵循SMTP協議的約定來使用Send（）、Receive()函數來發送SMTP命令和接收郵件服務器發來的應答碼以完成對郵件的傳送。
|
|
|
POP3協議命令原始碼及工作原理
dele 3
|
HTTP服務器與HTTP客戶機之間的會話如下：
1客戶機與服務器建立聯系
與服務器建立連接，就是與SOCKET建立連接，因此要指定機器名稱、資源名稱和斷口號，可以通過URL來提供這些信息。URL的格式為：
HTTP：//<IP地址>/[端口號]/[路徑][?<查詢信息>]
資源的缺省值是INDEX或DEFAULT,斷口號缺省為80.
2客戶向服務器提出請求
請求信息包括希望返回的文件名和客戶機信息.客戶機信息以請求頭發送給服務器,請求頭包括HTTP方法和頭字段.
HTTP方法常用的有GET、HEAD、POST，而PUT、DELETE、LINK、UNLINK方法
許多HTTP服務器都不使用。
頭字段包括：
。DATE：請求發送的日期和時間
。PARGMA：用于向服務器傳輸與實現無關的信息。這個字段還用于告訴代理服
務器，要從實際服務器而不是從高速緩存取資源
。FORWARDED：可以用來追蹤機器之間，而不是客戶機和服務器的消息。這個字段
可以用來追蹤在代理服務器之間的傳遞路由。
。MESSAGE_ID:用于唯一地標識消息
。ACCEPT：通知服務器客戶所能接受的數據類型和尺寸。（*/*表示可以接受
所有類型的數據。
。AOTHORIZATION：向服務器提供旁路安全保護和加密機制，若服務器
不需要這個字段，則不提供這個字段
。FROM：當客戶應用程序希望想服務器提供有關其電子郵件地址時使用
。IF-MODEFIED-SINCE用于提供條件GET。如果所請求的文檔自從所指定
的日期以來沒有發生變化，則服務器應不發送該對象。如果所發送的日期格式不合
法，或晚于服務器的日期，服務器會忽略該字段
。BEFERRER：向服務器進行資源請求用到的對象
。MIME-VERTION：用于處理不同類型文件的MIME協議版本號
。USER-AGENT：有關發出請求的客戶信息
3服務器對請求作出應答
服務器收到一個請求，就會立刻解釋請求中所用到的方法，并開始處理應答。
服務器的應答消息也包含頭字段形式的報文信息。
。報文第一行是狀態行，格式為<HTTP版本號><狀態代碼><解釋短語>
狀態碼是個三位數字碼，分為四類：
。以2開頭，表示請求被成功處理
。以3開頭，表示請求被重定向
。以4開頭，表示客戶的請求有錯
。以5開頭，表示服務器不能滿足請求
解釋短語是對狀態碼的解釋。
。報文還向客戶返回幾個頭字段，如：
。STATUSCODE/REASONPHRASE
。DATE
。LAST-MODIFIED
。SERVER
。CONTENT_TYPE
。RETRY_AFTER：服務器太忙時返回這個字段
。WWW_AUTHENTICATE：當服務器的安全機制要求客戶發送某中授權信息時使用該字段
。報文最后是實體信息，即客戶請求得到的HTTP服務器上的資源內容。
4關閉客戶與服務器之間的連接
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
