IP_ACCESS mapping table
One form of SMTP and LMTP client connection control is provided by the
IP_ACCESS mapping table. The
IP_ACCESS mapping table was added for MS 6.3.
IP_ACCESS access mapping table is consulted during SMTP/LMTP client operations just prior to attempting to open connections to a remote server. (In particular, and as compared to the
AUTH_ACCESS mapping, the
IP_ACCESS mapping is consulted after MX record lookup just before the A record is used.) It thus allows a "last moment" or "last ditch" check on the IP address to which the client would otherwise be about to connect---with the mapping table being able to cause the connection attempt to be aborted or redirected. This has the potential to be useful under certain special circumstances, such as security concerns where some potential destination IP address should never be connected to, or where it is wished to avoid connecting to known-to-be-bogus destination IP addresses (e.g., 127.0.0.1 -- see also the
loopcheck channel option), or where there is a desire to attempt to "fail over" to another destination IP address (similar to a
lastresort channel option effect).
IP_ACCESS mapping table probe has the following default format:
Or if bit 0 (value 1) of the (new in Messaging Server 7.0-0.04)
use_ip_access MTA option is set, then the format is:
source-channel is the channel from which the message is being dequeued,
ip-count is the total number of IP addresses for the remote server,
ip-current-count is the index of the current IP address being tried,
ip-current-address is the current IP address,
hostname is the symbolic name of the remote server, and
retry-count is what number delivery attempt this is (based on how many prior delivery attempts, as determined by the message filename) or
-1 if the data is not available (if the message filename does not follow the MTA's normal message filenaming conventions).
The mapping can set the flags shown in Table of
IP_ACCESS mapping flags. In particular, setting a
$f flag will cause the connection attempt to be aborted.
|$N||Immediately reject the connection attempt, hence immediately bounce the message, generating a notification message with a "Illegal host/domain name found" reason and a "5.4.4 Illegal host/domain name found" error status in the notification message. Any supplied text will be logged as the reason for rejection but will not be included in the DSN.|
|$F||Synonym for $N: immediately reject the connection attempt and hence the message.|
|$I||Skip the current IP without attempting to connect.|
|$A||Replace the current IP address with the mapping result.|
Possible applications of
- Detect when an apparently innocuous remote destination domain name resolves in the DNS to a known "bad" or "malicious" IP address, and abort (or redirect) connections to that remote destination.
- Detect and work around internal network or configuration problems, such as "surprise" internal host name assignments, to detect and avoid host name use that might otherwise result in messages looping or being misrouted.
- Forcibly re-route (or alternatively bounce) messages that have had multiple unsuccessful delivery attempts.
- Limit the number of MX records attempted on a per-hostname basis (as opposed to use of the TCP/IP-channel-specific option MAX_MX_RECORDS).
Call out from
IP_ACCESSto a MeterMaid table to achieve "throttling" of outbound connection attempts to some specially limited remote server.
As a concrete example, here is an example of throttling outbound connections performed by a special, dedicated-to-delivery-to-a-special-destination, channel. Note that this is not generally a useful or appropriate thing to do. Limits on a remote server are its business, and under its control. Any special configuration you attempt may become out-of-date, or counter-productive in any of several ways, with no notice to you. And usually the MTA's normal scheduling, retry strategies, and load management are effective and adaptable to wide ranges of circumstances, including even unusual remote server problems. Furthermore, attempting to "work around" limits that a remote server has intentionally imposed are likely to backfire if (or more likely when) the remote server notices you "pushing" its limit and instead decides to block all your system's submissions outright. However, should such special outbound throttling still be desired...
In this example, a "special", three limited remote destination domains are assumed to be slow1.domain.com, slow2.domain.com, and slow3.domain.com, assumed to be only able to accept two hundred messages per MX host every thirty minutes.
! Special rewrite rules to route slow1.domain.com, slow2.domain.com, and ! slow3.domain.com out the special new tcp_outlimit channel: ! slow1.domain.com $U%slow1.domain.com@tcp-outlimit-daemon slow2.domain.com $U%slow2.domain.com@tcp-outlimit-daemon slow3.domain.com $U%slow3.domain.com@tcp-outlimit-daemon ! Special channel for the throttled outbound messages. ! It is a good idea to have such a special channel for handling ! the throttled outbound messages since this channel may be more prone than ! a normal channel to getting backlogged with not-yet-delivered messages. ! tcp_outlimit smtp mx backoff pt30 ...keywords-similar-to-tcp_local... tcp-outlimit-daemon
In legacy configuration:
metermaid.table.outthrottle.type = throttle metermaid.table.outthrottle.data_type = ipv4 metermaid.table.outthrottle.value_type = integer metermaid.table.outthrottle.max_entries = 50 metermaid.table.outthrottle.quota = 200 metermaid.table.outthrottle.quota_time = 1800
or in Unified Configuration:
msconfig> show metermaid.local_table:outthrottle.* metermaid.local_table.table_type = throttle metermaid.local_table.data_type = ipv4 metermaid.local_table.value_type = integer metermaid.local_table.max_entries = 50 metermaid.local_table.quota = 200 metermaid.local_table.quota_time = 1800 IP_ACCESS ! For the special destination domains slow1.domain.com, slow2.domain.com, ! slow3.domain.com: ! Check the current destination IP address against MeterMaid outthrottle table. ! If over the outthrottle table's limit, this connection attempt will be ! skipped due to $I. ! tcp_outlimit|*|*|*|slow1.domain.com \ $C$[IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2]$I tcp_outlimit|*|*|*|slow2.domain.com \ $C$[IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2]$I tcp_outlimit|*|*|*|slow3.domain.com \ $C$[IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2]$I ! ! Otherwise, fall through and perform the connection attempt as usual.