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

問題：

什麼原因會導致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或Message Tracking來獲取IP地址。

一旦您知道IP，就可以開始使用nslookup進行測試。請務必計算每次轉換所需的秒數

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

host.example.com> nslookup 10.92.152.18
PTR= host.example.com TTL=2h 35m 43s

然後對反向DNS查詢返回的主機名執行查詢，如下所示：

host.example.com> nslookup host.example.com
A=10.92.152.18 TTL=2h 34m 16s

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

CPU使用率高

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

當系統負載較重時，所有情況都需要更長的時間才能發生。您可以轉到Monitor頁籤的System Status頁，或者使用「status detail」CLI命令來檢查這一點。這兩種方法都會在「計量表」部分提供CPU使用率統計資訊。以下是範例：

CPU使用率
總計67%
MGA 16%
案例 46%
Brightmail反垃圾郵件0%
防病毒0%
報告4%
隔離0%

如果總計很高（95%或更高），並且持續高達數分鐘，則可能是

smtp標語延遲。

資源節約模式

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

以下是範例：

資源節約0

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

什麼是資源節約模式？

防火牆

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

220
*****02***********************************************************0****0****
0 ***************2******200**0*********0*00