The FROM_ACCESS mapping table can 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 PMDF will probe the table with a probe string of the form (note the use of the vertical bar character, |)
port_access-probe-infoconsists of all the information usually included in a PORT_ACCESS mapping table probe in the case of incoming SMTP messages, or will be blank otherwise, and
app-infowill usually be SMTP in the case of messages submitted via SMTP, and blank otherwise. Note that if you are using TLS, that
app-infocontains the TLS information, for example
SMTP/TLS-168-DES-CBC3-SHA, so we recommend you use SMTP*.
submit-typecan be one of MAIL, SEND, SAML, or SOML, corresponding to how the message was submitted into PMDF. 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-channelis the channel originating the message (i.e., queueing the message);
from-addressis the address of the message's purported originator; and
auth-fromis the authenticated originator address, if such information is available, or blank if no authenticated information is available.
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 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 can be supplied in the mapping output. This string will be included in the rejection error PMDF issues.2 If no string is output (other than the $N, $n, $F, or $f flag), then default rejection text will be used. See Table 16-1 for descriptions of additional 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
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_local|*| $Y *|SMTP*|*|tcp_local|*|* $Y$J$4
authrewriteset 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 instance, with
authrewrite 2set on the tcp_local channel, the following FROM_ACCESS mapping table would not be necessary:
FROM_ACCESS *|SMTP*|*|tcp_local|*| $Y *|SMTP*|*|tcp_local|*|* $Y$K$4
authrewritealone is sufficient to get this effect (adding the authenticated address verbatim). However, the real purpose of FROM_ACCESS is to permit more complex and subtle alterations. For instance, perhaps you want to force on a Sender: header only in cases where the authenticated address differs from the envelope From: address, with subaddresses not being considered to constitute a difference, as illustrated in the following table:
FROM_ACCESS ! If no authenticated address is available, do nothing *|SMTP*|*|tcp_local|*| $Y ! If authenticated address matches envelope From:, do nothing *|SMTP*|*|tcp_local|*|$3* $Y ! If authenticated address matches envelope From: sans subaddress, do nothing *|SMTP*|*|tcp_local|*+*@*|$3*@$5* $Y ! Fall though to... ! ...authenticated address present, but didn't match, so force Sender: header *|SMTP*|*|tcp_local|*|* $Y$ASender:$ $4
2 Note that it is up to whatever is attempting to send the message whether the PMDF 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, PMDF 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.