12.4.3 TCP/IP Connection and DNS Lookup Support

You can specify information about how the server handles TCP/IP connections and address lookups. This section describes the following:

• 12.4.3.1 TCP/IP Port Number and Interface Address

• 12.4.3.2 Caching for Channel Connection Information

• 12.4.3.3 Reverse DNS Lookups

• 12.4.3.4 IDENT Lookups

• 12.4.3.5 TCP/IP MX Record Support

• 12.4.3.6 Nameserver Lookups

• 12.4.3.7 Last Resort Host

• 12.4.3.8 Alternate Channels for Incoming Mail (Switch Channels)

• 12.4.3.9 Source Channel Switching Based on User or Domain Settings

• 12.4.3.10 Target Host Choice

Table 12–22 lists the TCP/IP connection and DNS lookup keywords described in this section.

Table 12–22 TCP/IP Connection and DNS Lookup Keywords

Channel Keyword(s)	Description
Port Selection and Interface Address	Specifies the default port number and interface address for SMTP connections
port	Specifies the default port number for SMTP connections. The standard port is 25.
interfaceaddress	Binds to the specified TCP/IP interface address.
Cache Keywords	Specifies how connection information is cached
cacheeverything	Caches all connection information.
cachefailures	Caches only connection failure information.
cachesuccesses	Caches only connection success information.
nocache	Does not cache any connection information.
Reverse DNS Lookups	Specifies how to handle Reverse DNS lookups on incoming SMTP connections
forwardcheckdelete	If a reverse DNS lookup has been performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, deletes the name and use the IP address.
forwardchecknone	Does not perform a forward lookup after a DNS reverse lookup.
forwardchecktag	If a reverse DNS lookup has been performed, next performs a forward lookup on the returned name to check that the returned IP number matches the original; if not, tags the name with *.
IDENT Lookups/DNS Reverse Lookups	Specifies how to handle IDENT lookups and DNS Reverse Lookups on incoming SMTP connections
identnone	Does not perform IDENT lookups; does perform IP to hostname translation; includes both hostname and IP address in Received: header.
identnonelimited	Does not perform IDENT lookups; does perform IP to hostname translation, but does not use the hostname during channel switching; includes both hostname and IP address in Received: header.
identnonenumeric	Does not perform IDENT lookups or IP to hostname translation.
identnonesymbolic	Does not perform IDENT lookups; does perform IP to hostname translation; includes only the hostname in Received: header.
identtcp	Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; include both hostname and IP address in Received: header
identtcplimited	Performs IDENT lookups on incoming SMTP connections and IP to hostname translation, but do not use the hostname during channel switching. Includes both hostname and IP address in Received: header.
indenttcpnumeric	Performs IDENT lookups on incoming SMTP connections, but does not perform IP to hostname translation.
identtcpsymbolic	Performs IDENT lookups on incoming SMTP connections and IP to hostname translation; includes only hostname in Received: header.
MX Record Support and TCP/IP Nameserver	Specifies whether and how the channel supports MX record lookups
mx	TCP/IP network and software supports MX records lookup.
nomx	TCP/IP network does not support MX lookups.
defaultmx	Channel determines whether to do MX lookups from network.
randommx	Does MX lookups; randomizes returned entries with equal precedence.
nonrandomemx	Does MX lookups; does not randomize returned entries with equal precedence.
nameservers	Specifies a list of nameservers to consult rather than consulting the TCP/IP stack's own choice of nameservers; nameservers requires a space separated list of IP addresses for the nameservers.
defaultnameservers	Consults TCP/IP stack’s choice of nameservers.
lastresort	Specifies a last resort host.
Switch keywords	Controls selection of alternate channels for incoming mail
allowswitchchannel	Allows switching to this channel from a switchchannel channel
noswitchchannel	Stays with the server channel; does not switch to the channel associated with the originating host; does not permit being switched to.
switchchannel	Switches from the server channel to the channel associated with the originating host.
userswitchchannel	Source channel switching based on user or domain settings.
tlsswitchchannel	Switches to another channel upon successful TLS negotiation.
saslswitchchannel	Switches to another channel when SASL authentication is successful.
Target Host Choice and Storage of Message Copies	Specifies a target host system and how message copies are stored.
daemon	Connects to a specific host system regardless of the envelope address.
single	Specifies that a separate copy of the message should be created for each destination address on the channel.
single_sys	Creates a single copy of the message for each destination system used.

