REUSE TIMED OUT TRANSFERS

TCP/IP-channel-specific options: REUSE_TIMED_OUT_TRANSFERS (0 or 1)
This SMTP server option controls creation and use of   files; the default is 1, meaning that such  files may be created and used. More specifically, this option controls whether the MTA writes and uses    files (MS 6.3 and  earlier) or in JS Messaging Server 7.0,    files. If enabled, the MTA writes such a file in cases where an SMTP client  connection is dropped after the MTA has received the final  "." terminating the message data, but before the MTA has successfully sent its "250 2.5.0 Ok." message acknowledging the receipt of the message back to the client, and checks for the  existence of such a file when receiving an incoming message (so as to  detect a "duplicate" attempted message submission). When such files are being created/used, the MTA will do a hash of each incoming  message to compare the hash against any stored    files to determine whether the current  incoming message had in fact already been received in a previous  transaction. When the MTA does see such a case, the MTA will issue a 250 2.5.0 Prior aborted transfer used success back to the sending client (after the client finishes sending the message data). The MTA will only create such a   file in the case of an incoming message  where there was a significant delay in our sending of the "250  ok"; see the    TCP/IP-channel-specific option. The MTA assumes that cases of "short" disconnect times are where it&#x27;s just a  poorly behaved client, one that likes to disconnect immediately without  waiting for the acknowledgement, that won&#x27;t in fact be resending the  message. Whereas the "long" timeout case, where the MTA will still make the   file, is a case where it&#x27;s  reasonable that the client timed out on the connection, and the client  likely will feel a need to try resending the message.

The  files are normally retained in the  incoming TCP/IP channel&#x27;s   subdirectory for the  number of days specified by an IMTA_TCP_FLAG_RETENTION Tailor option,  which defaults to 7 if not explicitly set. (The   MTA option  has no effect here; this Tailor option is always interpreted in units  of days.) Thus by default (no IMTA_TCP_FLAG_RETENTION Tailor option  set) such   files are retained for seven days. Note that disabling the MTA&#x27;s SMTP server creation and use of   files by setting     can provide a noticable performance (throughput) increase---perhaps 30%  for the SMTP server; the downside is that disabling their use means  that the MTA will no longer detect and avoid certain cases of duplicate  submissions of messages, so users may receive "duplicate"  copies of messages that might have been avoided.

See also:
 * FAST_SMTP_SESSION_TIME_LIMIT
 * return_units MTA Option
 * TCPIP-channel-specific options