tables(F)

tables -- MMDF name tables for aliases, domains, and hosts

Description

All of the MMDF name tables are encoded into a database that is built on top of the dbm(S) package. A number of tables are associated with MMDF, the exact set being specified by the tailor file, /usr/mmdf/mmdftailor. Name tables all have the same format. Functionally, they permit a simple key/value pairing. The syntax for tables is specified here:

entries ::=: entries entry
entry ::=: comment | real-entry
comment ::=: ``#'' value eol
real-entry ::=: name separator value eol
name ::=: {a key; a string of chars not containing a separator}
separator ::=: {``:'' and whitespace}
value ::=: {any relevant text; a string of chars not containing an eol}
eol ::=: {newline, null or DEL}

Hosts and domains

Two basic types of table are host and domain tables. This section gives a brief discussion of these concepts in terms of the MMDF system. The domain namespace is treated as a logical global hierarchy, according to the model of RFC 819, with subdomains separated by a period (.) (for example, ISI.USC.ARPA is a three level hierarchy with ARPA at the top level). A host is a computer associated with a channel which may be directly connected or reached through a relay associated with the channel. The distinction between hosts as physical entities, and domains as logical entities should be noted. All hosts known to an MMDF system must have unique names. For this reason, the convention of labeling hosts by an associated domain name is adopted in many cases. This is a useful method to guarantee unique names, but is not required.

The domain and host table structures are devised with three basic aims in mind:

To map a string into a fully expanded domain name.
To map this domain into a source route starting with a host.
To obtain the transport address associated with the host.

Domain tables

Domains are split in a two-level manner, with the top part of the tree specified in the mmdftailor file and the lower parts of the tree in tables. The two-level structure is intended as a balance between generality and efficiency. The order of searching is also specified in the mmdftailor file. The structure of a domain table is to have name as the part of the domain not in mmdftailor. Thus for ISI.USC.ARPA there might be a domain ARPA with name ``isi.usc'' or domain USC.ARPA with name ``isi''. The structure of value is:

value ::=

(domain dm_separator) host

Typically ``,'' or a space are used for dm_separator. This value is essentially a source route to be traversed from right to left. Consider an example table for the domain ARPA:

   # Sample ARPA domain table
   isi.usc:a.isi.usc.arpa
   b.isi.usc:b.isi.usc.arpa
   foobar.isi.usc:b.isi.usc.arpa
   graphics.isi.usc:graphics.isi.usc.arpa z.mit.arpa

Thus, if the ``isi.usc.arpa'' is analyzed, domain table ARPA will be selected, and host ``a.isi.usc.arpa'' associated with domain ``isi.usc.arpa.'' If only ``isi.usc'' were given, the domain tables would be searched in order, and if the ARPA table were the first one to give a match, then the same result would be reached. If ``foobar.isi.usc'' is given, it would be mapped to host ``b.isi.usc.arpa'' and (official) domain ``b.isi.usc.arpa.'' If ``graphics.isi.usc.arpa'' is given, a source route to domain ``graphics.isi.usc.arpa'' through HOST ``z.mit.arpa'' will be identified. If ``xy.isi.usc.arpa'' (or ``xy.isi.usc'') is given, then it will not be found. However, a subdomain will be stripped from the left and the search repeated. Thus domain ``xy.isi.usc.arpa'' will be identified as reached by a source route through host ``a.isi.usc.arpa.''

As specified earlier, the order of searching is also specified in mmdftailor. For example, a host in domain UCL-CS.AC.UK, might have a search order UCL-CS.AC.UK, AC.UK, UK, SWEDEN, ARPA, ``''. Thus, if there were a domain isi.usc.ac.uk, it would be the preferred mapping for isi.usc over isi.usc.arpa. The last domain searched is null, ``''. This could be used to contain random fully qualified domains or to identify gateways to other domains.

An example file is:

#  Sample Top level domain table
#  Odd host
basservax.australia:basservax.australia scunthorpe.ac.uk
# UUCP Gateway
uucp:seismo.arpa
# Mailnet Gateway  (-> multics -> educom ->mailnet)
mailnet:educom.mailnet mit-multics.arpa

To specify the root domain in mmdftailor, the name and dmn parameters of the domain should be set to null, ``''.

Host tables

For every host associated with the channel, there will be one or more entries. In each case, the key is the name identified from the domain tables. A host may have multiple entries if it has more than one transport address which the channel might utilize.

