IP ACCESS mapping table

One form of SMTP and LMTP client connection control is provided by the  mapping table. The   mapping table was added for MS 6.3.

The  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    mapping,  the   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   channel option),  or where there is a desire to attempt to  "fail over" to another destination IP address (similar to a    channel option effect).

The  mapping table probe has the following default format: source-channel&#x7c;ip-current-count&#x7c;ip-count&#x7c;ip-current-address&#x7c;hostname Or if bit 0 (value 1) of the (new in Messaging Server 7.0-0.04)   MTA option is set,  then the format is: source-channel&#x7c;ip-current-count&#x7c;ip-count&#x7c;ip-current-address&#x7c;hostname&#x7c;retry-count Here   is the channel from which the message is being dequeued,   is the total  number of IP addresses for the remote server,    is the index of the current IP  address being tried,   is the  current IP address,   is the symbolic name  of the remote server, and   is what  number delivery attempt this is (based on how many prior delivery  attempts, as determined by the message filename) or   if  the data is not available (if the message filename does not follow the  MTA&#x27;s normal message filenaming conventions).

The mapping can set the flags shown in Table of   mapping flags. In particular, setting a ,  ,  , or    flag will cause the connection attempt to be aborted.

Possible applications of  include:



 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  to 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&#x27;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&#x27;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&#x3e; show metermaid.local_table:outthrottle.&#x2a; 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&#x27;s limit, this connection attempt will be ! skipped due to $I. !   tcp_outlimit&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;slow1.domain.com  \ $C$&#x5b;IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2&#x5d;$I tcp_outlimit&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;slow2.domain.com \ $C$&#x5b;IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2&#x5d;$I tcp_outlimit&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;slow3.domain.com \ $C$&#x5b;IMTA_LIB:check_metermaid.so,throttle,outthrottle,$2&#x5d;$I ! ! Otherwise, fall through and perform the connection attempt as usual.

See also:
 * AUTH_ACCESS mapping table
 * MX_ACCESS mapping table
 * use_ip_access MTA Option
 * TCPIP-channel-specific options
 * TCPIP channels
 * MeterMaid