AUTH REWRITE mapping table

Certain values of the  channel option cause the   mapping table to be consulted to allow for more complex decision making and alterations of addresses. And bits of  also affect the form of probe to the    mapping table.

Probes for the  mapping table normally have the following  format: env-from&#x7c;&#x5b;resent-&#x5d;sender&#x7c;&#x5b;resent-&#x5d;from&#x7c;auth-originator If (new in MS 6.2) bit 5 (value 32) is set in the the   argument, the probe is prefixed with the source channel and a vertical bar; if (new in MS 7.3-11.01) bit 8 (value 256) is set in the    argument, the probe is suffixed with a vertical bar and the AUTH parameter from the MAIL FROM command; if (new in MS 7.0.5) bit 9    (value 512) is set in the   argument, the probe is prefixed with the final tag set by the   mappings and a vertical bar. Thus with these three optional bits set, the probe has the format: ACCESS-tag&#x7c;src-chan&#x7c;env-from&#x7c;&#x5b;resent-&#x5d;sender&#x7c;&#x5b;resent-&#x5d;from&#x7c;auth-originator&#x7c;auth-param New in MS 8.0.2.3, the  MTA option may be used to specify additional header fields to include in the mapping probe. These fields always appear at the end of the probe, separated by vertical bars.

With, the probes preferentially use any Resent-Sender: or Resent-From: header line values present, whereas with   the probes always use Sender: and From:. (Note that normally the  mapping table is only consulted when a submission has included SMTP AUTH info; that is, in order for the   mapping table  to be consulted not only must the relevant incoming channel be marked with an   value of 3 or 4, but also the submission included use of the SMTP AUTH command.  However, if bit 4 (value 16) is set in the   channel option&#x27;s argument, then   will be consulted even for non-authenticated submissions.)

New in 7.2-7.02, bit 6 (value 64) of  will, if set, cause a rewritten version of the envelope from address to be used for the   address in the probe  as opposed to the original form given in the SMTP MAIL FROM command. The specific rewritten form used is controlled by bit 7 (value 128): if set, the canonical form return address will be used, if clear the normally rewritten form will be used instead. These rewritten forms are useful when access checking is done using the   mapping in order to prevent envelope From forgery by authenticated users.

If the mapping table output contains a,  ,   , or  , then the envelope From address is replaced with the specified string. If the mapping table output contains a,  ,   , or  , then a Sender: header line is added (if   was specified and if a Resent-Sender: or Resent-From: was already present, then a Resent-Sender: header line is added instead of a Sender: header line) containing the specified string.

If the mapping table output contains a  or ,  then a From: header line is added (a Resent-From: in the case of   and a Resent-From: or Resent-Sender: header line already being present) containing the specified string. (Such replacing of the From: header address is NOT RECOMMENDED and CONTRARY TO INTERNET STANDARDS and quite likely to HARM the overall security of your users. It should almost NEVER be done: THIS MEANS YOU! Despite the wishes and mistaken notions of many sites and users, the From: header line, in Internet e-mail, is NOT INTENDED to represent the "real" originator of a message; it is intentionally defined permitting alternate usages.)

New in MS 7.0, if a  is specified, then its argument is interpreted  as a header line to add to the primary message header.

New in 7.3-11.01, if a  is specified,  then another vertical-bar-separated string will be read from the mapping result string and used to set or override the value of the SMTP AUTH parameter for the current transaction. The  channel option may  then be applied to the destination channel to cause this value to be propagated as an AUTH parameter on the SMTP MAIL FROM command.

New in MS 6.2, if a  is specified, then the message will be rejected. Optional rejection text may be specified after another vertical bar character,. And as of MS 6.3,   may also be used to specify the extended error code (specified before the   text, separated by a  ) in the form  . In the absence of such optional text and optional extended error code, the default text " " and default extended error code  will be used. (Note that use of the   channel option postpones the rejection.)

When using multiple such flags, separate the string arguments with the vertical bar character,, and specify the string arguments in the order listed in the paragraphs above; for instance, $J$Y$Z$A$Oenv-from&#x7c;sender&#x7c;from-hdr&#x7c;hdr-line-to-add&#x7c;auth-param or $X$N&#x7c;error-code&#x7c;rejection-text Technically, one could use all seven flags in the same entry, though it does not seem likely to be useful (as in particular the changes to the message, such as changes of address or addition of a header line) do  not apply since the rejection is going to occur at the SMTP protocol  level):  $J$Y$Z$A$O$X$Nenv-from&#x7c;sender&#x7c;from-hdr&#x7c;hdr-line-to-add&#x7c;auth-param&#x7c;error-code&#x7c;rejection-text As of the 8.0 release, the following input flags will be set:



 if SASL authentication has succeeded 

 if EHLO (EMSMTP) was used 

 if LHLO (LMTP) was used 

 if POP-before-SMTP was used 

 if this is an internal channel enqueue operation, i.e., from a conversion, process, reprocess,  or similar sort of channel 

 if a SSL/TLS security layer has been negotiated 



mapping flagssummarizes the available (output) flags and input flags.

 1To use multiple flags with arguments, separate the arguments with the  vertical bar character, , placing the arguments in the  order listed in this table.

An example of an AUtH_REWRITE mapping that prevents authenticated users from sending messages from addresses other than the ones listed in their mail, mailAltnerateAddress, or mailEquivalentAddress mappings would be: AUTH_REWRITE ! Probe format: env-from&#x7c;&#x5b;resent-&#x5d;sender&#x7c;&#x5b;resent-&#x5d;from&#x7c;auth-originator ! Check to see if the From: matches the authenticated user&#x27;s mail attribute; ! exit with success if it does &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;$2&#x2a;  $E ! Fetch the base DN we&#x27;ll need to look up the user &#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a;  $CBASE&#x7c;$}$4,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Probe now: BASE&#x7c;base-DN&#x7c;from&#x7c;auth-originator ! Check to see if the From: matches the authenticated user&#x27;s ! mailAlternateAddress or mailEquivalentAddress attributes. BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $CFOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(&#x7c;(mailAlternateAddress=$=$1$_)(mailEquivalentAddress=$=$1$_)))&#x5b;&#x7c;$1&#x7c;$2 ! Exit with success if it does FOUND&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $E ! Fail any other From: address &#x2a;          $NFrom$ address$ is$ not$ one$ of$ your$ addresses. Note that the  source channel option needs to be set to 3 for the AUTH_REWRITE mapping to be invoked.

A more sophisticated version of this mapping that allows users to specify arbitrary subaddresses would be: REMOVE_SUBADDRESS "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$0@$2 "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y"$0"@$2 $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$0@$2 &#x2a;                                    $Y$0 REMOVE_SUB_LDAP_QUOTE "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$=$0@$2$_ "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y$="$0"@$2$_ $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$=$0@$2$_ &#x2a;                                    $Y$=$0$_ MATCH_NOSUBADDRESS &#x2a;&#x7c;&#x2a;  $C$&#x7c;REMOVE_SUBADDRESS;$0&#x7c;&#x7c;$&#x7c;REMOVE_SUBADDRESS;$1&#x7c; &#x2a;&#x7c;$0&#x2a; $Y AUTH_REWRITE ! Check to see if the From: matches the authenticated user&#x27;s mail attribute; ! exit with success if it does &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $C$&#x7c;MATCH_NOSUBADDRESS;$2$&#x7c;$3&#x7c;$E ! Fetch the base DN we&#x27;ll need to look up the user &#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CBASE&#x7c;$}$4,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check to see if the From: matches the authenticated user&#x27;s ! mailAlternateAddress or mailEquivalentAddress attributes. BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CFOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(&#x7c;(mailAlternateAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(mailEquivalentAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)))&#x5b;&#x7c;$1&#x7c;$2 ! Exit with success if it does FOUND&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $E ! Fail any other From: address &#x2a; $NFrom$ address$ is$ not$ one$ of$ your$ addresses. An even more sophisticated approach that provides "send on behalf of" functionality is possible. Assuming a sendOnBehalfOf attribute has been added to the user&#x27;s entry listing the addresses the user is authorized to send on behalf of, the following mapping could be used: REMOVE_SUBADDRESS "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$0@$2 "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y"$0"@$2 $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$0@$2 &#x2a;                                    $Y$0 REMOVE_SUB_LDAP_QUOTE "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$=$0@$2$_ "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y$="$0"@$2$_ $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$=$0@$2$_ &#x2a;                                    $Y$=$0$_ MATCH_NOSUBADDRESS &#x2a;&#x7c;&#x2a;  $C$&#x7c;REMOVE_SUBADDRESS;$0&#x7c;&#x7c;$&#x7c;REMOVE_SUBADDRESS;$1&#x7c; &#x2a;&#x7c;$0&#x2a; $Y AUTH_REWRITE ! Check to see if the From: matches the authenticated user&#x27;s mail attribute; ! exit with success if it does &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $C$&#x7c;MATCH_NOSUBADDRESS;$2$&#x7c;$3&#x7c;$E ! Fetch the base DN we&#x27;ll need to look up the user &#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CBASE&#x7c;$}$4,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check to see if the From: matches the authenticated user&#x27;s ! mailAlternateAddress or mailEquivalentAddress attributes. BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CFOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(&#x7c;(mailAlternateAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(mailEquivalentAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(sendOnBehalfOf=$1)))&#x5b;&#x7c;$1&#x7c;$2 ! Exit with success if it does FOUND&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $E ! Fail any other From: address &#x2a; $NYou$ are$ not$ authorized$ to$ send$ from$ the$ address$ you$ specified If the "send on behalf of" permissions are instead stored on the "other side" - in, say, an, mailGrantSendPermissionsTo on the granting user&#x27;s entry that specifies the mail attribute of the user permissions are being granted to, the following mapping could be used: REMOVE_SUBADDRESS "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$0@$2 "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y"$0"@$2 $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$0@$2 &#x2a;                                    $Y$0 REMOVE_SUB_LDAP_QUOTE "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$=$0@$2$_ "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y$="$0"@$2$_ $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$=$0@$2$_ &#x2a;                                    $Y$=$0$_ MATCH_NOSUBADDRESS &#x2a;&#x7c;&#x2a;  $C$&#x7c;REMOVE_SUBADDRESS;$0&#x7c;&#x7c;$&#x7c;REMOVE_SUBADDRESS;$1&#x7c; &#x2a;&#x7c;$0&#x2a; $Y AUTH_REWRITE ! Check to see if the From: matches the authenticated user&#x27;s mail attribute; ! exit with success if it does &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $C$&#x7c;MATCH_NOSUBADDRESS;$2$&#x7c;$3&#x7c;$E ! Fetch the base DN we&#x27;ll need to look up the user &#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CBASE&#x7c;$}$4,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check to see if the From: matches the authenticated user&#x27;s ! mailAlternateAddress, mailEquivalentAddress, or sendOnBehalfOf attributes. BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CFOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(&#x7c;(mailAlternateAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(mailEquivalentAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(sendOnBehalfOf=$1)))&#x5b;&#x7c;$1&#x7c;$2 ! Exit with success if it does FOUND&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $E ! Now switch the base DN to that of the domain specified in the From: address BASE&#x7c;&#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CSECONDARY_BASE&#x7c;$}$2,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check and see if the address owner granted send-on-behalf-of permissions SECONDARY_BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CSECONDARY_FOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(&#x7c;(mail=$=$1$_)(mailAlternateAddress=$=$1$_)(mailEquivalentAddress=$=$1$_))(mailGrantSendPermissionsTo=$=$2$_))&#x5b;&#x7c;$2 ! Exit with success if permission was granted - also add a Sender: field SECONDARY_FOUND&#x7c;&#x2a;&#x7c;&#x2a; $Y$1 ! Fail any other From: address &#x2a; $NYou$ are$ not$ authorized$ to$ send$ from$ the$ address$ you$ specified In the case of a "mailGrantSendPermissionsTo" granting permission, this mapping also adds a Sender: field containing the authenticated address of the actual sender. This can be disabled by changing the "$Y$!" in the SECONDARY_FOUND check to "$E".

Note that this example retains the ability to specify a sendOnBehalfOf attribute on the user permissions are being granted to. If this is not desirable the "(sendOnBehalfOf=$1))" search clause should be removed from the associated LDAP URL.

Also note that neither of the two preceding examples grant permissions to "send on behalf of" using subaddresses; adding this capability is straightforward.

Finally, if permission checks on both sides must succeed - a logical AND rather than an OR - the following set of mappings could be used: REMOVE_SUBADDRESS "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$0@$2 "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y"$0"@$2 $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$0@$2 &#x2a;                                    $Y$0 REMOVE_SUB_LDAP_QUOTE "$&#x5b;a-z0-9.#$&&#x27;&#x2a;\-/=?^_`{}\~&#x5d;&#x2a;+$_&#x2a;"@&#x2a; $Y$=$0@$2$_ "$_&#x2a;+$_&#x2a;"@&#x2a;                          $Y$="$0"@$2$_ $_&#x2a;+$_&#x2a;@&#x2a;                            $Y$=$0@$2$_ &#x2a;                                    $Y$=$0$_ MATCH_NOSUBADDRESS &#x2a;&#x7c;&#x2a;  $C$&#x7c;REMOVE_SUBADDRESS;$0&#x7c;&#x7c;$&#x7c;REMOVE_SUBADDRESS;$1&#x7c; &#x2a;&#x7c;$0&#x2a; $Y AUTH_REWRITE ! Check to see if the From: matches the authenticated user&#x27;s mail attribute; ! exit with success if it does &#x2a;&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $C$&#x7c;MATCH_NOSUBADDRESS;$2$&#x7c;$3&#x7c;$E ! Fetch the base DN we&#x27;ll need to look up the user &#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CBASE&#x7c;$}$4,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check to see if the From: matches the authenticated user&#x27;s ! mailAlternateAddress, mailEquivalentAddress BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CUSER&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(&#x7c;(mailAlternateAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)(mailEquivalentAddress=$&#x7c;REMOVE_SUB_LDAP_QUOTE;$1&#x7c;)))&#x5b;&#x7c;$1&#x7c;$2 ! Exit with success if it does USER&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $E ! Must now match the sendOnBehalfOf attribute. BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; $CFOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(mail=$=$2$_)(sendOnBehalfOf=$=$1$_))&#x5b;&#x7c;$1&#x7c;$2 ! Now switch the base DN to that of the domain specified in the From: address FOUND&#x7c;&#x2a;&#x7c;&#x2a;@&#x2a;&#x7c;&#x2a;@&#x2a; $CSECONDARY_BASE&#x7c;$}$2,_base_dn_{&#x7c;$1@$2&#x7c;$3@$4 ! Check and see if the address owner granted send-on-behalf-of permissions SECONDARY_BASE&#x7c;&#x2a;&#x7c;&#x2a;&#x7c;&#x2a; \ $CSECONDARY_FOUND&#x7c;$&#x5d;ldap:///$0?uid?sub?(&(&#x7c;(mail=$=$1$_)(mailAlternateAddress=$=$1$_)(mailEquivalentAddress=$=$1$_))(mailGrantSendPermissionsTo=$=$2$_))&#x5b;&#x7c;$2 ! Exit with success if permission was granted - also add a Sender: field SECONDARY_FOUND&#x7c;&#x2a;&#x7c;&#x2a; $Y$1 ! Fail any other From: address &#x2a; $NYou$ are$ not$ authorized$ to$ send$ from$ the$ address$ you$ specified

See also:
 * authrewrite Option
 * FROM_ACCESS mapping table
 * Recipient access mapping tables
 * mapping_paranoia MTA Option
 * saslpassauth Option
 * acceptalladdresses Option
 * Pre-defined mapping tables