Alias file format

The alias file format is as follows: alias1: a1,a2,...,am alias2: b1,b2,...,bm .            .    .             .    .             .  aliasn: n1,n2,...,nm .            .    .             .    .             . where   is translated into the addresses   ,  ,   , ...,  . The aliases  ,  , ...,   are limited to 128 characters each. (In iMS 5.2 and earlier, the limit had been 64 characters.) Each address  ,  ,  etc., may contain up to 256 characters (252 characters in iMS  5.2 and earlier). There is no limit to the number of addresses that can be specified for an alias (that is, appear in a single list on the right hand side of an  alias definition), although excessive numbers of addresses may eat up  excessive amounts of memory. A physical line of the alias file may contain at most 1024 characters. To specify a list of addresses containing more than that number of    characters, the line must be continued onto multiple physical lines. Long lines may be continued by ending them with a backslash,. A backslash must follow a comma. There can be no white space preceding the colon separating the alias name from its  translation value.

An alias expansion address prefixed with a colon character, , has a special interpretation. The alias expansion address will be used as normal except when the MTA is  generating a  notification message  (a Delivery Status Notification such  as a bounce message, or a Message Disposition Notification such as a  vacation messages); when generating a notification message regarding  the alias, the unexpanded alias will be used rather than the alias  expansion value (which would normally be used). This mechanism can be useful in cases where an alias expansion address is an  "internal" address that should not be exposed to the outside. It is essentially an alias-specific analogue of the  channel option. For instance, with aliases defined as adam: :bob@ims-ms-daemon carl: donald@ims-ms-daemon messages sent to adam will be redirected to bob@ims-ms-daemon. But if a notification message needs to be sent back to an original message  sender, the notification message will refer to address adam, rather  than to bob@ims-ms-daemon. This contrasts with the case of notification messages regarding messages sent to carl; in this case, any  notification messages will refer to the donald@ims-ms-daemon address.

The matching process is configurable for aliases containing a subaddress, that is, aliases of a form such as: adam+hobbylist: adam-personal-mailbox@domain.com See the  channel options for details.

An address (or addresses) on the right hand side of an alias file entry may optionally have various so-called  named parameters associated with  it (or them). Such named parameters are more commonly of interest and used with  mailing list definitions,  but some (in  particular, &#x5b;BLOCKLIMIT&#x5d;, &#x5b;CAPTURE&#x5d;, &#x5b;JOURNAL&#x5d;, &#x5b;CONVERSION_TAG&#x5d;, and  &#x5b;FILTER&#x5d;), can be of interest for individual aliases as well. Such parameters are specified by listing them at the beginning of  the right hand (translation) side of the alias entry; the parameters  then apply to all addresses on the right hand. Thus an alias entry using named parameters and translating to a single addresses would have the form: alias: &#x5b;p-name-1&#x5d; p-value-1,...,&#x5b;p-name-k&#x5d; p-value-k,address while an alias entry using named parameters and translating to multiple addresses (hence an e-mail group, or perhaps mailing list, depending upon which named parameters are set) would have the form: alias: &#x5b;p-name-1&#x5d; p-value-1,...,&#x5b;p-name-k&#x5d; p-value-k,address-1,...,address-j corresponding to Unified Configuration alias option settings along the lines of: msconfig&#x3e; show alias:alias alias:alias.alias_entry = address-1 alias:alias.alias_entry = address-2 ... alias:alias.alias_entry = address-j alias:alias.p-name-1 = p-value-1 alias:alias.p-name-2 = p-value-2 ... alias:alias.p-name-k = p-value-k Alternatively, rather than having an address or (in legacy configuration) a comma separated list of addresses as the translation of an alias, in the alias file an alias may translate to a  mailing list reference as discussed in  Alias file mailing list aliases, or to an  LDAP URL reference as discussed in  Alias file LDAP URL alias values.

A typical, minimal alias file will include at least a postmaster alias definition. (See alias_entry for a discussion of minimal such postmaster alias definition in a modern, Unified Configuration setup.)

In older versions of the MTA, an alias was normally simply a valid RFC 822 "local-part"; however, in more modern MTA configurations, with the  MTA option set to a value of , an alias consists of an entire address, including  the domain name, rather than just the local-part. In particular, aliases must follow RFC 822 syntax rules for local-parts (or addresses, when    has selected use of addresses); this  means that for proper functioning, with the exception of periods which  are specifically allowed in local-parts without quoting, the presence  of any other RFC 822 "specials" character or a space in an alias will require that the alias be enclosed in double quotes, e.g., "John Doe": doe@acme.com john.doe: doe@acme.com Comment lines are allowed in the alias file. A comment line is any line that begins with an exclamation point, , in column one.

Duplicate aliases (identical left hand sides) are not allowed in the alias file.

Note that prior to MS 6.1, certain sorts of errors in the format of aliases would not result in an immediate error message, but rather mail  to the bad addresses would just be silently dropped. For instance, use of an apparently local (and syntacticaly unexceptional) but in fact  non-existant user address as a value (on the right hand side) would not  necessarily result in any error message---not if there was at least one  apparently valid value on the right hand side. (This is in contrast to overt syntactic errors in the alias file format itself, which have  always been report ed at MTA process startup time, or at    time  if a compiled configuration is in use. It is also  in contrast to delivery problems to addresses that, at alias expansion  time, appear potentially valid; delivery problems are and always have  been reported back to the appropriate notification address, if any. It  is also in contrast to the case where all of the values appear  to be invalid.) As of MS 6.1, errors apparent at alias expansion  time in aliases are reported to the other members of the alias. But in any case, when defining an alias it is a good idea to use    to check aliases,  and see Alias restrictions for further general information on alias operation and the alias file.

See also:
 * Aliases in LDAP
 * Aliases in Unified Configuration
 * useintermediate Option
 * subaddressexact Option
 * Notification message types
 * Alias file include files
 * Alias file named parameters
 * Alias file mailing list aliases
 * Alias options
 * Alias file LDAP URL alias values
 * Alias restrictions
 * alias_domains MTA Option
 * cnbuild utility
 * test -rewrite utility
 * Alias recursion and nested list definitions
 * Alias file
 * Aliases