When access mapping table controls are applied

The MTA checks access control mapping tables as early as possible. Exactly when this happens depends upon the e-mail protocol in use---when the information that must be checked becomes available.

For incoming SMTP messages, the Dispatcher consults the   mapping table  to decide whether  or not to accept the SMTP connection -- before even accepting a connection. In the case of an accepted SMTP connection handed over to an SMTP server process thread, then (as of Messaging Server 7.0) each SMTP server process thread makes its own additional probe of    after the hand off  of a connection from the Dispatcher, prior to issuing the server&#x27;s SMTP  banner line. (If the "client" is the MMP and it sends an XPEHLO command, that resets the effective source IP address and so the  SMTP server process thread will then do yet another    probe.) There are trade-offs in performance between the Dispatcher check and the server process check of  ; see the    mapping table discussion for additional details.

Continuing with the (incoming) SMTP protocol, where addresses are presented in the initial part of the attempted message handover, well before the message data itself would be handed over, note that a   rejection will occur in response to the MAIL FROM: command, before the sending side ever gets to send the recipient information let alone the message data, while a  recipient access mapping table (,  ,  , or  ) sort of rejection will occur in response to the RCPT TO: command, before the sending side ever gets to send the message data. Thus if an SMTP message is rejected due to such a  mapping table rejection,  the MTA never even accepts or sees the message data, thereby minimizing the overhead of performing such rejections.

In contrast, note that an   mapping table  which (as of MS 6.2) may  reject messages, or a  Sieve script " "  message rejection, since they in principle may make use of information  from the message as a whole (message header lines and body content),  cannot be applied until after the message data has been received by the  MTA. In particular, in the case of an SMTP message, these forms of rejection cannot occur until after the end of the DATA phase of  processing, thus they involve more overhead (both network traffic, and  MTA processing overhead) than rejections performed via a     mapping table.

So the order in which access mapping tables are checked for incoming messages is:



 (by Dispatcher), 

 (by SMTP server as of Messaging Server 7.0), 

 (by SMTP server after successful STARTTLS negotiation), or               (by SMTP server when an ETRN command is received), 

 (after SMTP AUTH), 

 (after SMTP MAIL FROM), 

 ,        ,  , and              (after SMTP RCPT TO, after the MTA&#x27;s address rewriting and alias    processing has been applied, all four are checked in the order listed), 

 (by SMTP SUBMIT server when a BURL command is received instead of regular        message DATA), 

 (after SMTP DATA). </li>

</ul>

In the list above, failing a check at one stage normally aborts message acceptance and processing and hence no further checks need be  performed. But as regards the recipient address based mapping tables ,  ,   , and  , note  that they are all checked at the same stage of processing (which is  after address rewriting and alias processing); if multiple of these  recipient address access control mapping tables exist, then the MTA  will check them all (and any side-effects they cause will take place)  in the order just listed (which is a point to keep in mind when using such mapping tables to obtain side-effects such as addition of header lines, logging to  , etc.).

The MTA is designed to do most processing upon message enqueue. So outgoing SMTP messages receive relatively little processing. However, there are a few possible access checks for outgoing SMTP messages. See the,  , and   mapping tables.

See also:
 * Dispatcher operation
 * FROM_ACCESS mapping table
 * PORT_ACCESS mapping table
 * Recipient access mapping tables
 * Recipient access mapping tables
 * Recipient access mapping tables
 * Recipient access mapping tables
 * Recipient access mapping tables
 * AUTH_REWRITE mapping table
 * Sieve ereject and reject and refuse extensions