经典 ASP 网站发送邮件超时（IIS6，默认 SMTP 服务器）
我刚刚将客户的经典 ASP 网站移至他们自己的 VPS 服务器（Windows 2003、32 位、IIS6、虚拟 SMTP 服务器），大约 12 小时后，该网站在尝试发送电子邮件 (CDO.Message) 时开始出现故障。
任何发送电子邮件的脚本都会花费很长时间才返回错误：Active Server Pages、ASP 0113、脚本超时。标准超时已到位。奇怪的是，使用相同的电子邮件发送方法和设置（实际上相同的功能）向我发送错误的自定义错误页面能够向我发送错误通知。
我需要让网站正常运行，所以我停止/启动了 SMTP 服务器，但这没有帮助，然后重新启动 IIS，问题立即得到解决。
我担心这种情况可能会再次发生。对于可能导致此问题的原因有何建议，或者默认 SMTP 服务器是否需要一些额外的设置来应对相当大容量的网站？
I have just moved a customer's Classic ASP website to their own VPS server (Windows 2003, 32-bit, IIS6, Virtual SMTP server) and after about 12 hours the website starting failing whenever it tried to send emails (CDO.Message).
Any script that sent an email took a very long time before it returned the error: Active Server Pages, ASP 0113, Script timed out. The standard timeout is in place. Strangely the custom error page which sends errors to me using the same email send method and settings (same function actually) was able to send me the error notification.
I needed to get the website going so I stopped/started the SMTP server which didn't help, then restarted IIS which resolved the issue immediately.
I am worried this might happen again. Any suggestions for what can cause this problem or does the default SMTP server need some additional settings to cope with a reasonably high-volume website?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于经典的 ASP 代码必须调用基于外部 COM 的组件才能发送电子邮件（如果您正在创建 CDO 消息，这就是您正在做的事情 --- 每当您在 ASP 代码中调用 CreateObject 时，即 COM），如果外部组件需要很长时间才能响应，则 ASP 代码将显得挂起。例如，大多数 SMTP 组件将同步尝试将消息发送到 SMTP 服务器，从而阻止您的 asp 代码执行，直到发送电子邮件为止。这在非常繁忙的 SMTP 服务器上会成为一个问题，因为它们响应连接请求和 SMTP 命令的速度可能非常慢。另一个糟糕的情况是，许多 ISP/主机试图通过故意使其 SMTP 服务器响应缓慢来限制您发送电子邮件的速度。更糟糕的是，某些主机甚至会在设定的时间段内实际使后续连接逐渐变慢。这可能会显着影响您的站点性能，因为您的页面代码通常会在 SMTP 发送期间被阻止。
最好的解决方案是使用不执行此类限制措施的主机或 SMTP 服务器。除此之外，有一种方法可以通过使用消息队列来解决这个问题。如果您使用 CDO，这意味着您必须在 IIS Web 服务器上配置 Microsoft SMTP 服务才能使用。即使 IIS 计算机上有其他 SMTP 软件，也可以正确配置此功能。一旦 Microsoft SMTP 服务在 IIS 服务器上运行，它将能够在服务器上对电子邮件进行排队，并将它们与您的应用程序/页面代码异步转发到配置的 SMTP 服务器。配置 Microsoft SMTP 服务时，您必须定义所谓的“智能主机”。这只是您要将出站电子邮件路由到的 SMTP 服务器，以便在您的网络上传送。
配置完成后，您只需更改使用 CDO 对电子邮件进行排队的代码，而不是尝试发送它。在 CDO 代码中，您应该有一行设置 CDO 字段值，如下所示：
您想要将“sendusing”字段的值从值 2 更改为值 1。这些是枚举值cdoSendUsingPort (2) 和 cdoSendUsingPickup (1) 枚举。执行此操作后，您还可以删除“smtpserver”和“smtpserverport”字段，因为这些字段会被 Microsoft SMTP 服务的配置方式覆盖。执行此操作后，您的 asp 代码将快速生成电子邮件，并将其在 IIS 服务器的邮件接收文件夹中排队。因此您的应用程序/页面代码将运行得更快。由于 SMTP 服务在后台缓慢传送邮件，因此外发电子邮件可能会堆积在队列文件夹中。它不会使电子邮件发送得更快，但它确实可以防止您的代码由于 SMTP 服务器速度慢而被阻止。
Since classic ASP code has to call an external COM based component in order to send email (that's what you are doing if you are creating a CDO message --- anytime you have a CreateObject call in your asp code, that is COM), the asp code will appear to hang if the external component takes a long time to respond. For example, most SMTP components will synchronously try to send the message to the SMTP server blocking your asp code from executing until the email message is sent. This becomes a problem on very busy SMTP servers, as they can be very slow to respond to connection requests and to SMTP commands. Another bad situation is that many ISP's/hosts attempt to throttle the speed you can send email by purposefully making their SMTP servers respond slowly. Even worse, some hosts will go so far as to actually make subsequent connections over a set time period progressively slower. This can significantly impact your site performance since you are typically having your page code blocked during the SMTP send.
The best solution would be to use a host or SMTP server that does not enforce such restrictive measures. Barring that, there is a way to work around this by using message queuing. If you are using CDO, this means you have to configure the Microsoft SMTP Service on your IIS web server for use. This can be configured properly even if you do have other SMTP software on the IIS machine. Once the Microsoft SMTP Service is running on your IIS server, it will be able to queue email on the server and forward them to the configured SMTP server asynchronously to your application / page code. When configuring the Microsoft SMTP Service, you must define what it calls a "smart host". This is simply the SMTP server you are going to route the outbound email to for delivery on your network.
Once you have that configured, you just have to change your code that uses CDO to queue the email message instead of trying to send it. In your CDO code, you should have a line that sets CDO field values which look something like this:
You want to change the value for the "sendusing" field from a value of 2 to a value of 1. These are the enumerated values for the cdoSendUsingPort (2) and cdoSendUsingPickup (1) enums. Once you do this, you can also drop the "smtpserver" and "smtpserverport" fields as these are overridden by however your Microsoft SMTP Service is configured. Once you do this, your asp code will quickly generate the email message and it will be queued in the IIS server's mail pickup folder. So your application / page code will run much faster. The outgoing emails will potentially accumulate in the queue folder as the SMTP Service slowly works on delivering them in the background. It doesn't make the email get send any faster, but it does prevent your code from blocking due to a slow SMTP server.
后来我发现问题并不是由电子邮件的实际发送引起的，而是因为我通过从另一个 ASP 页面（通过 XML 对象）检索 HTML 来生成电子邮件的 HTML 正文。
我尝试了各种方法来解决该问题，包括切换邮件组件（到 Jmail）和使用不同版本的 XML 对象，但问题仍然会间歇性地发生。
最后，我更改了代码以生成电子邮件正文的 HTML，而不是调用另一个 ASP 页面并读取它的响应。
消除 XML 对象的使用似乎已经解决了问题，但从未找到原因。
I later found that the actual sending of the email was not causing the problem but the fact that I was generating the HTML body for the email by retrieving HTML from another ASP page (via the XML object).
I tried various things to fix the problem including switching mail components (to Jmail) and using different versions of the XML object but the problem would still occur intermittently.
In the end I changed the code to generate the HTML for the email body instead of calling another ASP page and reading it's response.
Eliminating use of the XML object seems to have resolved the problem but the cause was never found.