Alias file format

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

The alias file format is as follows:

alias1: a1,a2,...,am 
alias2: b1,b2,...,bm 
  .             . 
  .             . 
  .             . 
aliasn: n1,n2,...,nm 
  .             . 
  .             . 
  .             . 

where aliasn is translated into the addresses n1, n2, n3, ..., nm. The aliases alias1, alias2, ..., aliasn are limited to 128 characters each. (In iMS 5.2 and earlier, the limit had been 64 characters.) Each address a1, a2, 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 useintermediate 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:


See the subaddress* 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, [BLOCKLIMIT], [CAPTURE], [JOURNAL], [CONVERSION_TAG], and [FILTER]), 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:  [p-name-1] p-value-1,...,[p-name-k] 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:  [p-name-1] p-value-1,...,[p-name-k] p-value-k,address-1,...,address-j

corresponding to Unified Configuration alias option settings along the lines of:

msconfig> 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 alias_domains MTA option set to a value of 6, 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 alias_domains 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": 

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 imsimta cnbuild 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 imsimta test -rewrite -check_expansions to check aliases, and see Alias restrictions for further general information on alias operation and the alias file.

See also: