目錄

問題：

DNS問題

CPU使用率高

資源節約模式

防火牆

問題：

什麼原因會導致SMTP標識延遲？

通常，當您通過telnet連線到郵件伺服器的埠25時，您將很快獲得SMTP標語。以下是SMTP橫幅的示例：

220 host.example.com ESMTP

554 host.example.com

有時會出現延遲，您得到的只是顯示器中的連線資訊。以下是範例：

host.example.com> telnet 10.92.152.18 25

正在嘗試10.92.152.18...

已連線到host.example.com。

跳脫字元為「^]」。

請注意，此示例中缺少標語。經過一段時間後，標語應最終顯示在下一行中。本文討論這一具體情況。我們將討論以下四個共同的原因：DNS問題、CPU使用率高、資源節約模式和防火牆。

DNS問題

SMTP標語延遲的最常見原因是DNS查詢時間比正常時間長或超時。在連線和橫幅顯示之間有三個查詢：反向DNS（或PTR記錄）查詢，然後對PTR記錄中指定的主機名進行正向（或A記錄）查詢，然後進行SenderBase查詢以獲取連線主機的SBRS（SenderBase信譽分數）。

這些查詢用於確定連線主機屬於哪個發件人組。這將確定使用什麼郵件流策略，以及是否接受來自此主機的郵件。這將影響要傳送的郵件橫幅（如果有）。因此，在給出標語之前進行這些查詢至關重要。

要確定問題是否與DNS相關，您需要登入到ESA的命令列(CLI)並使用nslookup命令。從裝置本身執行此操作非常重要，因此您要從裝置的角度執行操作。首先，您需要知道嘗試連線的IP地址。您可能希望使用mail_logs或郵件跟蹤獲取IP地址。

一旦知道IP，就可以開始使用nslookup進行測試。請務必計算每個過程需要多少秒

DNS查詢！首先進行反向DNS查詢：

host.example.com> nslookup 10.92.152.18

PTR= host.example.com TTL=2小時35分43秒

然後，在反向DNS查詢時返回的主機名上進行查詢，如下所示：

host.example.com> nslookup host.example.com

A=10.92.152.18 TTL=2小時34分16秒

如果這兩個查詢的總時間與橫幅延遲的時間大致相同，您已經找到了原因，並希望進一步檢視DNS情況。後續步驟可能包括測試來自不同網路的其他IP地址。這將告訴您問題是否隔離於特定主機或網路，或者是否存在更常見的DNS問題。

CPU使用率高

SMTP標語延遲的另一個可能原因是CPU使用率非常高。

當系統負載較重時，所有操作都需要較長的時間。您可以通過轉到「監控」頁籤的「系統狀態」頁面或使用「狀態詳細資訊」CLI命令來檢查此情況。這兩種方法都會在Gages部分提供CPU使用率統計資訊。以下是範例：

CPU利用率

總計67%

MGA 16%

案例46%

Brightmail反垃圾郵件0%

防病毒0%

報告4%

隔離0%

如果總量非常高（95%或更高），並且持續數分鐘保持高水準，則CPU使用可能是導致

smtp標語延遲。

資源節約模式

SMTP標語延遲的另一個可能原因是系統已進入資源節約模式。在這種模式下，系統通過減緩郵件接收流量來保護自己。它通過故意延遲其傳送的每個SMTP響應來實現這一點。要確定系統是否處於資源節約模式，請轉到「監視器」頁籤的「系統狀態」頁，或使用「狀態詳細資訊」CLI命令。在儀表區查詢資源保護行。

以下是範例：

資源保護0

任何非零數字表示系統試圖通過減緩SMTP響應來保護自己。您可以在此處瞭解有關資源保護的更多資訊：

什麼是資源節約模式？

防火牆

SMTP標語延遲的最後一個常見原因是可感知SMTP的防火牆。這些功能，例如對所有SMTP內容執行「SMTP修正」或運行安全掃描。有時，防火牆可能會在掃描時延遲標語，並可能修改SMTP標語的內容。以下是更改SMTP標語的常用防火牆示例：

220

*****02***********************************************************0****0****

0 ***************2******200**0*********0*00