PMDF System Manager's Guide
Previous Contents Index

3.1.1 The Alias File

Aliases are kept in a central file, usually aliases in the PMDF table directory. 3 Each time a PMDF program begins running, this file is read and loaded into an internal hash table. This overhead may be avoided by compiling your PMDF configuration in which case the contents of the alias file will be incorporated into the compiled configuration. The disadvantage to this, however, is that it means that the configuration must be recompiled and reinstalled whenever a change is made to the alias file or an include file used by the alias file. See Section 8.1 for details on compiling your configuration.

The alias file and any files it references should be world readable. Failure to allow world read access will lead to erratic behavior.

3.1.1.1 Format

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 60 characters each. Each address a1, a2, etc., may contain up to 252 characters. 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.

Alternatively, rather than having an address or comma separated list of addresses as the translation of an alias, an alias may translate to a mailing list reference as discussed in Section 3.1.1.3 below, or to an LDAP URL reference as discussed in Section 3.1.1.4 below.

Example 3-1, Example 3-2, and Example 3-3 show typical, minimal alias files on OpenVMS, UNIX, and NT, respectively.

An alias should normally be a valid RFC 8224 local-part; however, the ALIAS_DOMAINS PMDF option (see Section 7.3.1) controls the format of aliases and use of a non-default value for ALIAS_DOMAINS can specify that aliases consist of the 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": doe@example.com 
john.doe: doe@example.com
OpenVMS postmasters in particular should note also that RFC 822 addresses do not contain VMS MAIL's IN% wrapper; nor are DECnet style addresses (e.g., NODE::USER) valid RFC 822 addresses.

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 certain sorts of errors in the format of aliases will not result in an immediate error message, but rather mail to the bad addresses will just be silently dropped; use PMDF TEST/REWRITE (OpenVMS) or pmdf test -rewrite (UNIX or NT) to check aliases, and see Section 3.1.5 for further general information on alias files.

3.1.1.2 Including Other Files in the Alias File

Other files can be included in the primary alias file. A line of the form 


<file-spec
directs PMDF to read the file file-spec. The file specification must be a complete file path specification and the file must have the same protections as the primary alias file; i.e., it must be world readable.

The contents of the included file are inserted into the alias 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 alias file itself. Indeed, include files may themselves include other files. Up to three levels of include file nesting are allowed.

If a compiled configuration is being used, then the configuration must be recompiled and reinstalled before changes to any included file (or the primary alias file itself) will take effect. Note that this is not the case for mailing list files described in the next section.

3.1.1.3 Mailing Lists

A mailing list address is a special address created through the alias file or alias database. A mailing list address alias with associated mailing list file file-spec or LDAP URL ldap-url is specified in the alias file with an entry of, respectively, the general form 


alias: <file-spec, optional-parameters
or 


alias: <ldap-url, optional-parameters
Similar definitions may also be made in the alias database, (though of course omitting the colon, as just white space separates the alias from its definition in the alias database).

Mailing lists have many options associated with them; for a full discussion of mailing list aliases, see Chapter 4.

3.1.1.4 LDAP URLs as Alias Values

An alias value (that is, the right hand side of an alias definition) may be specified either as an address directly, e.g., user@domain, or indirectly referencing an LDAP URL---specifically, an LDAP search URL---that returns one or more addresses. The format is 


alias: <"ldap-url"

Note
The LDAP URL must be specified in double-quotes if it contains any commas.
Note that this is just a special case of use of an LDAP URL for a mailing list definition, as mentioned in Section 3.1.1.3: the LDAP query URL may be such as to return only one address rather than multiple addresses, and all of the optional mailing list parameters are omitted.

Standard LDAP URLs are used, with the host and port omitted; the host and port are instead specified with LDAP_HOST and LDAP_PORT PMDF options (see Section 7.3.2 for further discussion of these options). That is, the LDAP URL should be specified as 


ldap:///dn[?attributes[?scope?filter]]
where the square bracket characters [ and ] shown above indicate optional portions of the URL. The dn is required and is a distinguished name specifying the search base. The optional attributes, scope, and filter portions of the URL further refine what information to return. For an alias, the desired attributes to specify returning would typically be the mail attribute (or some similar attribute). The scope may be any of base (the default), one, or sub. And the desired filter might be to request the return of any object that has the "objectclass=person" and "cn=John Smith" attribute-value pairs.

For instance, at a site example.com with an LDAP server running on port 389 of the system ldap.example.com, the PMDF option file might have the lines 


LDAP_HOST=ldap.example.com 
LDAP_PORT=389
set, and an alias file line might appear as: 


John.Smith:  <"ldap:///o=example.com?mail?sub?(objectClass=person,cn=John Smith)"

Note that port number 389 is the default. Also note that LDAP URL is specified in double-quotes since it contains commas.

