The MTA provides a facility to support mailbox names associated with the local system that do not necessarily correspond to actual users: aliases. Aliases are useful for constructing mailing lists, forwarding mail, and providing synonyms for user names. For a discussion on how alias resolution is handled see 18.104.22.168 The $V Metacharacter
Old-style mailing lists defined in the aliases file or aliases database now accept a nonpositional [capture] parameter. If used, the [capture] parameter specifies a capture address with the same semantics as capture addresses specified by the LDAP_CAPTURE attribute applied to a user or group in LDAP.
A value "/" given as an [envelope_from] nonpositional alias parameter, as an error to positional alias parameter, or as a value of the mgrpErrorsTo LDAP attribute, is now interpreted as a request to revert to using the original envelope From: address for the incoming message while retaining mailing list semantics. This can be useful for setting up mailing lists that report all forms of list errors to the original sender.
Use of the Alias Database is discouraged. Use the aliases file instead, especially since it can be dynamically reloaded using the imsimta reload command.
The MTA uses the information in the directory and creates the alias database. The alias database is consulted once each time the regular alias files is consulted. However, the alias database is checked before the regular alias file is used. In effect, the database acts as a sort of address rewriter that is invoked prior to using the alias file.
The format of the database itself is private. Do not try to edit the database directly. Make all required changes in the directory.
The aliases file is used to set aliases not set in the directory. In particular, the postmaster alias is a good example. Aliases set in this file will be ignored, if the same aliases exist in the directory. Changes can be activated by issuing the imsimta reload command (or restarting the MTA). Any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored.
Messaging Server provides other facilities for address manipulation, such as the address reversal database and specialized mapping tables. For best performance, however, rewrite rules should be used whenever possible to perform address manipulations. See Chapter 11, Configuring Rewrite Rules.
A physical line in this file is limited to 1024 characters. You can split a logical line into multiple physical lines using the backslash (\) continuation character.
The format of the file is as follows:
user@domain: address (for users in hosted domains) user@domain: address (for users in non-hosted domains. Example: default-domain)
! A /var/mail/ user email@example.com: inetmail@native-daemon ! A message store user firstname.lastname@example.org: mstestuser@ims-ms-daemon
The file specification must be a complete file path specification and the file must have the same protections as the primary aliases file; for example, it must be world readable.
The contents of the included file are inserted into the aliases file at its point of reference. The same effect can be achieved by replacing the reference to the included file with the file's actual contents. The format of include files is identical to that of the primary aliases file itself. Indeed, include files may themselves include other files. Up to three levels of include file nesting are allowed.