公开IIS SMTP Pickup文件夹作为文件共享 – 坏主意？

环境：

IIS Web Farm
- 5台服务器
- Windows Server 2008 R2
- IIS 7.5
- ASP.NET 3.5和4.0 Web应用程序

我们的networking应用程序，像许多，需要发送邮件。只发送，不接收。

过去，我们在每个Web服务器上启用了IIS 6 SMTP服务，并使用.NET SMTP类将邮件文件放在拾取文件夹中。工作正常。

为了简化环境并在Web服务器上运行较less的服务，我正在考虑只在一个实用程序Windows服务上运行SMTP服务的可行性，并将拾取目录暴露给服务器场中其他Web服务器文件共享。 ASP.NET Web应用程序将简单地将其邮件文件放在共享的拾取文件夹中，单个SMTP服务将处理所有Web服务器的传出邮件stream。我并不担心卷或SMTP服务的能力，这不会是一个问题。

优点：

简化的pipe理和configuration
Web服务器上的负载更低，攻击vector更less
单点故障排除，如果有邮件问题

缺点：

单点故障
如果我需要重新启动实用程序框，则会失去出站邮件function。这可以通过对Web服务器上的文件共享使用脱机文件夹caching来缓解。还没有testing过，但可能是networking服务器，感觉没有连接到文件共享，可能会丢弃他们的文件本地，自动同步到SMTP服务器，当它重新启动。
电子邮件文件名冲突 – 需要确保ASP.NET在写入.eml文件时，在整个Web场中使用保证的唯一名称。 SmtpClient源代码指示GUID用于命名文件，但MS可以在将来的实现中更改。

这会工作吗？

编辑：思考更多关于我的脱机文件的想法，我不知道这是最好的办法。脱机文件需要一个计划的任务来安排同步，每次运行时，我将拉动所有其他Web服务器的邮件文件，每隔一个服务器的本地caching。也许更好的办法是将文件堆积在本地文件夹中，而其他一些作业（计划的robocopy）会尝试将文件复制到远程文件共享中。曾经想过DFSR，但是我再一次将所有的邮件文件洗牌到所有的networking服务器，这是浪费。

最好的办法是通过TCP / IP使用SMTP，即监听端口25（或任何其他端口），然后使用System.Net.Mail的MailMessage和SmtpClient。

然后，您可以在SMTP服务器前面引入负载均衡器，并让每台服务器连接到该负载均衡的名称/ IP。

我在这里看不到你的观点。您尝试通过引入更多的复杂性和安全问题来简化您的设置。

SMTP是您的问题的解决scheme。现在你只需要寻找一个好的实现。 SMTP带有内置队列处理（无文件名冲突），抗故障，由于多个MX而具有冗余意识，并且是一个久经考验的协议。顺便说一下，它是独立于操作系统。

您希望通过单点故障，依赖于调度程序，操作系统绑定，未logging的和新的未经testing的重新发明轮子程序来交换此信息。此外，您还为每个人展示了一个drop-in-box，不仅包含这5台服务器。

使用Web服务器上的简单存储转发服务器（如E-MailRelay ）和邮件转发到的中央SMTP服务器。这个SMTP服务器将被用于最终交付。然后，您可以确保您的中央SMTP仅接受来自这5台服务器的连接，并执行基于发件人的拒绝或您希望为公众减less潜在（垃圾邮件）风险的任何filter/阻止。

此解决scheme具有透明度（日志logging+监视），简单性（一个进程），一致性（标准Internet协议）和完整性（交付确认）的所有优点。没有必要交换它自制的解决方法。