【正文】 使得軟件能夠符合有關(guān)的 WINDOWS 程序標(biāo)準(zhǔn)，并且有了清晰的結(jié)構(gòu)規(guī)劃，給維護(hù)帶來(lái)了方便。 2 SMTP 協(xié)議概述 協(xié)議簡(jiǎn)介 SMTP，簡(jiǎn)單郵件傳輸協(xié)議是 Simple Mail Transfer Protocol 的縮寫(xiě)。它是互聯(lián)網(wǎng)上的一種通訊協(xié)議，工作于應(yīng)用層，使用端口 為 25。主要功能就是傳送電子郵件，當(dāng)我們使用郵件程序，郵寄 EMail 給對(duì)方時(shí)，必須通過(guò) SMTP 協(xié)議，將郵件發(fā)送到對(duì)方的郵件服務(wù)器上，等待對(duì)方查收。 SMTP 協(xié)議的目標(biāo)是可靠高效地傳送郵件，它獨(dú)立于傳送子系統(tǒng)而且僅要求一條可以保證傳送數(shù)據(jù)單元順序的通道。 SMTP 的一個(gè)重要特點(diǎn)是它能夠在傳送中接力傳送郵件，傳送服務(wù)提供了進(jìn)程間通信環(huán)境（ IPCE），此環(huán)境可以包括一個(gè)網(wǎng)絡(luò)，幾個(gè)網(wǎng)絡(luò)或一個(gè)網(wǎng)絡(luò)的子網(wǎng)。理解到傳送系統(tǒng)（或 IPCE）不是一對(duì)一的是很重要的。進(jìn)程可能直接和其它進(jìn)程通過(guò)已知的 IPCE 通信。郵件是一個(gè)應(yīng)用程 序或進(jìn)程間通信。郵件可以通 過(guò)連接在不同 IPCE(Interprocess Communication Environment)上的進(jìn)程跨網(wǎng)絡(luò)進(jìn)行郵件傳送。更特別的是，郵件可以通過(guò)不同網(wǎng)絡(luò)上的主機(jī)接力式傳送。 協(xié)議原理 從 1982 年到現(xiàn)在， SMTP 協(xié)議及其相關(guān)的協(xié)議已經(jīng)發(fā)展成一個(gè)比較完整的體系，不再是建立之初那個(gè)只能傳送文本消息的簡(jiǎn)單協(xié)議。協(xié)議制定者制定了一系 列的相關(guān)協(xié)議，如：有關(guān)認(rèn)證的部分和附件傳送部分等。相關(guān)文檔也由最初的RFC821 文檔，擴(kuò)展為目前的 RFC282 RFC2045－ 204 RFC2554 等多個(gè)。目前按照郵件協(xié)議的規(guī)定已經(jīng)不僅僅能夠傳送文本，而且能夠傳送文件，網(wǎng)頁(yè)以及多媒體信息。但基本的操作模式?jīng)]有變化，只是增加了相關(guān)的命令和格式。郵件傳送的模型，沒(méi)有變化。以下就以 RFC821 文檔中規(guī)定描述有關(guān)的內(nèi)容。 工作模型 SMTP 設(shè)計(jì)基于以下通信模型：針對(duì)用戶的郵件請(qǐng)求，發(fā)送 SMTP 建立與接收SMTP 之間建立一個(gè)雙向的傳送通道，用于發(fā)送與接收 SMTP 的命令與應(yīng)答碼。其中接收 SMTP 可以是最終接受者也可以是中間傳送者。 SMTP 命令由發(fā)送 SMTP 發(fā)出，由接收 SMTP 接收，而應(yīng)答則 反方向傳送。 一旦傳送通道建立， SMTP 發(fā)送者發(fā)送 MAIL 命令指明郵件發(fā)送者。如果 SMTP接受者可以接收郵件則返回 OK 應(yīng)答。 SMTP 發(fā)送者再發(fā)出 RCPT 命令指明郵件接收者。如果 SMTP 接收者能夠接收，那么返回 OK 作為應(yīng)答；如果不能收到，則返回拒絕應(yīng)答（但并不中止整個(gè)郵件操作），雙發(fā)如此重復(fù)多次。當(dāng)接收者收到全部郵件后就會(huì)收到特別的序列，如果接受者成功處理了郵件，則返回 OK 應(yīng)答。如圖 1所示。 圖 1 SMTP工作模型 SMTP 提供傳送郵件的機(jī)制，如果接收方與發(fā)送方連接在同一個(gè)傳送服務(wù)器時(shí)，郵件可以直接由發(fā)送方 主機(jī)傳送到接收方主機(jī)；或者，當(dāng)兩者不在同一個(gè)傳送服務(wù)器時(shí)，通過(guò)中繼 SMTP 服務(wù)器傳送。為了能夠?qū)?SMTP 服務(wù)器提供中繼能力，它必須擁有最終目的主機(jī)地址和郵箱名稱。 MAIL 命令參數(shù)是回復(fù)路徑，它指定郵件從何處來(lái)；而 RCPT 命令的參數(shù)是轉(zhuǎn)發(fā)路徑的，它指定郵件向何處去。向前路徑是源路徑，而回復(fù)路徑是返回路徑（它用于發(fā)生錯(cuò)誤時(shí)返回郵件）。 當(dāng)同一個(gè)消息要發(fā)往不同的接收者時(shí)， SMTP 遇到了向不同接收者發(fā)送同一份數(shù)據(jù)的復(fù)制品的問(wèn)題，郵件命令和應(yīng)答有一個(gè)比較奇怪的語(yǔ)法，應(yīng)答也有一個(gè)數(shù)字代碼。 命令與應(yīng)答對(duì)大小寫(xiě)不敏感， 也就是說(shuō)，命令和應(yīng)答可以是大寫(xiě)，小寫(xiě)或兩者的混合，但這一點(diǎn)對(duì)用戶郵件名稱卻不一定是對(duì)的，因?yàn)橛械闹鳈C(jī)對(duì)用戶名大小寫(xiě)是敏感的。這樣 SMTP 實(shí)現(xiàn)中就將用戶郵箱名稱保留成初始時(shí)的樣子，主機(jī)名稱對(duì)大小寫(xiě)不敏感。 命令與應(yīng)答由 ASCII 字母表組成，當(dāng)傳送服務(wù)提供 8位字節(jié)傳送通道，每 7位字符正確傳送，而最高位被填充為 0。當(dāng)指定一般的命令或應(yīng)答格式后，參數(shù)會(huì)由一些類似于語(yǔ)言的字符串表示出來(lái)，如 string＞ 或 reversepath＞ ，這里尖括號(hào)表示這是一種類似于語(yǔ)言的變量。 工作過(guò)程 從 SMTP 協(xié)議的整體工作過(guò)程來(lái)看，客戶端和服務(wù)器是典型的 C/S 結(jié)構(gòu)，由客戶端向服務(wù)器發(fā)起連接請(qǐng)求，發(fā)送相關(guān)的命令（也可以說(shuō)是要求的服務(wù)），等待服務(wù)器的相關(guān)信息。得到服務(wù)器的信息后，對(duì)這些信息進(jìn)行分析，再繼續(xù)進(jìn)行下一步操作。本節(jié)中提供了一些相關(guān)過(guò)程舉例和命令的說(shuō)明，具體描述了 SMTP協(xié)議中數(shù)據(jù)的交互過(guò)程。本節(jié)只介紹了少數(shù)幾個(gè) SMTP 命令和代碼， 本節(jié)末尾 有詳細(xì)的命令列表和代碼列表。 傳送 在 SMTP 發(fā)送操作中有三步，操作由 MAIL 命令開(kāi)始給出發(fā)送者標(biāo)識(shí)。一系列或更多的 RCPT 命令緊跟其后，給出了接收者信息，然后是 DATA命令列出發(fā)送的郵件內(nèi)容，最后郵件內(nèi)容指示符確認(rèn)操作。 1) 過(guò)程中的第一步是 MAIL 命令， reversepath＞包括源郵箱。 MAILSPFROM:reversepathCRLF 此命令告訴接收者新的發(fā)送操作已經(jīng)開(kāi)始，請(qǐng)復(fù)位所有狀態(tài)表和緩沖區(qū)。它給出反向路徑以進(jìn)行錯(cuò)誤信息返回。如果請(qǐng)求被接收，接收方返回一個(gè) 250 OK應(yīng)答。 reversepath中不止包括了郵箱，它包括了主機(jī)和源郵箱的反向路由，其中的第一個(gè)主機(jī)就是發(fā)送此命令的主機(jī)。 2) 過(guò)程中的第二步是發(fā)送 RCPT 命令。 RCPTSP TO: forwardpathCRLF 此命令給出向前路徑標(biāo)識(shí)接收者，如果命令被接收，接收方返回一個(gè) 250 OK應(yīng)答，并存儲(chǔ)向前路徑。如果接收者未知，接收方會(huì)返回一個(gè) 550 Failure 應(yīng)答。此過(guò)程可能會(huì)重復(fù)若干次。 forwardpath＞不僅包括郵件，它是主機(jī)和目的郵箱的路由表，在其中的第一個(gè)主機(jī)就是接收命令的主機(jī)。 3) 過(guò)程中的第三步是發(fā)送 DATA 命令。 DATACRLF 如果命令被接收，接收方返回一個(gè) 354 Intermediate 應(yīng)答，并認(rèn)定以下的 各行都是信件內(nèi) 容。當(dāng)信件結(jié)尾收到并存儲(chǔ)后，接收者發(fā)送一個(gè) 250 OK 應(yīng)答。因?yàn)猷]件是在傳送通道上發(fā)送，因此必須指明郵件內(nèi)容結(jié)尾，以便應(yīng)答對(duì)話可以重新開(kāi)始。 SMTP 通過(guò)在最后一行僅發(fā)送一個(gè)句號(hào)來(lái)表示郵件 內(nèi)容的結(jié)束，在接收方，一個(gè)對(duì)用戶透明的過(guò)程將此符號(hào)過(guò)濾掉，以不影響正常的數(shù)據(jù)。 注意：郵件內(nèi)容包括如下提示： Date , Subject , From , To 。 郵件內(nèi)容指示符確認(rèn)郵件操作并告知接收者可以存儲(chǔ)和再發(fā)送數(shù)據(jù)了。如果此命令被接收，接收方返回一個(gè) 250 OK 應(yīng)答。 DATA 命令僅在郵件操作未完成 或源無(wú)效的情況下失敗。 上面所述的過(guò)程是一個(gè)發(fā)送操作。這些命令只能以上面的順序使用。下例表示了在一個(gè)發(fā)送操作中這些命令的使用。 SMTP 過(guò)程例子此例是在 主機(jī)的 wangyoucao2020 發(fā)送郵件給 主機(jī)的 xia， li 和 yue 的。 S:MAIL FROM: R: 250 OK S: RCPT TO: R: 250 OK S: RCPT TO: R: 550 No such user here S: RCPT TO: R: 250 OK S: DATA R: 354 Start mail input。 end with ＜ CRLF＞ .＜ CRLF＞ S: Blah blah blah... S:..等等 S: ＜ CRLF＞ .＜ CRLF＞ R: 250 OK 此信被第一和三兩個(gè)人接收，而第二個(gè)人在此主機(jī)上沒(méi)有郵箱。 打開(kāi)與退出 想進(jìn)行郵件的發(fā)送，就要有一對(duì)用于傳送信息的通道。這條通道就是發(fā)送者和接接收者用戶發(fā)送和接收數(shù)據(jù)的保證。在 SMTP 中規(guī)定了建立和銷毀通道的命令。 建立命令為 :HELO（ EHLO）。銷毀的命令為： QUIT。這兩個(gè)命令的正確應(yīng)答碼為 220 和 221。信道正常被建立或銷毀的時(shí)候，服務(wù)器端和客戶端會(huì)分別依靠命令和應(yīng)答碼來(lái)打開(kāi)或關(guān)閉信道。 打開(kāi)傳送通道時(shí)，要交換一些信息以確定雙方的身份。以下的命令是用于打 開(kāi)和關(guān)閉的： HELO ＜ SP＞ ＜ domain＞ ＜ CRLF＞ QUIT ＜ CRLF＞ 在 HELLO 命令中，主機(jī)自己發(fā)送命令，此命令可以被解釋為：“你好，我是XX” 打開(kāi)連接的例子： R: 220 Simple Mail Transfer Service Ready S: HELO xx R: 250 關(guān)閉聯(lián)結(jié)的例子 S: QUIT R: 221 Service closing transmission channel 從整個(gè) SMTP 協(xié)議的工作過(guò)程來(lái)看，整個(gè)過(guò)程很類似于一對(duì)朋友的談話，首先要由客戶端的朋友先向服務(wù)器端開(kāi)口說(shuō) HELO，然后服務(wù)器端回答它的話。接下來(lái)客戶端就會(huì)根據(jù)一定的順序，來(lái)繼續(xù)的和服務(wù)器朋友進(jìn)行交流，直到雙方談話結(jié)束，客戶端會(huì)主動(dòng)的說(shuō) QUIT，表示自己要走了。服務(wù)器會(huì) 回 復(fù)它一個(gè)正常的代碼。之后雙方的交流就正式的結(jié)束了。應(yīng)答碼列表如圖 2所示 。 圖 2 SMTP協(xié)議應(yīng)答碼 命令列表如圖 3所示。 圖 3 SMTP協(xié)議規(guī)定的命令關(guān)鍵字 相關(guān)協(xié)議的簡(jiǎn)單介紹 電子郵件系統(tǒng)經(jīng)過(guò)幾十年的發(fā)展，已經(jīng)形成了較為完善的技術(shù)體系。在這個(gè)體系中，建立之初由 RFC821 文檔規(guī)定的內(nèi)容已經(jīng)不能滿足人們?nèi)找媾蛎浀男枨?。因此?制定 出了 一系列的相關(guān)協(xié)議 來(lái)滿足人們?nèi)找孀兓男枨?。下面簡(jiǎn)單介紹幾個(gè)相關(guān)的協(xié)議： RFC2821 文檔：該文檔是 RFC821 的 較為完整的 版本。沒(méi)有 改變?nèi)魏卧械拿?，只是?jiǎn)單的增加了內(nèi)容。類似于 821 文檔。目前大多數(shù)的 SMTP 協(xié)議實(shí)現(xiàn)參考的資料都是 2821 文檔。 它更全面，也更 合理 。 RFC2554 文檔： ESMTP（ SMTP Service Extension for Authentication），它是對(duì) SMTP 協(xié)議的擴(kuò)展，確切來(lái)說(shuō)是對(duì)于郵件傳輸中有關(guān)身份認(rèn)證部分的規(guī)定。其中定義了新的關(guān)鍵字 AUTH LOGIN，并且規(guī)定了身份認(rèn)證的格式和驗(yàn)證的字符串采用的編碼方式。下面給出一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)明驗(yàn)證的過(guò)程，其中 S代表服務(wù)器 ,C 代表客戶端： S: 220 ESMTP server ready C: EHLO S: S: 250 AUTH LOGIN PLAIN。 C: AUTH LOGIN S: 334 Username 的 BASE64 編碼 C: 用戶名 的 BASE64 編碼 S: 334 Password 的 BASE64 編碼 C: 密碼的 BASE64 編碼 S: 235 Authentication successful. 當(dāng)客戶端發(fā)送連接請(qǐng)求到 服務(wù)器時(shí)，服務(wù)器返回 220 應(yīng)答碼，說(shuō)明目前服務(wù)器已經(jīng)準(zhǔn)備工作?？蛻舳耸褂?EHLO 命令聲明自己的身份。 此時(shí)由于要進(jìn)行身份驗(yàn)證，那么必須使用 EHLO 而不是 HELO。服務(wù)器返回操作正確的 250應(yīng)答碼。然后繼續(xù)發(fā)送 250 應(yīng)答碼，要求客戶端去進(jìn)行身份驗(yàn)證?？蛻舳税l(fā)送 AUTH LOGIN命令給服務(wù)器，服務(wù)器返回 334 要求客戶端發(fā)送 BASE64 編碼后的用戶名?？蛻舳税l(fā)送 BASE64 編碼后的用戶名。服務(wù)器驗(yàn)證無(wú)誤后，返回 334 代碼，并要求客戶端發(fā)送密碼。客戶端發(fā)送密碼給服務(wù)器，等待服務(wù)器的驗(yàn)證結(jié)果，服務(wù)器返回235 Authentication successful 信息給客戶端。說(shuō)明驗(yàn)證成功?？梢岳^續(xù)發(fā)送郵件。 RFC2045 文檔： MIME（ Multipurpose Inter Mail Extensions），是對(duì)郵件傳送中的有關(guān)多媒體信息進(jìn)行說(shuō)明。（可以把其看成是 822 文檔的全面升級(jí)版本，當(dāng)然這種說(shuō)法并不準(zhǔn)確，因?yàn)樗鼈児餐c(diǎn)僅僅是都對(duì)內(nèi)容格式進(jìn)行說(shuō)明。）在該協(xié)議中，規(guī)定了一些關(guān)鍵的格式字段如： A MIMIVersion header field , A ContentType header field , A ContentTransferEncoding header field 以及兩個(gè)擴(kuò)展的字段 ContentID 、 Content Description header fields 等字段，并且對(duì) BASE64 編碼格式進(jìn)行了說(shuō)明。 3 軟件 開(kāi)發(fā)背景與環(huán)境 軟件 開(kāi)發(fā)背景 作為計(jì)算機(jī)專業(yè)的學(xué)生，在課堂上學(xué)習(xí)到的僅僅是有關(guān)協(xié)議的理論知識(shí)，并沒(méi)有分析并運(yùn)用協(xié)議的實(shí)際經(jīng)驗(yàn)。對(duì)于協(xié)議的相關(guān)知識(shí)只能停留在理論階段。為了加深對(duì) SMTP 協(xié)議的理解，全面掌握 SMTP 協(xié)議，提高動(dòng)手能力和解決實(shí)際問(wèn)題的能力，而 提出了該課題。 本軟件是為了學(xué)習(xí)目的而開(kāi)發(fā)出的系統(tǒng)，采用 VC++ 作為開(kāi)發(fā)平臺(tái)， C++作為開(kāi)發(fā)的語(yǔ)言。使用 MFC 提供的有關(guān)底層 API，不依靠提供的組件，手動(dòng)分析協(xié)議的工作流程 。對(duì)發(fā)送和接收的數(shù)據(jù)進(jìn)行分析，把文字描述的協(xié)議轉(zhuǎn)化為計(jì)算機(jī)語(yǔ)言，并 提供方便用戶使用的操作界面。生成一個(gè)能夠向任何實(shí)現(xiàn)了 SMTP 協(xié)議的郵件服務(wù)器發(fā)送郵件的客戶端軟件，