| Previous | Next | Contents | Index |
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-info|app-info|submit-type|src-channel|from-address|auth-from |
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, or will be blank otherwise, and
app-info will usually be SMTP in the case of
messages submitted via SMTP, and blank otherwise. Note that if you are
using TLS, that app-info contains the TLS
information, for example SMTP/TLS-168-DES-CBC3-SHA, so we
recommend you use SMTP*. submit-type can 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-channel is the channel
originating the message (i.e., 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 (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
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_local|*| $Y *|SMTP*|*|tcp_local|*|* $Y$J$4 |
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 instance, with authrewrite
2 set 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 |
authrewrite alone 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. |
| Previous | Next | Contents | Index |