This file contains a list of aliases for local users or mailing lists. The format of each alias is
alias_name~recip_name1~recip_name2~...
An attempt has been made to remain compatible with sendmail alias file format, though the syntax is much more format free than sendmail. As distributed, case differences are ignored when comparing names to aliases. Only alias names which resolve to the local host are recognized, and are stored in their local form. Lines which start with a white~space are continuation lines. Parenthesised strings are taken as comments (no nesting), as is anything after a '#' (as in /bin/sh). Here are some examples:
# this whole line is a comment
#
# These are equivalent definitions
alias_name recip1 recip2 recip3
alias_name: recip1, recip2 , recip3
alias_name recip1 recip2
recip3
alias_name recip1 # Recip1's name
recip2 # Recip2's name
recip3 # Recip3's name
alias_name recip1 (Recp1's name) recip2 (Recp2's name)
recip3 (Recp3's name)
alias_name@thishost recip1 recip2 recip3
alias_name@thisdomain recip1 recip2 recip3
thishost!alias_name recip1 recip2 recip3
thisdomain!alias_name recip1 recip2 recip3
Mailing lists are easily handled by two forms of file inclusion. The first form is the same as is supported by sendmail
mylist :include:/usr/lib/ml/mylist
In this example, each entry in /usr/lib/ml/mylist would be added to the alias for mylist. The second form is unique to smail. It allows the aliases file to include other aliases files.
:include:/usr/lib/ml/more-aliases
This would include the file /usr/lib/ml/more-aliases as a regular alias file. This makes it easier to maintain groups of aliases that change frequently, such as the list of netnews moderators.
All aliases are recursive, so care must be taken in their definition. smail aliasing attempts to prevent infinite loops, and to do what was intended by the user. For example, the alias:
mylogin~mypc!mylogin~mylogin
Expands to
mypc!mylogin mylogin
even though the second occurrence of mylogin matches the alias name.
Both forms of file inclusion are recursive, too, so watch out for nesting include files. They may lead to infinite loops.
While the cost of parsing an alias file is usually negligible, it's wise to take savings anywhere savings can be found. Therefore, it's worth mentioning smail's parsing strategy. smail will try to get by with doing as little work as possible when aliasing. If on a particular invocation of smail, none of the recipent addresses are local, (i.e., not potential aliases) then the aliases file won't even be read. Similarly, when an aliases file is read, it does not expand any of the :include: files until they are referenced. Thus, in the alias (above) for mylist, the file :include:/usr/lib/ml/mylist would not be opened and read (parsed) unless mail was sent to mylist. Wise use of :include: files can greatly increase the efficiency of the alias utility. It's not clear exactly where the break-even point is when deciding to use an :include: file in an alias, versus having all of the recipents listed on the line; but if a mailing list is large (whatever that means) it is wise to use the :include: feature to save on parsing costs. Note that this discussion only applies to the first form of file inclusion, since reading an aliases file constitutes a reference to :include: files of the second form.
There is another form of aliasing which works with the alias capability. This is called per user forwarding. For a given user name, if there is no alias for the user then, if the file ~user/.forward exists, then its contents will be treated as an alias for the user. The syntax is the same as that of the recipient lists in the alias file described above.
One difference between smail and sendmail is that smail doesn't handle stuff like mail to files or command execution.