FROM_ACCESS mapping table

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

The FROM_ACCESS 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 FROM_ACCESS mapping table is similar to that for a MAIL_ACCESS mapping table, minus the destination channel and address, and with the addition of authenticated sender information, if available. Thus if a FROM_ACCESS 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, |)


Here port_access-probe-info 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 reprocess channel), or will be blank otherwise, and app-info will usually be SMTP/claimed-HELO-name in the case of messages submitted via SMTP, or SMTP/TLS-crypto-info/claimed-HELO-name 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. submit-type may be one of MAIL, SEND, SAML, or SOML, corresponding to how the message was submitted into the MTA. Normally the value is MAIL, meaning it was submitted as a message; SEND, SAML, or SOML can occur in the case of broadcast requests (or combined broadcast/message requests) submitted to the SMTP server. src-channel is the channel originating the message (i.e., queueing the message); from-address is the address of the message's purported originator (that is, the envelope From address); note that as of Messaging Server 7.0u2, the MTA options use_orig_return , and (new in 6.3) use_canonical_return, and (new in Messaging Server 7.0) use_auth_return , can be used to probe with a different form of the envelope From address. auth-from is the authenticated originator address, if such information is available (e.g., from an SMTP AUTH command, in which case it is the user's mail 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 include_conversiontag and include_spares1 (renamed from include_spares as of MS and access_auth MTA options can cause inclusion of additional fields in the FROM_ACCESS probes. If the relevant bits of these options are set, then the format of the probes with all optional fields enabled becomes


The source-auth field contains the value of the SMTP MAIL FROM command's AUTH parameter; the username field contains the canonical username result produced by authentication. The optional list-of-tags 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 s* fields contain the values of the LDAP attributes named by the ldap_spare_* 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 $Y or $y, then the enqueue from that particular From: address is permitted. If the mapping output contains any of the flags $N, $n, $F, or $f, then the enqueue from that particular address is rejected. As of MS, the lower case variants result in a rejection that cannot be selectively ignored by enqueue processors. 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 $N, $n, $F, or $f 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 FROM_ACCESS 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 mailUserStatus attribute in the sixth spare slot:

    msconfig> set ldap_spare_6 mailUserStatus
    msconfig# set include_spares1 32

And the following addition at the end of the FROM_ACCESS mapping would check the attributes value:


  TCP|*|SMTP*|MAIL|tcp_*|*|*|overquota $X4.2.3|$NOver$ quota$ users$ cannot$ send$ mail

Besides determining whether to allow a message to be submitted based on the originator, FROM_ACCESS can also be used to alter the envelope From address via the $J flag, or to set a different "sender" address via the $K 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 authrewrite 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:

  *|SMTP*|*|tcp_local|*|     $Y 
  *|SMTP*|*|tcp_local|*|*    $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 FROM_ACCESS 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: