PORT ACCESS mapping table

The MTA Dispatcher is able to selectively accept or reject incoming connections to  the services it manages such as SMTP, SMTP SUBMIT,  or LMTP,  based on IP address and port number. At Dispatcher startup time, the Dispatcher will look for a mapping table named. If the mapping was present when the Dispatcher was started, then Dispatcher operation will include checking the mapping for each incoming connection. For each incoming connection the Dispatcher will format connection transport information in the form: TCP&#x7c;server-address&#x7c;server-port&#x7c;client-address&#x7c;client-port and try to match against all  mapping entries. If the result of the mapping contains  or ,  the connection will be immediately closed. Any other result of the mapping indicates that the connection is to be accepted. or  may optionally be followed by a rejection message. If present, the message will be sent back down the connection just prior to closure.

As of MS 8.0.1.3, tildes (~) may be used as delimiters between multiplie lines in order to create a multiline response. Also note that a CRLF terminator will be appended to the string before it is sent back down the connection.

If no entry matched, then and only then will any   lookups, as specified via a Dispatcher option (in particular in legacy configuration mode, in the Dispatcher configuration file), be performed, and the result of such a lookup is another way a connection may be refused. In particular, note that either an explicit rejection in, or (as MS 6.0) a match without a rejection hence an "accept" effect will prevent   lookups from occurring; this allows    to do initial filtering on connections, either "black listing" or "white listing" them, with    taking effect only on any other source IP addresses.

The flag  followed by an optional string causes the MTA to  send the string    to syslog (UNIX)   if the mapping probe matches; the flag   followed by an optional string causes the MTA to send the string   to syslog (UNIX)  if access is rejected.

If bit 1 (value 2) of the   MTA option is set  and the    flag is set so that the connection is rejected, then also specifying  the   flag will cause a "T" entry to be written to the  MTA connection log. Note that running processes do not notice the periodic  "roll-over" of the   file into  the   file, and the creation of a new   file; such changes are normally noticed merely because new processes come into existence and see the "new" file. But in the case of the Dispatcher, which is normally a very long running process (normally not restarted except at times of certain configuration changes), this means that the Dispatcher, which is writing the " " records, will continue writing to the "old" log file. For instance, after a  file has been renamed to , the Dispatcher will keep writing its " " records to the file it "knew" about, now named  ; it will not know to start writing to   unless and until the Dispatcher is restarted. (As of MS 6.2, the Dispatcher periodically (namely once an hour) forces a close and re-open of the connection log file.) So, if you are using " " records, you may wish to restart your Dispatcher daily (at the time of log file rollover)---especially if you  are running a version prior to MS 6.2.

The  mapping table, in addition to its normal use by the Dispatcher, is also optionally probed again by the  SMTP server and LMTP server  for the purpose of determining the appropriate SASL rule set (when SMTP AUTH has been used during message submission); as of 7.0, the SMTP server probe of the   mapping table is unconditional (always performed). (However, the LMTP server probe of  is still conditional.) Or enabling bit 4 of the   MTA option also causes the SMTP server and LMTP server to probe the   mapping table; in this case site-supplied  text may be provided in the   entry to include in the SMTP server&#x27;s and LMTP server&#x27;s   field---a field which is used in certain types of log entries (such as "C" connection log entries entries). To specify such text, include two vertical bar characters in the right hand side of the entry, followed by the desired text. New in MS 6.3-0.15, such SMTP server probes of  will respect the    (in the case of SMTP AUTH usage), , and   flags, whereas in prior versions the SMTP server probe results were only relevant for setting the SASL ruleset and the optional logging text; as of the fix for 12208860 (Sun 6590888) (MS 6.3-5.02),   rejections will be respected in all cases. Thus new in MS 6.3-0.15 for the special case of SMTP AUTH use, and true in general subsequently, the SMTP server probes of   can be used to achieve connection rejections (in this case performed by the SMTP server processes, rather than by the main Dispatcher process); for "simple" rejections it is more efficient to perform such rejections from the main Dispatcher process, but for potentially complex or "slow" rejections (such as rejections determined by the results of DNS verification lookups), deferring the rejection until the individual SMTP server process stage can avoid "bottlenecking" the main Dispatcher process waiting for a result of a probe. (LMTP server probes of  remain, as previously, relevant only for setting the SASL ruleset and the optional logging text.)

 1To use multiple flags with arguments, or the non-flagged fields, separate the arguments with the vertical bar character,, placing the arguments in the order listed in this table.

Note that prior to MS 6.3-0.15, Dispatcher probes of the   mapping table could not make use of  LDAP callouts ([[Mapping entry templates#Mapping_LDAP_query_URL_substitutions|LDAP callouts ($&#x5d;...&#x5b; callouts)]]#x5d;...&#x5b; callouts).

The following example  mapping will only accept SMTP connections (to port 25, the normal SMTP port) from a single network, except for a particular host singled out for rejection without explanatory text: PORT_ACCESS TCP&#x7c;&#x2a;&#x7c;25&#x7c;192.123.10.70&#x7c;&#x2a;    $N500 TCP&#x7c;&#x2a;&#x7c;25&#x7c;192.123.10.&#x2a;&#x7c;&#x2a;     $Y TCP&#x7c;&#x2a;&#x7c;25&#x7c;&#x2a;&#x7c;&#x2a;                $N500$ Bzzzzzzzzt$ thank$ you$ for$ playing. Note that you will need to restart the Dispatche - or as of MS 6.3-0.15 use the   utility to reload the changed mappings file into running processes such as the Dispatcher - after making any changes to the   mapping table so that the Dispatcher will see the changes. (Note that this requires a compiled MTA configuration and you&#x27;ll first need to recompile before reloading.)

The  mapping table is specifically intended for performing IP number based rejections; for more general control at the email address level, the  e-mail address access mappings such as   or   may be more appropriate.

See also:
 * When access mapping table controls are applied
 * dns_verify_domain Option
 * Dispatcher
 * SMTP SUBMIT servers
 * LMTP back end TCPIP channel
 * MTA transaction logging
 * TCPIP channels
 * Access mapping tables
 * slave_debug Option
 * mm_debug MTA Option
 * os_debug MTA Option
 * TRACE_LEVEL
 * DISABLE_ADDRESS
 * DISABLE_CIRCUIT
 * DISABLE_GENERAL
 * DISABLE_STATUS
 * log_connection MTA Option
 * BANNER_PURGE_DELAY
 * AUTH_DEBUG
 * sndopr_prefix MTA Option
 * sndopr_priority MTA Option
 * INTERNAL_IP mapping table
 * reload utility
 * Spamfilter early verdicts
 * Initial PORT_ACCESS mapping table