Summary:

The following events in the EMF event log:

EMF 4.x
event id 101 - SMTP proxy expired
event id 105 - Connection to remote SMTP server expired unexpectedly

Later EMF versions
event id 1034 - SMTP connection expired
event id 1066 - Connection to remote host unexpectedly expired

Other network connection or timeout problems.

Detailed Information:

There are two different timeouts in effect when trying to connect to a remote server. The first is creating the socket connection to the remote machine on port 25. The other is once the socket is established, how long EMF waits for a 220 response indicating that the machine is ready to talk SMTP.

The first case, EMF attempting to create a TCP/IP connection to the remote machine, is not under the control of the EMF application, but is instead controlled by the operating system. When the EMF server fails to create a socket connection to the remote machine, it will first attempt to failover to the next MX Record. If there is no second MX record, or the second connection attempt fails too, EMF will put the message into the retry queue and try again later.

Once the TCP/IP session has been established, EMF will wait 5 minutes for the SMTP response code 220, meaning that the SMTP server is ready to accept a message. This 5 minutes is recommended by RFC 2821 and is not configurable within EMF. See the excerpt from RFC 2821 below for a list of other timeouts that are used by EMF.

Per RFC 2821 - section 4.5.3.2 Timeouts

Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many SMTP servers accept a TCP connection but delay delivery of the 220 message until their system load permits more mail to be processed.

MAIL Command: 5 minutes

RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and aliases is not deferred until after the message was accepted.

DATA Initiation: 2 minutes
This is while awaiting the "354 Start Input" reply to a DATA command.

Data Block: 3 minutes
This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.

DATA Termination: 10 minutes.
This is while awaiting the "250 OK" reply. When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful and would typically result in delivery of multiple copies of the message, since it has been successfully sent and the server has accepted responsibility for delivery.

Resolution:

An event in the EMF event log indicating an SMTP session has expired can usually be ignored since SMTP clients (including EMF) will either fail over to another relay or try again later. This may happen during very busy periods on the network when a packet may be lost.

Many events may indicate severe network issues (i.e. lost packets) between the EMF server and the remote host.

In rare cases the final packet indicating that an SMTP Server has accepted responsibility for a message may be lost (the final 250 in response to the end-of-data sequence). This can result in duplicate copies of messages being sent or received. The SMTP protocol tries to guarantee that every message be delivered at least once, but inherently can't guarantee that a message won't be delivered more than once. For more information about how the SMTP protocol works, see related article Using Telnet to manually send an SMTP message to a relay on the right.

In any case, 99% of the time (or more) connection timeouts or broken TCP connections are resolved by fixing the network or firewall, and the issue is not related to anything within EMF.

Additional Info:

http://www.imc.org/rfc2821