.dom naming scheme;
however, this filename extension makes it easier to
determine the purpose of the file.
|
|
MMDF uses domain tables to match a short host name to its fully qualified host name. This allows users to address mail to other machines within a host's domain using just the host's name, instead of requiring each host's fully qualified domain name in addresses. For example, if the domain your_company.COM includes machines named volga, yangtze, mekong, and seine, a user on volga can address mail to user andrei on yangtze as andrei@yangtze instead of having to use the fully qualified name, andrei@yangtze.your_company.COM.
Domain tables can also convey information to MMDF about how machines are connected, and they can specify special domain routing considerations.
Domain tables are named using domain_name.dom (except for root.dom, which contains any domain information not named in other domain tables). The standard practice is to maintain a separate domain table for the domain in which the host machine resides. Domain tables are created by default in the /usr/mmdf/table directory (or the directory specified by the MTBLDIR parameter in the mmdftailor file).
The SCO OpenServer system includes two domain tables in the /usr/mmdf/table directory:
| Domain table | Domain | Describes |
|---|---|---|
| local.dom | local | machines in the local domain |
| root.dom | root | domains not listed in other domain tables |
Use the
Domain Administration Manager
to create new domain tables for each domain.
For example, create a domain table for the your_company.com
domain and name it your_company.dom.
You do not need to use the .dom naming scheme;
however, this filename extension makes it easier to
determine the purpose of the file.
Each domain table consists of at least two columns of information: the first (leftmost) column lists the host name and the second column lists the fully qualified name for that host. The domain names can be either upper- or lowercase. Use tabs, spaces, a colon, or a combination of these characters to separate the columns. Additional columns indicate names of one or more forwarding machines (machines through which mail should be routed for delivery to the host listed in the second column).
The name of a domain table determines the domain names for which MMDF searches. For instance, the domain table for UUCP generally contains entries for names in this form:
hostname: hostname.UUCPHowever, you can create an entry to map a specific UUCP address to another address. For example, to map research.uucp to research.jcn.com, the entry in the uucp.dom table looks like this:
research: research.jcn.comThe following sections give examples of different domain tables.
The local.dom table describes the machines in the local domain (independent of the channel that MMDF uses to reach each machine). For example, if there are four machines in the domain your_company.com, the domain.dom table looks like this:
volga: volga.your_company.COM yangtze: yangtze.your_company.COM mekong: mekong.your_company.COM seine: seine.your_company.COMThe domain.dom table maps each machine to the fully qualified host name in the your_company.com domain.
The root.dom table defines any the hosts and domains not defined in the other domain tables. This table can also contain information about how to access top-level domains, such as MIL and GOV. For example, if your host connects to the UUnet network system, you can set up MMDF to send all mail addressed to specific domains to uunet.uu.net. To do so, set up your root.dom table like this:
COM: uunet.UU.NET EDU: ucscc.EDU MIL: uunet.UU.NET GOV: star.GOV NET: uunet.UU.NETIn this example, all mail directed to the com, mil, and net domains is sent out on UUnet; mail directed to the gov domain goes to star.gov; and mail sent to the edu domain goes to ucscc.edu. This includes mail addressed to domains that are contained within the named domains. For example, mail sent to user@cs.berkeley.edu is sent to ucscc.edu unless a separate domain entry exists for cs.berkeley.edu or for berkeley.edu.
The uucp.dom table is created if UUCP is configured on your system and if you add any hosts with a fully qualified name of hostname.UUCP . This table describes the hosts in the UUCP domain. For example, if your host connects to the remote machines cactus or palm via UUCP, the uucp.dom table looks like this:
cactus: cactus.UUCP palm: palm.UUCPIn this case, MMDF directs any mail sent to the cactus or palm machines to the UUCP network.
Use the Domain Administration Manager to create new domain tables. When you subsequently add new hosts that belong to that domain, they are added to the appropriate table. For example, if you create the domain table rivers.dom and then add a host named nile.rivers.COM, this entry is added to rivers.dom:
nile: nile.rivers.COM
If you are configuring MMDF for use on a local area network
(LAN), you can use the domain tables to distribute
the processing load on the machines, or you can designate a
special mail server machine to route all the messages.
You have these choices:
Each machine's domain table only needs to include badhosts and
badusers channels that contain the fully qualified host
name of the server.
The domain table can be the same for each machine in the network.
The network can grow, and machines can be added and removed with
no effect on the domain tables of other computers.
The disadvantage is that the server receives a great deal of
traffic and should be dedicated to its task.
In addition, if the server is down, so is all mail
between machines.
The best policy is a system of machines grouped around a
server that has knowledge of another server; each server has
knowledge of yet another and so on.
The advantage is that networked machines can operate independently of each other. One machine's crash has no effect on the mail capability of the others (unless that machine is connected to another network via UUCP). The disadvantages are that system administration gets geometrically more difficult as you add or remove machines to or from the network. When a machine or user is added to or removed from the network, you must update all domain or alias tables to recognize the change. Because a domain table can contain redundant information about the local machine, you can use one domain table on every machine. You should only use distributed processing for small networks.
You can greatly simplify the distributed processing configuration by running a name server program on your network. For details on setting up the name server, see ``Configuring the Domain Name Service'' and ``Selecting name server lookup method''.
In addition to containing the names of the local machines on the LAN, a gateway machine also contains the names of the other machines to reach over the other networks. This information is kept in the respective domain and channel tables for the other networks and also in the root.dom table on the gateway machine. Other machines on the LAN use the badhosts channel to route non-local mail to the gateway machine, or a root.dom table that lists all the top-level domains as routing through the gateway. To avoid overloading the gateway machine, the other machines on the LAN should use local domain tables as described in the earlier ``Distributed Processing'' bullet.