Timeouts

Wait xx seconds for sockets to connect before giving up

After initiating a connection request MDaemon will wait this many seconds for the remote system to accept the connection. If the remote system does not respond within this time frame, MDaemon will send the message to a specified Server or place it into the retry system, depending upon which option you have chosen on the Domain screen of the Default Domain editor.

Wait xx seconds for protocol dialog to start before giving up

Once a connection has been established with a remote host, this is the number of seconds that MDaemon will wait for the remote host to begin the SMTP or POP3 protocol dialog. If the remote host does not begin the protocol session within this time frame, MDaemon will send the message to a specified Server or place it into the retry system, depending upon which option you have chosen on the Domain screen of the Default Domain editor.

Wait XX seconds for MX DNS server responses

While using DNS services to resolve 'MX' hosts for remote domains, MDaemon will wait for responses to its 'MX' queries for this number of seconds. If the DNS server does not respond within this time frame MDaemon will attempt to deliver the message to the IP address specified in the remote host's 'A' DNS record. If that attempt fails, MDaemon will send the message to a specified Server or place it into the retry system, depending upon which option you have chosen on the Domain screen of the Default Domain editor.

Wait XX seconds for A-Record DNS server responses

This timer governs how long MDaemon will wait while attempting to resolve a remote host's IP address. If the attempt fails, MDaemon will send the message to a specified Server or place it into the retry system, depending upon which option you have chosen on the Domain screen of the Default Domain editor.

Wait XX seconds for Minger server responses

This the the number of seconds that MDaemon will wait for a response from a Minger server.

SMTP and POP3 sessions timeout after XX inactive minutes

If a successfully connected and operating session remains inactive (no i/o) for this length of time, MDaemon will abort the transaction. MDaemon will try again at the next scheduled processing interval.

Wait on response to SMTP DATA command for XX minutes

This option governs how long MDaemon will wait for the "250 Ok" response after sending the DATA command during the SMTP process. Since some receiving servers perform lengthy anti-spam, anti-virus, or other necessary operations at that time, this option can be used to give them time to complete those tasks. The default is 10 minutes.

IMAP sessions timeout after xx inactive minutes

If an IMAP session has no activity for this number of minutes, MDaemon will close the session.

IMAP NOOP and IDLE commands trigger 1 minute inactivity timeout

When this checkbox is enabled, the IMAP inactivity timer will be set to one minute when a NOOP or IDLE command is encountered. Some IMAP clients will issue NOOP commands simply to keep sessions open even though there is no actual mail transaction activity going on. This feature will prevent such sessions from remaining active and thus will reduce resources consumed, which can be extremely useful for higher volume IMAP based mail sites.

Latency

Latency xx milliseconds

This is the delay in milliseconds between POP/SMTP/IMAP protocol commands. This is useful for preventing high-speed connections from processing data faster than the recipient can extract it. This delay takes effect only during the POP/SMTP/IMAP protocol command sequence the actual transfer of a mail message file is already fully buffered.

Loop Detection and Control

Maximum message hop count before message placed in bad queue (5-500)

RFC standards stipulate that a mail server must stamp each message each time that it is processed. These stamps can be counted and used as a stopgap measure against recursive mail loops that can sometimes be caused by errant configurations. If undetected, these looping message delivery cycles will consume your resources. By counting the number of times the message has been processed, such messages can be detected and placed in the bad message directory. The assumption is that if a message hasn't reached its recipient after being processed by a given number of mail servers then there is probably a mail loop in progress. Most likely, the default setting of this control should be sufficient to prevent mail loops and will not need to be changed.