FROM ACCESS mapping table

The  mapping table may be used to control who can send mail,  or to override purported From: addresses with authenticated addresses,  or both.

The input probe string to the  mapping table is  similar to  that for a    mapping table,  minus the destination channel and  address, and with the addition of authenticated sender information, if  available. Thus if a  mapping table exists, then for each  attempted message submission the MTA will probe the table with a probe  string of the form (note the use of the vertical bar character, &#x7c;) port_access-probe-info&#x7c;app-info&#x7c;submit-type&#x7c;src-channel&#x7c;from-address&#x7c;auth-from Here   consists of all the information usually included in a  PORT_ACCESS mapping table probe 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    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.   is the channel originating the message (i.e., queueing the message);    is the address of the message&#x27;s  purported originator (that is, the envelope From address);  note that as of Messaging Server 7.0u2, the MTA options   , and (new in 6.3)   ,  and (new in Messaging Server 7.0)    , can be  used to probe with a different form of the envelope From address.   is the authenticated originator address, if such information is available (e.g., from an SMTP  AUTH command, in which case it is the user&#x27;s    attribute value which is returned from the SASL library code and  substituted in this field of the probe), or blank if no authenticated  information is available.

The   and     (renamed from    as of MS 8.0.2.2) and   MTA options can  cause inclusion of additional fields in the    probes. If the relevant bits of these options are set, then the format of the probes with all optional fields enabled becomes port_access-probe&#x7c;app-info&#x7c;submit-type&#x7c;src-chan&#x7c;from-addr&#x7c;auth-from&#x7c;source-auth&#x7c;username&#x7c;list-of-tags&#x7c;s1&#x7c;s2&#x7c;s3&#x7c;s4&#x7c;s5&#x7c;s6 The   field contains the value of the SMTP MAIL FROM command&#x27;s AUTH parameter; the   field contains the canonical username result produced by authentication. 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.

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  or  , then the  enqueue from that particular From: address is permitted. If the mapping output contains any of the flags ,  ,   , or  , then the enqueue  from 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.1  If no string is output (other than the ,  ,   , or   flag), then  default rejection text will be used, 550 5.7.1 Initial access check failure See Address access mapping table flags for descriptions of additional flags.

As of MS 6.2p4, the initial configuration of the MTA generates a minimal    mapping table that disables generation of vacation messages back to typical list "owner" addresses.

This configuration can easily be extended to block submission entirely based on various criteria. For example, suppose that in addition to not being allowed to receive mail, is is also desirable to prevent over quota users from sending mail. The following settings would expose the  attribute in the sixth spare slot: msconfig&#x3e; set ldap_spare_6 mailUserStatus msconfig# set include_spares1 32 And the following addition at the end of the  mapping would check the attributes value: FROM_ACCESS TCP&#x7c;&#x2a;&#x7c;SMTP&#x2a;&#x7c;MAIL&#x7c;tcp_&#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;overquota $X4.2.3&#x7c;$NOver$ quota$ users$ cannot$ send$ mail Besides determining whether to allow a message to be submitted based on the originator,   can also be used to alter the envelope From  address via the   flag, or to set a different  "sender" address via the   flag. Although the envelope From and sender address are not always seen in message  headers, they can be quite significant for various functional  operations (such as access checks). And depending upon other configuration, they may potentially end up visible in header lines  (envelope From in the Return-path: header line added during final  delivery, and sender address in a Sender: header line if added due to  use of the   channel option). For instance, this mapping table can be used to cause the original envelope From address to simply  be replaced by the authenticated address, when an authenticated address  is present: FROM_ACCESS &#x2a;&#x7c;SMTP&#x2a;&#x7c;&#x2a;&#x7c;tcp_local&#x7c;&#x2a;&#x7c;    $Y &#x2a;&#x7c;SMTP&#x2a;&#x7c;&#x2a;&#x7c;tcp_local&#x7c;&#x2a;&#x7c;&#x2a;   $Y$J$4  1Note 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 at the MAIL FROM: stage of the SMTP dialogue, 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.

See also:
 * Recipient access mapping tables
 * PORT_ACCESS mapping table
 * When access mapping table controls are applied
 * Access mapping table MTA options
 * mapping_paranoia MTA Option
 * Access mapping tables
 * Recipient access mapping tables
 * include_conversiontag MTA Option
 * include_spares1 MTA Option
 * access_auth MTA Option
 * Conversion tags
 * Testing address access mapping tables
 * Initial FROM_ACCESS mapping table