12.4.3.1 TCP/IP Port Number and Interface Address

Keywords: port, interfaceaddress

The SMTP over TCP/IP channels normally connect to port 25 when sending messages. The port keyword can be used to instruct an SMTP over TCP/IP channel to connect to a nonstandard port. Note that this keyword complements the Dispatcher option PORT, which controls which ports the MTA listens on for accepting SMTP connections.

The interfaceaddress keyword controls the address to which a TCP/IP channel binds as the source address for outbound connections; that is, on a system with multiple interface addresses this keyword controls which address will be used as the source IP address when the MTA sends outgoing SMTP messages. Note that this keyword complements the Dispatcher option INTERFACE_ADDRESS, which controls which interface address a TCP/IP channel listens on for accepting incoming connections and messages.

12.4.3.2 Caching for Channel Connection Information

Keywords: cacheeverything, nocache, cachefailures, cachesuccesses

Channels using the SMTP protocol maintain a cache containing a history of prior connection attempts. This cache is used to avoid reconnecting multiple times to inaccessible hosts, which can waste lots of time and delay other messages. The cache is a per process cache and only persists during a single run of the outbound SMTP delivery channel.

The cache normally records both connection successes and failures. (Successful connection attempts are recorded in order to offset subsequent failures—a host that succeeded before but fails now doesn't warrant as long of a delay before making another connection attempt as does one that has never been tried or one that has failed previously.)

However, the caching strategy used by the MTA is not necessarily appropriate for all situations. Therefore channel keywords are provided to adjust the MTA cache.

The cacheeverything keyword enables all forms of caching and is the default. The nocache keyword disables all caching.

The cachefailures keyword enables caching of connection failures but not successes—this forces a somewhat more restricted retry than cacheeverything does. Finally, cachesuccesses caches only successes. This last keyword is effectively equivalent to nocache for SMTP channels.

12.4.3.3 Reverse DNS Lookups

Keywords: forwardchecknone, forwardchecktag, forwardcheckdelete

The forwardchecknone, forwardchecktag, and forwardcheckdelete channel keywords can modify the effects of doing reverse DNS lookups. These keywords can control whether the MTA does a forward lookup of an IP name found using a DNS reverse lookup, and if such forward lookups are requested, specify what the MTA does if the forward lookup of the IP name does not match the original IP number of the connection.

The forwardchecknone keyword is the default, and means that no forward lookup is done. The forwardchecktag keyword tells the MTA to do a forward lookup after each reverse lookup and to tag the IP name with an asterisk (*), if the number found using the forward lookup does not match that of the original connection. The forwardcheckdelete keyword tells the MTA to do a forward lookup after each reverse lookup and to ignore (delete) the reverse lookup returned name if the forward lookup of that name does not match the original connection IP address; in this case, the MTA uses the original IP address instead.

---

Note –

Having the forward lookup not match the original IP address is normal at many sites, where a more “generic” IP name is used for several different IP addresses.

---

12.4.3.4 IDENT Lookups

Keywords: identnone, identnonelimited, identtnonnumeric, identnonesymbolic, identtcp, identtcpnumeric, identtcpsymbolic, identtcplimited

The IDENT keywords control how the MTA handles connections and lookups using the IDENT protocol. The IDENT protocol is described in RFC 1413.

The identtcp, identtcpsymbolic, and identtcpnumeric keywords tell the MTA to perform a connection and lookup using the IDENT protocol. The information obtained from the IDENT protocol (usually the identity of the user making the SMTP connection) is inserted into the Received: header of the message as follows:

• identtcp inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup and the IP number itself.

• identtcpsymbolic inserts the host name corresponding to the incoming IP number, as reported from a DNS reverse lookup; the IP number itself is not included in the Received: header.

• identtcpnumeric inserts the actual incoming IP number—no DNS reverse lookup on the IP number is performed.

---

Note –

The remote system must be running an IDENT server for the IDENT lookup caused by identtcp, identtcpsymbolic, or identtcpnumeric to be useful.

---

Be aware that IDENT query attempts may incur a performance hit. Increasingly routers will “black hole” attempted connections to ports that they don’t recognize. If this happens on an IDENT query, then the MTA does not hear back until the connection times out (a TCP/IP stack controlled time-out, typically on the order of a minute or two).

Another performance factor occurs when comparing identtcp, indenttcplimited, or identtcpsymbolic to identtcpnumeric. The DNS reverse lookup called for with identtcp, identtcplimited, or identtcpsymbolic incurs some additional overhead to obtain the more user-friendly host name.

The identnone keyword disables IDENT lookup, but does specify IP to host name translation, and both IP number and host name will be included in the Received: header for the message.

The identnonesymbolic keyword disables IDENT lookup, but does do IP to host name translation; only the host name will be included in the Received: header for the message.

The identnonenumeric keyword disables this IDENT lookup and inhibits the usual DNS reverse lookup translation of IP number to host name, and might result in a performance improvement at the cost of less user-friendly information in the Received: header. This is the default.

The identtcplimited and identnonelimited keywords have the same effect as identtcp and identnone, respectively, as far as IDENT lookups, reverse DNS lookups, and information displayed in Received: header. Where they differ is that with identtcplimited or identnonelimited the IP literal address is always used as the basis for any channel switching due to use of the switchchannel keyword, regardless of whether the DNS reverse lookup succeeds in determining a host name.

12.4.3.5 TCP/IP MX Record Support

Keywords: mx, nomx, defaultmx, randommx, nonrandommx

Some TCP/IP networks support the use of MX (mail forwarding) records and some do not. Some TCP/IP channel programs can be configured not to use MX records if they are not provided by the network that the MTA system is connected to. The mx, nomx, defaultmx, randommx, nonrandommx keywords control MX record support.

The keyword randommx specifies that MX lookups should be done and MX record values of equal precedence should be processed in random order. The keyword 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 keyword is currently equivalent to nonrandommx; it might change to be equivalent to randommx in a future release. The nomx keyword disables MX lookups. The defaultmx keyword specifies that mx should be used if the network says that MX records are supported. The keyword defaultmx is the default on channels that support MX lookups in any form.

12.4.3.6 Nameserver Lookups

Keywords: nameservers, defaultnameservers

When name server lookups are being performed, the nameservers channel keyword may be used to specify a list of name servers to consult rather than consulting the TCP/IP stack's own choice of name servers. The nameservers keyword requires a space separated list of IP addresses for the name servers, as shown in the following example:

nameservers 1.2.3.1 1.2.3.2

The default, defaultnameservers, means use the TCP/IP stack's own choice of name servers.

To prevent name server lookups on UNIX, you can modify the nsswitch.conf file. On NT, modify the TCP/IP configuration.

12.4.3.7 Last Resort Host

Keywords: lastresort

The lastresort keyword is used to specify a host to connect to even when all other connection attempts fail. In effect this acts as an MX record of last resort. This is only useful on SMTP channels.

The keyword requires a single parameter specifying the name of the “system of last resort.” For example:

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

12.4.3.8 Alternate Channels for Incoming Mail (Switch Channels)

Keywords: switchchannel, allowswitchchannel, noswitchchannel. See also saslswitchchannel on 12.4.4 SMTP Authentication, SASL, and TLS, and tlsswitchchannel on 12.4.8 Transport Layer Security and userswitchchannel on 12.4.3.9 Source Channel Switching Based on User or Domain Settings

The following keywords control selection of an alternate channel for incoming mail: switchchannel, allowswitchchannel, noswitchchannel.

When the MTA accepts an incoming connection from a remote system, it must choose a channel with which to associate the connection. Normally this decision is based on the transfer used; for example, an incoming SMTP over TCP/IP connection is automatically associated with the tcp_local channel.

This convention breaks down, however, when multiple outgoing channels with different characteristics are used to handle different systems over the same transfer. When this happens, incoming connections are not associated with the same channel as outgoing connections, and the result is that the corresponding channel characteristics are not associated with the remote system.

The switchchannel keyword provides a way to eliminate this difficulty. If switchchannel is specified on the initial channel the server uses, the IP address of the connecting (originating) host will be matched against the channel table and if it matches the source channel will change accordingly. If no IP address match is found or if a match is found that matches the original default incoming channel, the MTA may optionally try matching using the host name found by doing a DNS reverse lookup. The source channel may change to any channel marked switchchannel or allowswitchchannel (the default). The noswitchchannel keyword specifies that no channel switching should be done to or from the channel.

Specification of switchchannel on anything other than a channel that a server associates with by default has no effect. At present, switchchannel only affects SMTP channels, but there are actually no other channels where switchchannel would be reasonable.

12.4.3.9 Source Channel Switching Based on User or Domain Settings

Keywords: userswitchchannel. See also switchchannel on 12.4.3.8 Alternate Channels for Incoming Mail (Switch Channels)

Source channel switching based on user or domain settings is now possible. There are three new settings involved:

1. A new channel keyword userswitchchannel. This keyword must be present on the initial source channel for user channel switching to occur.

2. A new MTA option LDAP_DOMAIN_ATTR_SOURCE_CHANNEL that specifies the name of a domain-level attribute containing the name of the channel to which to switch.

3. A new MTA option LDAP_SOURCE_CHANNEL that specifies the name of a user-level attribute containing the name of the channel to which to switch.

Additionally, the channel being switched to must be set to allow channel switches. That is, it cannot be marked with the noswitchchannel keyword. Switching is done based on information returned by rewriting the MAIL FROM address. Note that MAIL FROM addresses are easily forged so this functionality should be used with extreme care.

12.4.3.10 Target Host Choice

Keywords: daemon, multiple, single, single_sys

The interpretation and usage of the daemon keyword depends upon the type of channel to which it is applied.

The daemon keyword is used on SMTP channels to control the choice of a target host.

Normally, channels connect to whatever host is listed in the envelope address of the message being processed. The daemon keyword is used to tell the channel to instead connect to a specific remote system, generally a firewall or mail hub system, regardless of the envelope address. The actual remote system name should appear directly after the daemon keyword, as shown in the following example:

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

If the argument after the daemon keyword is not a fully qualified domain name, the argument will be ignored and the channel will connect to the channel's official host. The official host is the fully qualified hostname associated with the channel. This can be specified in the second line of a three line channel block:

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

The official host can also be specified after TCP-DAEMON in a two-line channel block so outbound connections will identify themselves as a particular host:

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

When specifying the firewall or gateway system name as the official host name, the argument given to the daemon keyword is typically specified as router, as shown in the following example:

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

Messaging Server allows multiple destination addresses to appear in each queued message. Some channel programs, however, may only be able to process messages with one recipient, or with a limited number of recipients, or with a single destination system per message copy. For example, the SMTP client programs for the TCP/IP channels only establish a connection to a single remote host in a given transaction, so only addresses to that host can be processed (this despite the fact that a single channel is typically used for all TCP/IP traffic).

Other keywords of interest are multiple, single and single_sys. The multiple keyword, the default, creates a single copy of the message for the entire channel. The single keyword specifies that a separate copy of the message should be created for each destination address on the channel. The single_sys keyword creates a single copy of the message for each destination system used. Note that at least one copy of each message is created for each channel the message is queued to, regardless of the keywords used.