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, Messaging Server will search the table with a string of the form (note the use of the vertical bar character, |):
port-access-probe-info|app-info|submit-type|src-channel|from-address|auth-from |
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; otherwise, it is blank. app-info includes the system name claimed in the HELO/EHLO SMTP command. This name appears at the end of the string and is separated from the rest of the string (normally “SMTP”) by a slash. The claimed system name can be useful in blocking some worms and viruses. 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 (that is, queueing the message); from-address is the address of the message's purported originator; and auth-from is the authenticated originator address, if such information is available, or blank if no authenticated information is available.
If the probe string matches a pattern (that is, the left-hand side of an entry in the table), the resulting output of the mapping is checked. If the output contains the flags $Y or $y, then the enqueue for that particular To: address is permitted. If the 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 Messaging Server issues. If no string is output (other than the $N, $n, $F, or $f flag), then default rejection text will be used. For descriptions of additional flags, see Access Control Mapping Table Flags.
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 modify the effect of the authrewrite channel keyword (adding a Sender: header address on an accepted message) via the $K flag. For instance, this mapping table can be used to cause the original envelope From: address to simply be replaced by the authenticated address.
FROM_ACCESS *|SMTP|*|tcp_auth|*| $Y *|SMTP|*|tcp_auth|*|* $Y$J$3 |
When using the FROM_ACCESS mapping table to modify the effect on having authrewrite set to a nonzero value on some source channel, it is not necessary to use FROM_ACCESS if the authenticated address is going to be used verbatim.
For example, with authrewrite 2 set on the tcp_local channel, the following FROM_ACCESS mapping table would not be necessary because authrewrite alone is sufficient to get this effect (adding the authenticated address verbatim):
FROM_ACCESS *|SMTP|*|tcp_auth|*| $Y *|SMTP|*|tcp_auth|*|* $Y$K$3 |
However, the real purpose of FROM_ACCESS is to permit more complex and subtle alterations, as shown in the example below. The authrewrite keyword alone is appropriate if you want to add a Sender: header line (showing the SMTP AUTH authenticated submitter address) to incoming messages. However, suppose you want to force the addition of such a Sender: header line to incoming messages only if the SMTP AUTH authenticated submitter address differs from the envelope From: address (that is, not bother to add a Sender: header line if the addresses match), and suppose further that you wish the SMTP AUTH and envelope From: addresses will not be considered to differ merely because the envelope From: includes optional subaddress information.
FROM_ACCESS ! If no authenticated address is available, do nothing *|SMTP|*|tcp_auth|*| $Y ! If authenticated address matches envelope From:, do nothing *|SMTP|*|tcp_auth|*|$2* $Y ! If authenticated address matches envelope From: sans ! subaddress, do nothing *|SMTP|*|tcp_auth|*+*@*|$2*@$4* $Y ! Fall though to... ! ...authenticated address present, but didn't match, so force ! Sender: header *|SMTP|*|tcp_auth|*|* $Y$K$3 |