將 IIS SMTP Pickup 文件夾公開為文件共享 - 壞主意？
環境：
IIS 網路場
- 5台伺服器
- 視窗伺服器 2008 R2
- IIS 7.5
- ASP.NET 3.5 和 4.0 Web 應用程序
我們的網路應用程序和許多應用程序一樣，需要發送郵件。只發送，不接收。
過去，我們在每台 Web 伺服器上啟用了 IIS 6 SMTP 服務，並使用 .NET SMTP 類將郵件文件放到分揀文件夾中。工作正常。
為了簡化環境並在 Web 伺服器上執行更少的服務，我正在考慮僅在一個實用程序 Windows 服務上執行 SMTP 服務的可行性，並使用文件共享。ASP.NET Web 應用程序將簡單地將它們的郵件文件放在共享的拾取文件夾中，並且單個 SMTP 服務將處理所有 Web 伺服器的外發郵件流。我不擔心數量或 SMTP 服務跟上的能力，這不是問題。
優點：
- 簡化管理和配置
- 降低負載並減少 Web 伺服器上的攻擊向量
- 如果有郵件問題，單點故障排除
缺點：
- 單點故障
- 如果我需要重新啟動實用程序箱，我將失去出站郵件功能。這可以通過對 Web 伺服器上的文件共享使用離線文件夾記憶體來緩解。尚未對其進行測試，但可能 Web 伺服器檢測到與文件共享沒有連接，可以將其文件放在本地，以便在重新啟動時自動同步到 SMTP 伺服器。
- 電子郵件文件名衝突 - 需要確保 ASP.NET 在寫入 .eml 文件時使用保證在整個 Web 場中唯一的名稱來執行此操作。SmtpClient 原始碼指示使用 GUID 命名文件，但 MS 可能會在未來的實現中更改它。
這行得通嗎？
編輯：更多地考慮我對離線文件的想法，我不確定這是最好的方法。離線文件需要一個計劃任務來安排同步，並且每次執行時，我都會在每個其他伺服器的本地記憶體中提取所有其他 Web 伺服器的郵件文件。也許更好的主意是將文件堆積在本地文件夾中，而其他一些工作（計劃的 robocopy）會在啟動時嘗試將它們複製到遠端文件共享中。曾考慮過 DFSR，但同樣，我會將所有郵件文件移動到所有 Web 伺服器，這很浪費。
更好的選擇是通過 tcp/ip 使用 SMTP，即偵聽埠 25（或任何其他埠），然後使用 System.Net.Mail 的 MailMessage 和 SmtpClient。
然後，您可以在 SMTP 伺服器前面放置一個負載平衡器，並讓每個伺服器連接到該負載平衡名稱/IP。
我在這裡看不到你的意思。你試圖通過引入更多的複雜性和安全問題來簡化你的設置。
SMTP 是您問題的解決方案。現在你只需要尋找一個好的實現。SMTP 帶有內置隊列處理（無文件名衝突）、抗故障、多 MX 冗餘感知，並且是一個久經考驗的古老協議。順便說一句，它獨立於作業系統。
您希望將其與單點故障、依賴於調度程序、受作業系統約束、未記錄和新的未經測試的重新發明輪子程序進行交換。此外，您還為每個人公開了一個下拉框，不僅針對這 5 台伺服器。
在網路伺服器上使用簡單的儲存轉發伺服器（如E-MailRelay）和將郵件轉發到的中央 SMTP 伺服器。然後，此 SMTP 伺服器將用於最終傳遞。然後，您可以保護您的中央 SMTP，使其僅接受來自這 5 台伺服器的連接，並執行基於發件人的拒絕或任何您想要減少公眾潛在（垃圾郵件）風險的過濾器/阻止。
該解決方案具有透明性（日誌記錄+監控）、簡單性（一個過程）、一致性（標準 Internet 協議）和完整性（傳遞確認）的所有優點。無需交換它自製的解決方法。