SMTP協議原始指令碼和工作原理
1.SMTP是工作在兩種情況下：一是電子郵件從客戶端機傳輸到伺服器；二是從某一
個伺服器傳輸到另一個伺服器.
2.SMTP是個請求/回應協議，指令和回應都是基於ASCII文本，並以CR和LF符結束
。回應包括一個表示返回狀態的三位數字程式碼.
3.SMTP在TCP協議25號連接阜監聽連接請求
4.連接和發送程序：
a.建立TCP連接
b.客戶端發送HELO指令以標識發件人自己的身份，然後客戶端發送MAIL指令
伺服器端正希望以OK作為回應，表明準備接收
c.客戶端發送RCPT指令，以標識該電子郵件的計劃接收人，可以有多個RCPT行
伺服器端則表示是否願意為收件人接受郵件
d.協商結束，發送郵件，用指令DATA發送
e. 以.表示結束輸入內容一起發送出去
f.結束此次發送，用QUIT指令退出。
5.另外兩個指令：
VRFY---用於驗證給定的用戶郵箱是否存在，以及接收關於該用戶的詳細資料。
EXPN---用於擴充郵件列表。
6.郵件路由程序：
SMTP伺服器基於『域名服務DNS中計劃收件人的域名來路由電子郵件。SMTP服務
器基於DNS中的MX記錄來路由電子郵件，MX記錄註冊了域名和相關的SMTP中繼主機
，屬於該域的電子郵件都應向該主機發送。
若SMTP伺服器mail.abc.com收到一封信要發到shuser@sh.abc.com:
a.Sendmail請求DNS給出主機sh.abc.com的CNAME記錄，如有，假若CNAME到shmai
l.abc.com，則再次請求shmail.abc.com的CNAME記錄，直到沒有為止.
b.假定被CNAME到shmail.abc.com,然後sendmail請求@abc.com域的DNS給出shmai
l.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. Sendmail與1.2.3.4連接，傳送這封給shuser@sh.abc.com的信到1.2.3.4這台
伺服器的SMTP後台程序
7.SMTP基本指令集：
指令 描述
------------------------------
HELO 向伺服器標識用戶身份
發送者能欺騙，說謊，但一般情況下伺服器都能檢測到。
MAIL 啟始化郵件傳輸
mail from:
RCPT 標識單個的郵件接收人；常在MAIL指令後面
可有多個rcpt to:
DATA 在單個或多個RCPT指令後，表示所有的郵件接收人已標識，並啟始化
資料傳輸，以.結束。
VRFY 用於驗證指定的用戶/郵箱是否存在；由於安全方面的原因，伺服器常
禁止此指令
EXPN 驗證給定的郵箱列表是否存在，擴充郵箱列表，也常被禁用
HELP 查詢伺服器支持什麼指令
NOOP 無操作，伺服器應回應OK
QUIT 結束會話
RSET 重置會話，當前傳輸被取消
--------------------------------
8. MAIL FROM指令中指定的位址是稱作 envelope from位址，不需要和發送者自
己的位址是一致的。
RCPT TO 與之等同，指明的接收者位址稱為envelope to位址，而與實際的to
：行是什麼無關。
9.為什麼沒有RCPT CC和RCPT BCC:?
所有的接收者協商都通過RCPT TO指令來實現，如果是BCC，則協商發送後在對
方接收時被刪掉信封接收者
10.郵件被分為信封部分，信頭部分和信體部分
envelope from, envelope to 與message from:, message to:完全不相干。
evnelope是由伺服器主機間SMTP後台提供的，而message from/to是由用戶提
供的。有無冒號也是區別。
11. 怎樣由信封部分檢查是否一封信是否是偽造的？
a. received行的關聯性。
現在的SMTP郵件傳輸系統，在信封部分除了兩端的內部主機處理的之個，考慮
兩個公司防火牆之間 的部分，若兩台防火牆機器分別為Ａ和Ｂ，但接收者檢查信
封received：行時發現經過了C.則是偽造的。
b. received：行中的主機和IP位址對是否對應如：
Receibed: from galangal.org (turmeric.com [104.128.23.115] by mail
.bieberdorf.edu....
c. 被人手動增加在最後面的received行：
Received: from galangal.org ([104.128.23.115]) by mail .bieberdorf
.edu (8.8.5)
Received: from lemongrass.org by galangal.org (8.7.3)
Received: from graprao.com by lemongrass.org (8.6.4)
1.SMTP是工作在兩種情況下：一是電子郵件從客戶端機傳輸到伺服器；二是從某一
個伺服器傳輸到另一個伺服器.
2.SMTP是個請求/回應協議，指令和回應都是基於ASCII文本，並以CR和LF符結束
。回應包括一個表示返回狀態的三位數字程式碼.
3.SMTP在TCP協議25號連接阜監聽連接請求
4.連接和發送程序：
a.建立TCP連接
b.客戶端發送HELO指令以標識發件人自己的身份，然後客戶端發送MAIL指令
伺服器端正希望以OK作為回應，表明準備接收
c.客戶端發送RCPT指令，以標識該電子郵件的計劃接收人，可以有多個RCPT行
伺服器端則表示是否願意為收件人接受郵件
d.協商結束，發送郵件，用指令DATA發送
e. 以.表示結束輸入內容一起發送出去
f.結束此次發送，用QUIT指令退出。
5.另外兩個指令：
VRFY---用於驗證給定的用戶郵箱是否存在，以及接收關於該用戶的詳細資料。
EXPN---用於擴充郵件列表。
6.郵件路由程序：
SMTP伺服器基於『域名服務DNS中計劃收件人的域名來路由電子郵件。SMTP服務
器基於DNS中的MX記錄來路由電子郵件，MX記錄註冊了域名和相關的SMTP中繼主機
，屬於該域的電子郵件都應向該主機發送。
若SMTP伺服器mail.abc.com收到一封信要發到shuser@sh.abc.com:
a.Sendmail請求DNS給出主機sh.abc.com的CNAME記錄，如有，假若CNAME到shmai
l.abc.com，則再次請求shmail.abc.com的CNAME記錄，直到沒有為止.
b.假定被CNAME到shmail.abc.com,然後sendmail請求@abc.com域的DNS給出shmai
l.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. Sendmail與1.2.3.4連接，傳送這封給shuser@sh.abc.com的信到1.2.3.4這台
伺服器的SMTP後台程序
7.SMTP基本指令集：
指令 描述
------------------------------
HELO 向伺服器標識用戶身份
發送者能欺騙，說謊，但一般情況下伺服器都能檢測到。
MAIL 啟始化郵件傳輸
mail from:
RCPT 標識單個的郵件接收人；常在MAIL指令後面
可有多個rcpt to:
DATA 在單個或多個RCPT指令後，表示所有的郵件接收人已標識，並啟始化
資料傳輸，以.結束。
VRFY 用於驗證指定的用戶/郵箱是否存在；由於安全方面的原因，伺服器常
禁止此指令
EXPN 驗證給定的郵箱列表是否存在，擴充郵箱列表，也常被禁用
HELP 查詢伺服器支持什麼指令
NOOP 無操作，伺服器應回應OK
QUIT 結束會話
RSET 重置會話，當前傳輸被取消
--------------------------------
8. MAIL FROM指令中指定的位址是稱作 envelope from位址，不需要和發送者自
己的位址是一致的。
RCPT TO 與之等同，指明的接收者位址稱為envelope to位址，而與實際的to
：行是什麼無關。
9.為什麼沒有RCPT CC和RCPT BCC:?
所有的接收者協商都通過RCPT TO指令來實現，如果是BCC，則協商發送後在對
方接收時被刪掉信封接收者
10.郵件被分為信封部分，信頭部分和信體部分
envelope from, envelope to 與message from:, message to:完全不相干。
evnelope是由伺服器主機間SMTP後台提供的，而message from/to是由用戶提
供的。有無冒號也是區別。
11. 怎樣由信封部分檢查是否一封信是否是偽造的？
a. received行的關聯性。
現在的SMTP郵件傳輸系統，在信封部分除了兩端的內部主機處理的之個，考慮
兩個公司防火牆之間 的部分，若兩台防火牆機器分別為Ａ和Ｂ，但接收者檢查信
封received：行時發現經過了C.則是偽造的。
b. received：行中的主機和IP位址對是否對應如：
Receibed: from galangal.org (turmeric.com [104.128.23.115] by mail
.bieberdorf.edu....
c. 被人手動增加在最後面的received行：
Received: from galangal.org ([104.128.23.115]) by mail .bieberdorf
.edu (8.8.5)
Received: from lemongrass.org by galangal.org (8.7.3)
Received: from graprao.com by lemongrass.org (8.6.4)
