Alias envelope from alias option

Alias options:
The  alias option   takes a required value specifying an address to replace  the message&#x27;s original envelope From address. The legacy configuration analogue is the &#x5b;ENVELOPE_FROM&#x5d; alias file named parameter. This sets only the envelope From address,   (unlike the alias file   positional parameter which  also sets an Errors-to: address).

Setting the value to an address of the form   has a special meaning. The asterisk character will be expanded into a representation of the  recipient address; thus a separate copy of the list message is  generated for each recipient, with each copy including the intended  recipient address as a  subaddress within the return address. If delivery errors subsequently occur, the subaddress will indicate which  was the failing address. In some cases, when dealing with remote MTAs that generate nonstandard, uninformative delivery error messages, this  can in theory be useful as a way of determining which recipient  address(es) failed, even when the bounce message&#x27;s inner content is  relatively uninformative. And it may make processing of such bounce messages by an automated program more convenient. However, the tradeoff is that such per-user-specific return address values require that a  separate message copy be generated and sent for each recipient; for a  "large" list, with many recipients in the same destination  domains, this can be a large increase in overhead (a large decrease in  efficiency). And with more prevalent use nowadays of standard format notification messages,  the "need" for this sort of approach,  with its extra (potentially large) overhead, is much less (since the  intended recipient information can instead be extracted from the  standard field in the contents of a standard format notification  message).

(New in MS 6.3.) Setting the value to the forward slash character, , has a special meaning. It tells the MTA to revert to using the original envelope From address that had been  present on the incoming message, yet in all other respects use mailing  list semantics. This can be useful for setting up mailing lists that report all forms of list errors to the original sender.

For groups and lists defined in LDAP, see the   attribute (or more precisely, the attribute named by the    MTA option).

See also:
 * Alias options
 * Alias file named parameters
 * ldap_errors_to MTA Option
 * subaddressexact Option
 * Notification messages
 * Proper use of lists rather than groups