我收到從網站返回的錯誤訊息，該訊息似乎是伺服器端出現問題。但是，該伺服器適用於盒子上的所有其他網站。我（開發者）有可能做錯了什麼嗎？我不知道從哪裡開始在伺服器上追蹤這一點，我的系統管理員說一切看起來都很正常：
The following recipient(s) cannot be reached:
Customer Service Account on 6/3/2009 11:00 AM
There was a SMTP communication problem with the
recipient's email server. Please
contact your system administrator.
<fgdc.myservername.net #5.5.0 smtp;550 Requested action not taken: mailbox unavailable>
伺服器是 2003，64 位，運行 Exchange 2003
站點是Asp.Net C#，使用URL路由
我該從哪裡開始解決這個問題？
更新
事實證明，我的系統管理員將問題追溯到垃圾郵件防護層。事實證明，MIMESweeper 可能會丟棄該訊息，因為它看到來自我們的 Web 伺服器場的訊息試圖使用內部位址發送電子郵件。我們測試了外部位址（gmail、hotmail 等），效果很好。
感謝所有的答案。事實證明，從我的角度來看，最好的答案是「與您的系統管理員交談」......但我想我會為任何有類似問題的人更新問題。
答案1
伺服器表示您指定的「RCPT TO：」無效。
我建議您使用 Wireshark 之類的工具來捕獲程式碼和伺服器之間的 SMTP 對話，並驗證您是否正在發送預期的內容。看到網路上發生的事情並看看它是否與程式碼所說應該發生的事情一致總是很高興。
如果您指定了正確的收件人，請聯絡伺服器管理員並讓他們檢查。
答案2
當然，這可能是開發商的錯。例如，規範規定 RCPT 應該如下所示：
RCPT TO:<[email protected]>
然而，實際發送此內容是很常見的做法：
RCPT TO: [email protected]
大多數功能齊全、成熟的 MTA 都接受後者，儘管它並不嚴格正確。某些應用程式（例如郵件防火牆、CRM 郵件擷取器等）對此會嚴格並傳回錯誤。
我並不是說這就是本例的原因，但它是一個範例，說明您的程式碼如何在大多數伺服器上工作，但如果它在一小部分伺服器上崩潰，仍然是您的錯。
我同意埃文的建議，即嗅探流量並了解實際發送的內容。
答案3
可以這麼說，您可以使用常規武器向相關電子郵件地址發送電子郵件嗎？如果是這樣，那可能是你的程式碼。如果不是，那就是他們的伺服器（或者可能是試圖為他們的伺服器進行智慧託管的防火牆）。
答案4
如果您想知道這是伺服器故障網站。如果您的系統管理員說它是代碼 - 那就是代碼。錯誤總是開發人員的錯。如果你想怪罪系統管理員，我聽說有一個名為 stackoverflow 的網站可能更有同情心:)
嚴肅地說，是的，這就是代碼。根據錯誤，配方無效。以某種方式，網頁伺服器試圖將郵件傳送到名為「客戶服務帳戶」的帳戶，所有電子郵件地址的格式為[電子郵件受保護]。您收到 550 錯誤的事實表明您已正確連接到目標郵件伺服器，但沒有名為「客戶服務帳戶」的用戶
從技術上講，550 意味著無法中繼，但我猜測您正在嘗試發送到內部郵箱。即使您嘗試轉發，該收件者的格式也不正確。