Symptoms: Messages are not delivered in a timely manner.
The sending server is limiting the number of simultaneous outbound connections to any individual server. Increase the limit on the number of simultaneous connections.
Normally, a sending server does not open numerous simultaneous connections to any one server, and so the simultaneous-connection limit is not a bottleneck. However, when you route your e-mail through Postini Outbound Services, all connections from your sending server are opened to just one fully qualified domain name.
With Microsoft Exchange, this issue can occur when a Microsoft connector sends out a message through a smarthost and that smarthost relays an error or deferral back to the connector. The connector responds as if this were a problem with the smarthost rather than recognizing that the smarthost is relaying a response from a third party.
The connector marks its "link state" as down for the next retry interval (by default, 10 minutes) before trying again to send out mail through the smarthost. The link state can be suppressed so that the mail flow does not consider the connector state when deciding whether to try to send a message.
For more information, see:
- Exchange 2003 document from Microsoft KB: http://technet.microsoft.com/en-us/library/875ae7f8-446d-4786-85d2-719ac7093cf6.aspx
- Exchange 2000 document from Microsoft KB: http://support.microsoft.com/kb/263249/
With Lotus Domino, you can experience:
- Intermittent delays because the Domino server stops processing outbound mail flow and the queue backs up.
- Ongoing delays when outbound queues on the Domino server back up with hundreds of messages, eventually causing the router process to fail.
Fixing intermittent delays
With intermittent delays, the SMTP log on the Domino server may show entries (depending on your logging level) such as SMTPClient: Remote host no longer responding. This issue is usually caused by the Domino server encountering a message that Postini failed to deliver to the receiving mail server in a timely fashion.
To fix the delay, set the Initial Transfer Retry Interval to a value of 6 minutes or less. On a Domino server, when an issue such as this occurs, all further connections to the server for which the message was destined are blocked until the Retry Interval expires. Since Outbound Services are being used, all messages are bound for the same server, meaning that the entire queue stops processing. We recommend a Retry Interval of no higher than 6 minutes to allow the queue to start moving again more quickly. You may choose to use a lower value depending on your environment and requirements.
Fixing ongoing delays
Ongoing delays can occur with Domino servers version 5.9.01 and later that have SMTPS turned on. The SMTP log on the Domino server may show entries (depending on your logging level) similar to SMTPClient: Remote host not responding. SMTPS is turned on by default, and this causes Domino servers try to connect to port 465 before trying SMTP over TLS (your old port 25), and the initial connection failure cause the delivery queue (the "router" process) to start backing up. Ultimately, the back up causes the router process to fail, and requires restarting.
To fix the delay, disable the SMTPS option. (Note: Turning off SMTPS does not disable encrypted email; you are simply turning off the connection to the old SMTPS port (465). You can still use SMTP over TLS, which uses port 25.)Editions: This article is intended for administrators using Message Security for Google Apps. If you're using another edition, your service may include different features from those described in this article.
Keywords: outbound, delayed, Exchange, smarthost, simultaneous connections, Domino, retry interval