tables(F) 19 June 1992 tables(F) Name tables - MMDF name tables for aliases, domains, and hosts Description All of the MMDF name tables are encoded into a database which 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 ::= {string of chars not containing a <separator>} separator ::= {':' and whitespace} value ::= {string of chars not containing an <eol>} eol ::= {newline, nullch, DEL} where: name is a key value is any relevant text. 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 (.) (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 con- nected or reached through a relay associated with the channel. The dis- tinction between hosts as physical entities, and domains as logical enti- ties should be noted. All hosts known to an MMDF system must have unique names. For this reason, the convention of labeling hosts by an associ- ated 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: 1. To map a string into a fully expanded domain name. 2. To map this domain into a source route starting with a host. 3. 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 tailor 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 tailor file. The structure of a domain table is to have name as the part of the domain not in the tailor file. 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 The possible values of dmseparator are given in tai(S), although typi- cally (,) or ( ) would be used. 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 the tailor file. 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 top domain in the tailor file, the name and dmn parameters of the domain should be set to "". 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 trans- port 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. P.O. box channels POBox channels, for passive, telephone-based exchange, operate in two modes. In the first mode, a single login is authorized to pickup all mail for the channel. In this case, the host-table addresses are only used for the "collecting" function. For the second mode, different log- ins share the channel and are to receive only some of the mail queued for the channel. In this case, the login is treated as an "address", and the table entries should have the value fields contain the name of the login authorized to pickup mail for that "host". Access control tables Channels also have access control tables associated with them, to deter- mine 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 (RFC733 or JNT Mail route) address, with the local domain as the root. Local aliases The password file specifies the mailing names are login 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 the tailor file. An alias entry may be used for one of five functions: 1. True aliasing, where the key value maps to a local user's login name, for example ``dave:dcrocker;'' 2. Forwarding, where the key value maps to a foreign address, such as ``dcrocker:dcrocker@udel;'' and 3. Address lists, where the key value maps to a set of addresses, such as ``mother:cotton,dcrocker,farber.'' 4. Redirection of a message to a file: for example, ``foobar:dpk/foobar'' would cause user and group ids to be set to 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. 5. 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 news. As a convenience, the value-part of an entry may specify a file name, so that the actual value is taken from the file. There are two possible notations for this: 1. By having left-angle bracket (<) precede the value specification. For example: ``mother: < /etc/mmdf/mother_list@udel-relay.arpa.'' 2. 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 at 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 con- veniently, 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 tailoring 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 recom- mended. 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 Mail-IDs file, but should have only one entry in the users file. This does not prevent them from send- ing mail with any of their Mail-IDs. The users file is just a source of default Mail-IDs. Value added tables is an extension of AT&T System V provided by The Santa Cruz Opera- tion, Inc. Credit MMDF was developed at the University of Delaware and is used with permis- sion.