When a channel just sends all its mail to a relaying site, the address portion (value) of the entry is not needed, directly, during the transmission process. Hence, it need not be accurate. However, it is still used to logically collect together host names, that is, all table entries with the same value are regarded as being aliases for the same host.

Access control tables

Channels also have access control tables associated with them, to determine whether a message is allowed to use a given route. Each channel has four (optional) tables that determine the access controls used: insrc, outsrc, indest, and outdest.

Reformatting tables

There may also be a ``known hosts'' table associated with each channel. This is exactly the same format as a host table. If a message is being reformatted, and if an address does not have its host in this list, then it will be modified to appear as a percent route (RFC 733 or JNT Mail route) address, with the local domain as the root.

Local aliases

The password file specifies login names as the mailing names of all local recipients. Since this is a rather restricted name space, and since it is useful to have some other kinds of locally-known names, there is a second file used to specify aliases. The location of the aliases file is specified in mmdftailor.

An alias entry may be used for one of five functions:

True aliasing, where the key value maps to a local user's login name, for example ``dave:dcrocker''.
Forwarding, where the key value maps to a foreign address, such as ``dcrocker:dcrocker@udel''.
Address lists, where the key value maps to a set of addresses, such as ``mother:cotton,dcrocker,farber''.
Redirection of a message to a file. For example, ``foobar:dpk/foobar'' would cause user and group ids to be set to those of the user dpk and the text of the message to be appended to the file foobar in dpk's default login directory. Similarly, ``foobar:dpk//tmp/foobar'' would do the same for file /tmp/foobar.
Redirection of a message to a pipe. For example, ``news-inject:news|/usr/lib/news/uurec'' would cause a message to be passed into a UNIX pipe (see pipe(S)) with userid and groupid set to those of the user news.

As a convenience, the value-part of an entry may specify a filename, so that the actual value is taken from the file. There are two possible notations for this:

By having left-angle bracket (<) precede the value specification. For example: ``mother: < /etc/mmdf/mother_list@udel-relay.arpa.''
By using a data type with value ``:include:''. For example: ``mother: :include: /etc/mmdf/mother@udel-relay.arpa''.

In both cases, the @HOST (not a domain) is optional. If specified, it should be the local host.

Recursive specification is permitted. For example, ``crocker'' may map to ``dcrocker'' and ``dcrocker'' may map to ``dcrocker@udel,'' so that both ``crocker'' and ``dcrocker'' are locally-known names, but mail sent to either of them will be forwarded to ``dcrocker@udel.''

In practice, it is useful to organize alias files into the following order:

List aliases: which contain a value referring to a later address list. This constitutes a one-to-one mapping of a key to a value, where the value points into the ``Lists'' group.
Lists: which contain values referring to multiple addresses: this constitutes a one-to-many mapping, where some of the addresses may refer to other entries (address lists) in the Lists group, as well as other entries (individual addresses) later in the table.
Mailbox aliases: which contain values referring to single addresses. These constitute one-to-one mappings, where the value refers to an entry in the password file or to an entry in the ``Forwarding aliases'' group.
Forwarding aliases: which contain values referring to single addresses on other machines. These, also, are one-to-one mappings, where the value always refers to an off-machine address.

By organizing the file in this manner, only the ``Lists'' portion requires a topological sort. Since the other three sections will never point to entries within their section, they may be sorted more conveniently, such as alphabetically. Such a structure also tends to make changes easy. In particular, the handling of forwarding is easy, since all references to a user will get intercepted, at the end of the table.

Mail-ID tables

The Mail-ID tables are used only if the Mail-IDs feature is enabled. This can be done in the mmdftailor file by defining MMAILID to be 1. Mail IDs are used to disassociate mail addresses from login names. There are two tables that are used to map Mail IDs to users' login names and login ids to Mail IDs. The users file is used to map users (login ids) to Mail IDs, and the mailids file is used to map Mail IDs to users. The names of these files can be overridden, but it is not recommended. Each file has lines with two entries per line (user and Mail ID, or Mail ID and user).

A user can have more than one entry in the mailids file, but should have only one entry in the users file. This does not prevent them from sending mail with any of their Mail IDs. The users file is just a source of default Mail IDs.

NOTE: When the Mail-IDs feature is enabled, each user must have a Mail ID entry to send or receive mail. If root (or the postmaster, if not root) does not have a Mail ID, no mail can be sent.

Standards conformance

MMDF is not part of any currently supported standard; it was developed at the University of Delaware and is used with permission.