SMTP錯誤代碼合規

Question

我不太確定這是否構成此問題的最佳位置（或在服務器默認情況下）。我正在使用第三方.NET SMTP組件直接向收件人的郵件服務器發送電子郵件。我需要這樣做才能獲得實時的交付結果。通過另一個SMTP服務器發送需要我通過DSN報告異步獲取結果，這對我的應用程序的性質來說太麻煩了。

無論如何，我遇到了與目標SMTP服務器返回的錯誤代碼不符合錯誤消息的問題。因此，我不能將交付標記爲硬性或軟性反彈。例如。回覆錯誤代碼是450（表示郵箱不可用），但是回覆郵件與超時有關。當我再次發送相同的消息時，它已經過了。很明顯，以前的發送超時問題。

我意識到，問題可能不是接收SMTP服務器，而是防火牆/代理（無論您稱之爲什麼），即保護服務器。

有沒有人遇到類似的問題，你如何處理它。 PS：當我回到我的辦公室時，我會盡量從我的日誌中提供更多詳細信息。

Answer 1

聽起來像灰名單。這很有趣，因爲當我開始閱讀你的問題時，那是我可以預見的第一個障礙之一。

Greylisting是一種反垃圾郵件方法，其工作原理是在合法MTA嘗試在一段時間後重新提交郵件的基礎上軟交付失敗。不幸的是，有兩件事情對您不利：

• 灰名單可以隨機選擇。這意味着有時在接收郵件接收郵件前需要多次重試。
• 儘管4xx代碼應該總是被視爲軟故障並用於此目的，但服務器沒有任何要求告訴您這是歸因於灰名單。有些會如此善良，有些則不會。

您如何處理這將取決於軟故障是否被認爲是您的應用程序正在執行的最終失敗。如果他們不是，那麼你將不得不設計一些可靠的排隊和重試。我誠摯的建議是，實現可靠的DSN或日誌檢查可能比創建自己的符合RFC（和quirk）的MTA更容易。