目標郵件伺服器

此過程的第一步是檢查是否存在我們要驗證的電子郵件地址域的MX記錄。MX記錄是儲存有關處理特定域的郵件的郵件伺服器資訊的DNS記錄。如果域名沒有MX記錄，則也不存在有效的電子郵件地址。我們來看看使用nslookup 命令的兩個例子 。請注意，您可以類似地使用其他命令，如挖 。

我們的示例電子郵件測試將是 [email protected] 和 [email protected] ，我們將使用Google的公共DNS伺服器8.8.8.8獲取DNS記錄。

> nslookup

> server 8.8.8.8
Default Server:  google-public
 
-dns-a.google.com
Address:  8.8.8.8

> set q=mx

> gmail.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
gmail.com       MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.com
gmail.com       MX preference = 30, mail exchanger = alt3.gmail-smtp-in
 
.l.google.com
gmail.com       MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.com
gmail.com       MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
gmail.com       MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.com

> nonexistingdomainname123456.com
Server
 
:  google-public-dns-a.google.com
Address:  8.8.8.8

*** google-public-dns-a.google.com can't find nonexistingdomainname123456.com: Non-existent domain

對於非現有域的電子郵件地址，根本找不到任何MX伺服器。這自動錶示[email protected] 不是有效的電子郵件地址。對於 [email protected] ，情況不同。我們可以看到，對於 gmail.com 域，有5條MX記錄。通常只有少量電子郵件的域只能看到1個MX記錄，但較大的服務可能有多個郵件伺服器。重要的是不要在這裡選擇一個郵件伺服器。為了正確驗證電子郵件，我們可能必須使用所有發現的MX記錄中的所有伺服器。

搭建郵件伺服器(1~7篇文章)

為什麼這麼重要？想像一下我們從列表中選出一個MX伺服器的情況。可能發生的是，當我們嘗試連線到它以驗證電子郵件時，伺服器將不會因為任何原因而進行響應，或者由於該特定伺服器的最近問題，其響應將報告臨時錯誤。如果我們不嘗試其他可用的郵件伺服器，可能會導致錯誤的結果。另外一個伺服器可能會很好，並且給我們正確的答案。所以，如果一個伺服器有任何問題，只要嘗試另一個伺服器。這些問題包括無法連線到SMTP埠，沒有接收到問候，對HELO / EHLO或MAIL FROM命令的無效響應。

處理Greetdelay和HELO / EHLO

在這一步，我們假設我們有一個來自目標域的DNS MX記錄的郵件伺服器。下一步是將目標郵件伺服器連線到其埠25 / TCP的SMTP埠。我們剛才提到，如果無法建立連線，那麼我們應該嘗試另一臺伺服器（如果有的話）。

如果TCP連線建立，現在重要的是等待郵件伺服器傳送我們的問候語。我們不能簡單地將我們的命令傳送到伺服器，因為伺服器首先在SMTP協議中規定。一些伺服器被配置為拒絕與不尊重的客戶端進行協作。這是許多反垃圾郵件技術之一。垃圾郵件傳送程式有時被程式設計為儘可能簡單和快速。這就是為什麼他們不等待伺服器的問候，並在連線建立後立即開始傳送命令。拒絕這種客戶端的伺服器可能在最早階段擺脫這些垃圾郵件傳送者。

另一種相對較新的反垃圾郵件技術叫做Greetdelay。基本思想是基於我們已經提到的同樣的事實 - 垃圾郵件傳送者用於傳送電子郵件的許多程式非常簡單和編碼，以儘可能快地工作。如果要傳送數百萬封電子郵件獲得一些點選和銷售，他們必須快速。Greetdelay的想法是讓SMTP協議的RFC規範允許的時間延遲訊息傳輸代理（MTA，想要傳送電子郵件的軟體）。例如，執行Greetdelay的伺服器在向客戶端傳送問候之前等待30秒。或60秒。或90.不完全符合協議的垃圾郵件軟體可能會在允許傳送訊息之前放棄。可以在SMTP通訊的其他階段實現類似的策略。

因此，為了順利通過Greetdelay機制，電子郵件驗證機引擎必須將其超時設定至少5分鐘。問候語應該帶有程式碼SMTP響應程式碼220.其他程式碼可能意味著我們應該嘗試另一個MX伺服器。

收到問候語後，客戶端（我們的電子郵件驗證引擎）應傳送 HELO 或 EHLO 命令。由於 HELO 命令僅存在於與舊軟體的相容性，所以每次都使用 EHLO 。其唯一的引數是客戶端的完全限定域名（FQDN）。在我們傳送MAIL FROM 命令之後，我們將介紹在下一節中執行電子郵件驗證客戶端的伺服器擁有自己的域名的重要性 。但在我們可以這樣做之前，我們將等待對我們的EHLO的答覆 。這裡的SMTP程式碼應該是250，否則我們可以假設這個伺服器有問題。

讓我們看看當我們和其中一個Gmail的伺服器（從S開始的線路 ： 來自伺服器，從C開始的線路： 來自我們的客戶端）時，會發生什麼情況：

> nc alt4.gmail-smtp-in.l.google.com 25
S: 220 mx.google.com ESMTP m14si19812165icp.91 - gsmtp
C: EHLO mail.example.com
S: 250-mx.google.com at your service, [198.51.100.123]
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 SMTPUTF8

我們使用 Netcat 作為客戶端，允許我們手動鍵入SMTP命令。我們的IP地址是198.51.100.123。MX伺服器向我們傳送正確的問候語，並使用EHLO 命令回覆 。伺服器的響應程式碼是250，它向我們傳送了一個受支援的副檔名單，這對我們來說並不重要