Substitution sequences, as shown in Table 3-1, are available for use in constructing the LDAP URL.

Table 3-1 LDAP URL Substitution Sequences
Substitution  
sequence Description
$$ Literal $ character
$~ account Home directory of user account
$A Address
$D Domain name
$H Host name (first portion of fully qualified domain name)
$L Username minus any special leading characters such as ~ or _
$S Subaddress
$U Username

3.1.1.5 Standard Aliases

Certain aliases should be provided in every alias file. If no account with the name postmaster exists on the system, an alias for postmaster should be provided that translates into the username of the person responsible for maintaining PMDF (often, but not always, the SYSTEM account on OpenVMS systems or the root account on UNIX systems). It is also a good idea to provide an alias for postmast, since some mail systems cannot handle mailbox names with more than eight characters. In addition, on OpenVMS systems, an alias for root should also be provided since many UNIX systems send mail to root when attempting to contact the local system manager. A minimal alias file for an OpenVMS system would then be as shown in Example 3-1.

Example 3-1 A Minimal Alias File, aliases. , on OpenVMS 

postmast: postmaster 
postmaster: system 
root: system
A minimal alias file for a UNIX system would be as shown in Example 3-2.

Example 3-2 A Minimal Alias File, aliases , on UNIX 

postmast: postmaster 
postmaster: root
A minimal alias file for an NT system would be as shown in Example 3-3.

Example 3-3 A Minimal Alias File, aliases , on NT 

postmast: postmaster 
postmaster: Administrator

3.1.1.6 Subaddresses in Aliases

As background on the purpose of subaddresses, the L, popstore, and msgstore channels interpret a + character in an address specially: in an address of the form name+subaddress@localhost or name+subaddress@popstoredomain PMDF considers the portion of the mailbox after the plus character a subaddress. The L and popstore channels treat a subaddress as additional cosmetic information and, assuming no aliases or other address transformations apply, actually delivers to the account name without regard to the subaddress. The msgstore channels treat a subaddress as specifying a folder to which to deliver; that is, msgstore channels deliver to the name account's subaddress folder.

When looking up an alias, the use of subaddresses introduces an extra factor. The PMDF local channel, that is, the L channel on OpenVMS or UNIX or the first msgstore channel on NT, or any channel marked with the aliaslocal keyword, will try looking up aliases.

Subaddresses in aliases are handled as follows. By default, (that is, with the subaddressrelaxed keyword explicitly or implicitly on the channel doing the alias lookup), PMDF first checks for an alias entry including the subaddress; if no such entry is found, PMDF next checks for an entry with an asterisk, *, in place of the subaddress. Finally, if there is no prior match, PMDF checks for an entry without any subaddress. For instance, alias entries 


adam+privileged:   system 
adam:              bob+* 
carl+special:      system 
carl+*:            david+* 
carl:              eric
cause PMDF to translate adam+privileged to system and adam to bob, while adam+talklist, adam+general, etc., will be translated to bob+talklist, bob+general, etc. carl+special will be translated to system and carl to eric, while carl+talklist, carl+general, etc., will be translated to david+talklist, david+general, etc.

This handling of subaddresses during alias lookups is configurable; see Section 2.3.4.71.

3.1.1.7 Alias List Recursion

Aliases may reference other aliases, both in the alias database as well as in the alias file. PMDF limits such references to a maximum of ten levels to avoid possible infinite recursion loops.

If an alias references itself, either directly or indirectly, an alias loop results. The loop eventually terminates due to the level restriction, but the termination conditions may not produce consistent results in all cases.

The special case of an alias directly referencing itself is allowed and specially handled. For example, the alias file definition 


alias-name: alias-name, other-address-1, other-address-2, ...

will expand alias-name into itself plus other-address-1, other-address-2, and so on. alias-name may in turn get expanded in some other way (the system or personal alias database) but it will not be expanded further by the alias file.

Note

3 On OpenVMS systems, the PMDF alias file is pointed at by the PMDF_ALIAS_FILE logical; by default, it is the file PMDF_TABLE:aliases.. On UNIX systems, it is the file specified with the PMDF_ALIAS_FILE option in the PMDF tailor file; by default, the file /pmdf/table/aliases. On NT systems, it is the file specified with the PMDF_ALIAS_FILE NT Registry entry, usually pointing to a file such as C:\pmdf\table\aliases.

4 A copy of RFC 822, a basic reference for any e-mail administrator, is shipped with the PMDF distribution; it should be present as PMDF_DOC:[rfc]rfc822.txt on OpenVMS, or as /pmdf/doc/rfc/rfc822.txt on UNIX, or as C:\pmdf\doc\rfc\rfc822.txt on NT, unless your site chose not to install it.

Previous Next Contents Index