Recipient access mapping tables

The,  ,  , and    mapping tables may be used to control who may or may not send mail, receive mail, or both. The access checks have available a message&#x27;s envelope from address and envelope to addresses, and knowledge of what channel the message came in, and what channel it would attempt to go out; in additional, the  and   mapping tables also have access to all the information available to the    mapping table. Note that when the envelope To addresses are irrelevant and only the envelope From address matters, then use of the  mapping table, described in   mapping table, may be more convenient and efficient.

  If an  or   mapping table exists, then by  default for each recipient of every message passing through the MTA, the MTA  will probe the   and/or   mapping tables with a probe string of the form (note the use of the vertical bar character,  ) src-channel&#x7c;from-address&#x7c;dst-channel&#x7c;to-address where   is the channel originating the message (i.e., enqueueing/submitting the message);   is the address of the message&#x27;s originator;   is the channel to which the message will be enqueued/submitted; and   is the address to which the message is addressed. Use of an asterisk in any of these fields causes that field to match any channel or address, as appropriate; see Mapping table format for additional matching characters and sequences.

Note that the addresses here are envelope addresses, that is, envelope From address and envelope To address. The   used is by default the so-called mapped return address: the envelope From address after simple  address reversal has been applied to it (but not including, for  instance, destination-specific address reversal). However, the MTA options ,  and (new in MS 6.3)   ,  and (new in MS 7.0)   ,  can be used to probe with a different form  of the envelope From address. In the case of, the envelope To address is checked after rewriting, alias expansion, etc., have been performed; in the case of   the originally specified envelope to address is checked after rewriting, but before alias expansion.

The MTA options ,   ,   , and     (which in 8.0.2.2 replaced the previous   MTA option) can cause inclusion  of additional fields  in the probes. If the relevant bits of all these options are set (the options take bit-encoded integer arguments with distinct bits  controlling the inclusion of the fields in the distinct mapping  tables), then the format of probes with all optional fields enabled  becomes src-channel&#x7c;from-address&#x7c;dst-channel&#x7c;to-address&#x7c;orcpt&#x7c;access-counts&#x7c;list-of-tags&#x7c;s1&#x7c;s2&#x7c;s3&#x7c;s4&#x7c;s5&#x7c;s6 The optional   field is the SMTP ORCPT field; that is, it will contain the address type (typically " ") followed by a semicolon, followed by the "original" to address, e.g., " ". The optional   field contains a count of which  recipient address (RCPT TO) this probe is for, followed by a forward  slash, following by a count of the number of valid recipient addresses  resulting from previous recipient address submissions (addresses  resulting from previous RCPT TO commands), followed by a forward slash,  potentially followed by additional counts expected to be added in  future versions; so note that good practice is to always use an  asterisk here, so that future additions will not cause old entries to  stop working. The optional   field contains a comma-separated list of  conversion tags already present on  this message. (Note that conversion tags apply to entire message copies, different recipient conversion tags causing message copy  "split up". But these recipient address probes occur before  final recipient determination and hence before application of recipient  conversion tags occurs.) The optional   fields  contain the values of the LDAP attributes named by the    MTA  options.

  The  mapping table is a superset of the    and    mapping tables; that is, it combines both the channel and address information of , with the IP address and port number information of. (See  mapping table for discussion of the   mapping table.) Similarly, the   mapping table is a superset of the   and   mapping tables. The format for the default probe string for  is  port_access-probe-info&#x7c;app-info&#x7c;submit-type&#x7c;send_access-probe-info and similarly the format for the default probe string for   is  port_access-probe-info&#x7c;app-info&#x7c;submit-type&#x7c;orig_send_access-probe-info Here   consists of all the information usually included in a  mapping table probe (see   mapping table) in the case of incoming SMTP messages (including originally-incoming-SMTP messages that have been deferred to the   channel),  or will be blank otherwise, and   will usually be    in the case of  messages submitted via SMTP or       in the case of messages submitted via SMTP over TLS (including the case of originally-incoming-SMTP messages that have been deferred to the reprocess channel), and blank otherwise.   may be one of ,  ,  , or  , corresponding to how the message was submitted into the MTA. Normally the value is, meaning it was submitted as a message;  ,  , or    can occur in the case of broadcast requests (or combined broadcast/message requests) submitted to the SMTP server. And for the  mapping table,   consists of all the information usually included in a   mapping table probe (including, if the MTA options ,  ,  , and/or   are enabled, their respective additional fields). Similarly for the  mapping,   consists of all the information usually included in an   mapping table probe (including, if the MTA options ,  ,  , and/or   are enabled, their respective additional fields). (See above for additional discussion of  and   probes, as well as the ,  ,  ,   MTA options.)

New in MS 7.0, the MTA option   can cause vertical bars  present within a field to be replaced by a different character, thereby  ensuring that the only vertical bar characters in a probe are the field  delimiter occurrences.

Now, if the probe string matches a pattern (i.e., the left hand side of an entry in the table), then the resulting output of the mapping is checked. If the output contains the flags $Y or $y, then the enqueue for that particular recipient (envelope To) address is permitted.

If the mapping output contains any of the flags $N, $n, $F, or $f, then the enqueue to that particular address is rejected. In the case of a rejection, optional rejection text may be supplied in the mapping output. This string will be included in the rejection error the MTA issues.+ (Unless an at-sign character, , is part of the explicit rejection text, the MTA will append a colon and the recipient address to the end of the explicitly specified rejection text.) The specific enhanced status code, which in turn determines whether the error is temporary or permanent, can be specified through the use of $X; see the access mapping flags table below for details.

If no string is output (other than the $N, $n, $F, or $f flag), then some default rejection text will be used. As of 6.2, the exact default text depends upon the value of the  option; by default, if that option is 0, then the full SMTP error, including text, is: 550 5.7.1 unknown host or domain: recipient-address This default rejection text is rather intentionally misleading for reasons of security, as under some circumstances it may be desirable to avoid revealing the real reason for a rejection. When no such security concerns apply, it is often more user-friendly to take the option of specifing some explanatory rejection text, either your own choice of text, or set. If  is 1, then the full SMTP error, including text, is: but if that option is 1, then the text is: 550 5.7.1 you are not allowed to use this address Technical note:When the MTA generates a probe, it may also set various input flags  specific to certain probe conditions: e.g., the    input flag is set if SMTP AUTH has been used. Though these input flags are not part of the string part of the probe, they may be detected  (tested) in a mapping entry via flag comparison tests in the entry  template (right hand side). See the "Input flag comparisons" section of Address access mapping table flags  for a full list. Input flags are separate from output flags: even in an iterative mapping, a flag set as output  on one line will not become an input flag for possible subsequent  probes, as it is the original input flags which are the input flags for  all the probes. Sophisticated uses of the   mapping tables may  make use of such input flag tests to more precisely specify under which  circumstances to apply mapping effects.

See Address access mapping table flags for descriptions of additional flags. Note that input flags (set by the MTA prior to probing) are the only flags that may be tested using the input flag comparisons. Output flags, those set in the template (right hand side) of a mapping entry, are separate and not subject to such testing.

 1These flags are relevant for the,  ,  ,  , and   mapping table, except where footnotes indicate special restrictions. Note that the  mapping table supports a somewhat different set of flags.

 2To use multiple flags with arguments, separate the arguments with the vertical bar character,, placing the arguments in the order listed in this table.

 3Available for the   mapping table only.

 4It is a good idea to use the   flag when dealing with problem senders, to prevent a denial of service attack. In particular, it is a good idea to use  in any   entry or    entry rejecting access.

 5Not available for the   mapping table.

 6This output flag has a different meaning and/or occurs in a different position, relative to other output flags, for     vs. the other address   mapping tables. See the rest of this table for the other occurrence of this flag, describing its operation for the other type of mapping table.

 7Only one  and corresponding value can be used in a single mapping result.

 + Note that it is up to whatever is attempting to send the message whether the MTA rejection error text is actually presented to the user who attempted to send the message. In particular, in the case when  is used to reject an incoming SMTP message, the MTA merely issues an SMTP rejection code including the optional rejection text; it is up to the sending SMTP client to use that information to construct a bounce message to send back to the original sender.

An example of an important use of the   mapping table is discussed in Blocking SMTP relaying.

See also:
 * When access mapping table controls are applied
 * When mapping table changes take effect
 * Access mapping tables
 * Access mapping table MTA options
 * Initial SEND_ACCESS mapping table
 * PORT_ACCESS mapping table
 * FROM_ACCESS mapping table
 * access_counts MTA Option
 * access_orcpt MTA Option
 * include_conversiontag MTA Option
 * include_spares1 MTA Option
 * Conversion tags
 * Diagnosing .HELD files
 * mapping_paranoia MTA Option
 * Sieve filters
 * Sieve spamtest and virustest extensions
 * Bitbucket channel
 * Sieve environment extension
 * Sieve vacation extension
 * sndopr_prefix MTA Option
 * sndopr_priority MTA Option
 * block_limit MTA Option
 * blocklimit Option
 * recipientlimit Option
 * ldap_recipientlimit MTA Option
 * recipientcutoff Option
 * ldap_recipientcutoff MTA Option
 * Blocking SMTP relaying