TCPIP-channel-specific options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


TCP/IP-channel-specific options

TCP/IP channels  support, in addition to the usual channel options, a number of TCP/IP-channel-specific options.1 These TCP/IP-channel-specific options are set in legacy configuration in a channel-specific option file, or in Unified Configuration are set under the channel's options option. For instance: 


msconfig> set channel:tcp_local.options.BANNER_PURGE_DELAY 200

Note that in Unified Configuration such channel-specific options (those set under the options option) are not (currently) schema checked: be careful when setting them as msconfig will not warn of invalid values or syntax as it would for regular channel options! (Nor will msconfig show whether or not such channel-specific options have any default value.)

In legacy configuration, where an option file is used, such an option file must be named x_option where x is the name of the channel, and stored in the MTA table directory. Since the name of the default channel for the SMTP server is usually tcp_local, the option file for the SMTP server is usually IMTA_TABLE:tcp_local_option on UNIX; similarly, the name of the default channel for the SMTP SUBMIT server is usually tcp_submit, so the option file for the SMTP SUBMIT server is usually IMTA_TABLE:tcp_submit_option.

For incoming messages, such TCP/IP-channel-specific options are actually options for the server (SMTP, SMTP SUBMIT, or LMTPSS) as a whole. In particular, the only TCP/IP-channel-specific options that matter for incoming SMTP submissions are those for the SMTP server's default channel, not any channel options for possible other channels that may putatively handle the incoming message due to a *switchchannel channel option based "switching". Thus for instance in a typical configuration, for all incoming SMTP messages to port 25, it is only the channel-specific options set under channel:tcp_local.options that matter (in legacy configuration, only the tcp_local_option file that matters); similarly, the channel-specific options set under channel:tcp_submit.options affect all SMTP SUBMIT submissions (in legacy configuration, the tcp_submit_option file affects all SMTP SUBMIT submissions); and the channel-specific options set under channel:tcp_lmtpss.options affect all messages accepted by the LMTP server (in legacy configuration, the tcp_lmtpss_option file affects all messages accepted by the LMTP server). Any other channel-specific options (in legacy configuration, any other tcp_*_option file(s)) would only be potentially relevant for outgoing SMTP or LMTP messages---only affect SMTP or LMTP client operation.

Note that while master channel programs (the outgoing channel direction or SMTP client) read their option file each time they run and usually do not keep running for an especially long time, a slave channel program (each SMTP, SMTP SUBMIT, or LMTP server process) reads its options (in legacy configuration, its option file) only when it is first started, hence will not see changes while it continues to run, and its running time may be on the scale of hours. Server processes do automatically shut down periodically, and the Dispatcher creates new server processes in replacement, as required; so changes affecting server processes can get seen eventually, even in the absence of an explicit restart of the relevant server processes---but the change is likely not to take effect "quickly" in the absence of an explicit restart.

Note also that as of Messaging Server 7.0, TCP/IP channel option files for SMTP channels and LMTP client channels (but not yet LMTP server channels) are incorporated as part of a compiled configuration, if one exists. So as of Messaging Server 7.0, if a compiled configuration exists, it is necessary to recompile to get changes seen: 


# imsimta cnbuild

Then, no different than ever, when it is important or essential to get changes to take effect quickly, as opposed to waiting for existing server processes and channel delivery processes to naturally age, executing 


# imsimta restart *

will restart (the otherwise often quite long-running) SMTP, SMTP SUBMIT, and LMTP server processes; and see the imsimta qm utility's stop and start commands, or alternatively its stress and unstress commands, which may be used to force quick replacement of the (usually relatively short-lived in any case) SMTP and LMTP client processes (master channel jobs).

1Most of the options described actually relate to the SMTP protocol itself, rather than to the TCP/IP transport. As such, other MTA channels that use the SMTP protocol over other transports may have similar options.


See also:

Retrieved from "https://msg.wikidoc.info/index.php?title=TCPIP-channel-specific_options&oldid=27217"