Mx, nomx, nodns, defaultmx, randommx, nonrandommx, affinitylist, nameservers, defaultnameservers Channel Options
TCP/IP nameserver and MX record support (mx, nomx, nodns, defaultmx, randommx, nonrandommx, affinitylist, nameservers, defaultnameservers)
Most TCP/IP networks support the use of MX (mail forwarding) records for SMTP relay but a few do not. The MTA's TCP/IP channel programs can be configured to not use MX records if they are not provided by the network to which the MTA system is connected. Some TCP/IP channel programs can be configured to not do DNS (nameserver) lookups at all. randommx specifies that MX lookups should be done and MX record values of equal precedence should be processed in random order. nonrandommx specifies that MX lookups should be done and MX values of equal precedence should be processed in the same order in which they were received. The mx option is currently equivalent to nonrandommx; it may change to be equivalent to randommx in a future release. The nomx option disables MX lookups. The defaultmx option specifies that mx should be used (with randomization) if the network says that that MX records are supported, and if the destination port is port 25 for SMTP; (with defaultmx, destination ports other than port 25 do not get MX lookups by default).
LMTP channels do not normally make use of MX lookups. Additionally, LMTP channels need to connect to the correct store taking failover events into account. As of the 8.0 release, the affinitylist channel option provides this functionality. affinitylist disables MX lookups completely and translates the logical host given into the corresponding affinity group. Connections are then attempted sequentially to all the hosts in the group.
The default is defaultmx on channels that support MX lookups in any form.
New in MS 8.0 is specialized handling for MX entries of the form:
nomail IN MX 0 .
Such entries are intended to be an indication that host "nomail" does not operate a mail server. So when MX lookups are enabled, attempts to send to such a host will fail immediately after the MX lookup instead of attempting any sort of A record lookup. (Additionally, mailfromdnsverify will treat such hosts as not being a valid source of mail.)
Whether the operating system's TCP/IP local host tables are used in addition to the DNS for lookups is generally controlled by /etc/nsswitch.conf or the equivalent. Generally, operating system distributions are configured so that local host tables will indeed be consulted.
When nameserver lookups are being performed, that is, unless the nsswitch.conf file selects no use of nameservers, then prior to Messaging Server 7.0 the nameservers channel option may be used to specify a list of nameservers to consult rather than consulting the TCP/IP stack's own choice of nameservers. This affects the SMTP server and client and LMTP client, but not the LMTP server (which, if it needs to do any lookups, always relies on the TCP/IP stack's own choice of nameservers). Futhermore, as of Messaging Server 7.0, the nameservers channel option only affects MX record lookups, with all other lookups using the TCP/IP stack's choice of nameservers regardless of any nameservers channel option setting. nameservers requires a space separated list of IP addresses for the nameservers, e.g.,
1.2.3.1 1.2.3.2
defaultnameserversis the default, and means to use the TCP/IP stack's own choice of nameservers.
Note that while a nameservers setting is primarily meaningful to the SMTP client -- hence TCP/IP destination channels -- it also, prior to Messaging Server 7.0, potentially had meaning to the SMTP server -- hence TCP/IP source channels -- as for instance in cases where the SMTP server channel had been configured to perform DNS reverse lookups on incoming connections, or to perform forms of DNS verification.
See also:
