我們暫且不管是否能修改 SMTP ，先來了解 SMTP 到底是如何溝通的，SMTP 的使用範圍包含所有的郵件伺服器，以及我們正在使用的郵件軟體，例如：Outlook Express。溝通的角色就是 寄件者端 以及 收件者端，我們先來看一個實例。

(引用自 RFC 821)
[1]R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
[2]S: HELO USC-ISIF.ARPA
[3]R: 250 BBN-UNIX.ARPA
[4]S: MAIL FROM: <Smith@USC-ISIF.ARPA>
[5]R: 250 OK
[6]S: RCPT TO: <Jones@BBN-UNIX.ARPA>
[7]R: 250 OK
[8]S: RCPT TO: <Green@BBN-UNIX.ARPA>
[9]R: 550 No such user here
[10]S: RCPT TO: <Brown@BBN-UNIX.ARPA>
[11]R: 250 OK
[12]S: DATA
[13]R: 354 Start mail input; end with CRLF.
[14]S: Blah blah blah... S: ...etc. etc. etc. S: <CRLF>.<CRLF>
[15]R: 250 OK
[16]S: QUIT
[17]R: 221 BBN-UNIX.ARPA Service closing transmission channel

        首先寄件者(S)會先連線到收件者端(R)，然後收件者端會立即回覆第一個通訊指令 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready，這是一個打招呼的敘述，目的要告訴寄件者我是正常的。
        在 SMTP 中回覆指令統一的格式為 [數字][數字][數字][空白][內容][換行碼] Ex : 1xx Test 格式中的三個數字每一位都有其代表的意義，這在 RFC 中有詳細的說明，不過我們只要先簡單的知道，第一位數，如果是 1,2,3 代表正常，如果是 4,5 代表不正常，所以當收件端回覆 220 就代表正常可以繼續。接著寄件者，送出了第一個指令 HELO USC-ISIF.ARPA 這是要回應剛剛收件者的招呼，HELO 就是代表 HELLO 後面的敘述代表寄件者端的機器名稱或網址，也是為了要表明自己的身分，於是收件者回覆 250 BBN-UNIX.ARPA，這看起來是收件者表述自己的身分，但其實這並沒有強性規定，有的收件主機甚至只回答 250 OK 就可以了。MAIL FROM:<Smith@USC-ISIF.ARPA>，mail 指令就是要告訴收件者我的這封信寄件者是誰，此時收件者也會再回應是否正常，RCPT TO:<Jones@BBN-UNIX.ARPA>，RCPT 指令就是要告訴收件者主機，這封信是要寄給誰，如果同一封信要轉寄給很多人，就可以連續的下 RCPT 去指定給每一個人，當 RCPT 已經都指定完了收件人後寄件者的下一個指令就是 DATA，這是要告訴收件者，信件的內容開始了，當收件者回應一個正常的訊息，寄件者就可以把內容全部寫出，而雙方協定的信件終止符號為  <CRLF>.<CRLF>，收件者檢查到有終止符號時，就會立刻存檔並且回應正常，此時寄件者的最後一個指令就是 QUIT，離開，然後由收件者回應正常且斷線，如此便完成了一封信的寄信過程。

        看過了SMTP 溝通過程後，我們開始來探討到底這與垃圾郵件問題有什麼關係，第一個我們探討的指令是 HELO，協定中敘述 HELO 是為了要表示寄件者的身分，但是確沒有強制規定一定要正確，也就是說，我可以任意的填寫 HELO 後面的內容例如：HELO mail.yahoo.com ，冒充 yahoo 的 mail server 發信。HELO 是一個很好確定寄件者來源的指令，但可惜規範中完全不做驗證，如果 HELO 可以嚴格檢驗，這可以擋去相當大比例的垃圾郵件，因為目前大部分的垃圾郵件寄件者來源都是利用冒充的方法。接著來看第二個指令 MAIL，MAIL 指令與 HELO 一樣存在同樣的問題，MAIL 後的內容一樣可以自由填寫，所以 MAIL 後的內容也是可以造假的。第三個指令是 RCPT，這個指令是唯一不能造假的，因為這攸關信件能否寄到收信人手上，如果在此指令亂填，信件也會讓人收不到。DATA 指令中我們關心的是 RFC 822 - Standard for the format of ARPA Internet text messages 的問題，RFC 822規範了許多信件標題的格式，例如我們在收信軟體中常看到的“主旨”欄位，同樣的，在SMTP中的信件也遵照 RFC 822來處理，我們發現在 SMTP 中規範了 RCPT 與 MAIL ，然而在 RFC 822 也有 "From"," Sender"," To" 等規範，這意思是說，假設在 SMTP 中 Mail 指令後面用 test@yahoo.com 但是到了 DATA 指令的內容時，卻可以用 RFC 822 的格式，將 "From" 寫入另一個 Email 例如，test@kimo.com 。 RCPT 也是這樣的情形，在RCPT後寫入您正確的Email可是卻可以在信件內容 RFC 822 的 "To" 寫入另一個 E-Mail 。這就是為何我們常常會收到收件者不是自己但是卻可以收到信的原因。因為這兩個是沒有嚴格審查的，信件只要在 RCPT 指令指定了正確的收件者，信件自然會送達，但信件內容的 To 就可以隨意填寫了。這個部份也是一個有效的辨識垃圾信的方法，大約有 80% 的垃圾郵件，他們的 RCPT 與 To，或是 MAIL 與 From，都是沒有對應的，而正常的信件通常都是對應的。

        舊的通訊協定其實都是非常單純的，我們期望有新的相容性通訊協定誕生，或是更好的解決垃圾郵件的方法。

對本篇文章有任何看法 Mail Me