897 lines
21 KiB
HTML
897 lines
21 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>How Does Mail Routing Work?</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Network Administrators Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Electronic Mail"
|
|
HREF="x-087-2-mail.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Email Addresses"
|
|
HREF="x-087-2-mail.address.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="Configuring elm"
|
|
HREF="x-087-2-mail.elm.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Network Administrators Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-mail.address.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 17. Electronic Mail</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-mail.elm.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="X-087-2-MAIL.ROUTING"
|
|
>17.4. How Does Mail Routing Work?</A
|
|
></H1
|
|
><P
|
|
>The process of directing a message to the recipient's host is called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>routing</I
|
|
>. Apart from finding a path from the sending
|
|
site to the destination, it involves error checking and may involve speed and
|
|
cost optimization.</P
|
|
><P
|
|
>There is a big difference between the way a UUCP site handles routing
|
|
and the way an Internet site does. On the Internet, the main job of
|
|
directing data to the recipient host (once it is known by its
|
|
IP address) is done by the IP networking layer, while in the UUCP zone,
|
|
the route has to be supplied by the user or generated by the mail
|
|
transfer agent.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-MAIL.ROUTING.INTERNET"
|
|
>17.4.1. Mail Routing on the Internet</A
|
|
></H2
|
|
><P
|
|
>On the Internet, the destination host's configuration determines
|
|
whether any specific mail routing is performed. The default is to
|
|
deliver the message to the destination by first determining what host
|
|
the message should be sent to and then delivering it directly to that
|
|
host.
|
|
|
|
Most Internet sites want to direct all inbound mail to a highly
|
|
available mail server that is capable of handling all this traffic and
|
|
have it distribute the mail locally. To announce this service, the
|
|
site publishes a so-called MX record for its local domain in its DNS
|
|
database. MX stands for <I
|
|
CLASS="EMPHASIS"
|
|
>Mail Exchanger</I
|
|
> and
|
|
basically states that the server host is willing to act as a mail
|
|
forwarder for all mail addresses in the domain. MX records can also be
|
|
used to handle traffic for hosts that are not connected to the
|
|
Internet themselves, like UUCP networks or FidoNet hosts that must
|
|
have their mail passed through a gateway.</P
|
|
><P
|
|
>MX records are always assigned a <I
|
|
CLASS="EMPHASIS"
|
|
>preference</I
|
|
>. This
|
|
is a positive integer. If several mail exchangers exist for one host,
|
|
the mail transport agent will try to transfer the message to the
|
|
exchanger with the lowest preference value, and only if this fails
|
|
will it try a host with a higher value. If the local host is itself a
|
|
mail exchanger for the destination address, it is allowed to forward
|
|
messages only to MX hosts with a lower preference than its own; this
|
|
is a safe way of avoiding mail loops. If there is no MX record for a
|
|
domain, or no MX records left that are suitable, the mail transport
|
|
agent is permitted to see if the domain has an IP address associated
|
|
with it and attempt delivery directly to that host.</P
|
|
><P
|
|
>Suppose that an organization, say Foobar, Inc., wants all its mail
|
|
handled by its machine <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>mailhub</SPAN
|
|
>.
|
|
It will then have MX records like this in the DNS database:
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>green.foobar.com. IN MX 5 mailhub.foobar.com.</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This announces <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>mailhub.foobar.com</SPAN
|
|
> as
|
|
a mail exchanger for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>green.foobar.com</SPAN
|
|
>
|
|
with a preference of 5. A host that wishes to deliver a message to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>joe@green.foobar.com</SPAN
|
|
> checks DNS and finds the MX record pointing at
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>mailhub</SPAN
|
|
>.
|
|
If there's no MX with a preference smaller than 5, the message is delivered to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>mailhub</SPAN
|
|
>, which then
|
|
dispatches it to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>green</SPAN
|
|
>.</P
|
|
><P
|
|
>
|
|
|
|
This is a very simple description of how MX records work. For more information
|
|
on mail routing on the Internet, refer to RFC-821, RFC-974, and RFC-1123.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-MAIL.ROUTING.UUCP"
|
|
>17.4.2. Mail Routing in the UUCP World</A
|
|
></H2
|
|
><P
|
|
>Mail routing on UUCP networks is much more complicated than on the
|
|
Internet because the transport software does not perform any routing
|
|
itself. In earlier times, all mail had to be addressed using bang paths.
|
|
Bang paths specified a list of hosts through which to forward the
|
|
message, separated by exclamation marks and followed by the user's
|
|
name. To address a letter to a user called Janet on a machine named
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>, you would use the path
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>eek!swim!moria!janet</SPAN
|
|
>. This would
|
|
send the mail from your host to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>eek</SPAN
|
|
>, from there on to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>swim</SPAN
|
|
>, and finally to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>.</P
|
|
><P
|
|
>The obvious drawback of this technique is that it requires you to
|
|
remember much more about network topology, fast links, etc. than
|
|
Internet routing requires. Much worse than that, changes in the
|
|
network topology—like links being deleted or hosts being
|
|
removed—may cause messages to fail simply because you aren't
|
|
aware of the change. And finally, in case you move to a different
|
|
place, you will most likely have to update all these routes.</P
|
|
><P
|
|
> One thing, however, that made the use of source routing necessary was
|
|
the presence of ambiguous hostnames. For instance, assume there are two
|
|
sites named <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>, one in the U.S.
|
|
and one in France. Which site does
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria!janet</SPAN
|
|
> refer to now? This can
|
|
be made clear by specifying what path to reach
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> through.</P
|
|
><P
|
|
>
|
|
|
|
|
|
The first step in disambiguating hostnames was the founding of the UUCP
|
|
Mapping Project. It is located at Rutgers University and registers all
|
|
official UUCP hostnames, along with information on their UUCP neighbors
|
|
and their geographic location, making sure no hostname is used twice. The
|
|
information gathered by the Mapping Project is published as the
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>Usenet Maps</I
|
|
>, which are distributed regularly through
|
|
Usenet. A typical system entry in a
|
|
map (after removing the comments) looks like this:<A
|
|
NAME="X-087-2-FNMA06"
|
|
HREF="#FTN.X-087-2-FNMA06"
|
|
>[1]</A
|
|
>
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>moria
|
|
bert(DAILY/2),
|
|
swim(WEEKLY)</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This entry says <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> has a link
|
|
to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert</SPAN
|
|
>, which it calls twice a day,
|
|
and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>swim</SPAN
|
|
>, which it calls weekly. We
|
|
will return to the map file format in more detail later.</P
|
|
><P
|
|
>
|
|
|
|
Using the connectivity information provided in the maps, you can
|
|
automatically generate the full paths from your host to any
|
|
destination site. This information is usually stored in the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>paths</TT
|
|
> file, also called the <I
|
|
CLASS="EMPHASIS"
|
|
>pathalias
|
|
database</I
|
|
>. Assume the maps state that you can reach
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert</SPAN
|
|
> through <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ernie</SPAN
|
|
>; a pathalias entry for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> generated from the previous map
|
|
snippet may then look like this:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>moria ernie!bert!moria!%s</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>If you now give a destination address of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>janet@moria.uucp</SPAN
|
|
>, your MTA will pick
|
|
the route shown above and send the message to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ernie</SPAN
|
|
> with an envelope address of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert!moria!janet</SPAN
|
|
>.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
|
|
Building a <TT
|
|
CLASS="FILENAME"
|
|
>paths</TT
|
|
> file from the full Usenet maps is not
|
|
a very good idea, however. The information provided in them is usually rather
|
|
distorted and occasionally out of date. Therefore, only a number of major
|
|
hosts use the complete UUCP world maps to build their
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>paths</TT
|
|
> files. Most sites maintain routing information only
|
|
for sites in their neighborhood and send any mail to sites they don't
|
|
find in their databases to a smarter host with more complete routing
|
|
information. This scheme is called <I
|
|
CLASS="EMPHASIS"
|
|
>smart-host routing</I
|
|
>.
|
|
Hosts that have only one UUCP mail link (so-called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>leaf sites</I
|
|
>) don't do any routing of their own; they
|
|
rely entirely on their smart host.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="AEN14362"
|
|
>17.4.3. Mixing UUCP and RFC-822</A
|
|
></H2
|
|
><P
|
|
>The best cure for the problems of mail routing in UUCP networks so far is the
|
|
adoption of the domain name system in UUCP networks. Of course, you can't
|
|
query a name server over UUCP. Nevertheless, many UUCP sites have formed small
|
|
domains that coordinate their routing internally. In the maps, these domains
|
|
announce one or two hosts as their mail gateways so that there doesn't have to
|
|
be a map entry for each host in the domain. The gateways handle all mail that
|
|
flows into and out of the domain. The routing scheme inside the domain is
|
|
completely invisible to the outside world.</P
|
|
><P
|
|
>This works very well with the smart-host routing scheme.
|
|
Global routing information is maintained by the gateways only; minor hosts
|
|
within a domain get along with only a small, handwritten
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>paths</TT
|
|
> file that lists the routes inside their domain and
|
|
the route to the mail hub. Even the mail gateways do not need routing information for every single UUCP host in the world anymore. Besides
|
|
the complete routing information for the domain they serve, they only need to
|
|
have routes to entire domains in their databases now. For instance, this
|
|
pathalias entry will route all mail for sites in the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>sub.org</SPAN
|
|
> domain to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>smurf</SPAN
|
|
>:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>.sub.org swim!smurf!%s</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Mail addressed to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>claire@jones.sub.org</SPAN
|
|
>
|
|
will be sent to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>swim</SPAN
|
|
> with an envelope
|
|
address of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>smurf!jones!claire</SPAN
|
|
>.</P
|
|
><P
|
|
>The hierarchical organization of the domain namespace allows mail
|
|
servers to mix more specific routes with less specific ones. For
|
|
instance, a system in France may have specific routes for subdomains
|
|
of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>fr</SPAN
|
|
>, but route any mail for hosts
|
|
in the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>us</SPAN
|
|
> domain toward some system
|
|
in the U.S. In this way, domain-based routing (as this technique is called)
|
|
greatly reduces the size of routing databases, as well as the administrative
|
|
overhead needed.</P
|
|
><P
|
|
>The main benefit of using domain names in a UUCP environment, however, is that
|
|
compliance with RFC-822 permits easy gatewaying between UUCP networks and the
|
|
Internet. Many UUCP domains nowadays have a link with an Internet gateway that
|
|
acts as their smart host. Sending messages across the Internet is faster, and
|
|
routing information is much more reliable because Internet hosts can use DNS
|
|
instead of the Usenet Maps.</P
|
|
><P
|
|
>In order to be reachable from the Internet, UUCP-based domains usually
|
|
have their Internet gateway announce an MX record for them (MX records
|
|
were described previously in the section <A
|
|
HREF="x-087-2-mail.routing.html#X-087-2-MAIL.ROUTING.INTERNET"
|
|
>Section 17.4.1</A
|
|
>”). For instance, assume that
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> belongs to the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>orcnet.org</SPAN
|
|
> domain.
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>gcc2.groucho.edu</SPAN
|
|
> acts as its Internet
|
|
gateway. <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> would therefore use
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>gcc2</SPAN
|
|
> as its smart host so that all
|
|
mail for foreign domains is delivered across the Internet. On the other hand,
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>gcc2</SPAN
|
|
> would announce an MX record for
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>*.orcnet.org</SPAN
|
|
> and deliver all incoming
|
|
mail for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>orcnet</SPAN
|
|
> sites to
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>. The asterisk in
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>*.orcnet.org</SPAN
|
|
> is a wildcard that
|
|
matches all hosts in that domain that don't have any other record associated
|
|
with them. This should normally be the case for UUCP-only domains.</P
|
|
><P
|
|
>The only remaining problem is that the UUCP transport programs can't deal
|
|
with fully qualified domain names. Most UUCP suites were designed to cope
|
|
with site names of up to eight characters, some even less, and using
|
|
nonalphanumeric characters such as dots is completely out of the question
|
|
for most.</P
|
|
><P
|
|
>Therefore, we need mapping between RFC-822 names and UUCP hostnames.
|
|
This mapping is completely implementation-dependent. One
|
|
common way of mapping FQDNs to UUCP names is to use the pathalias file:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>moria.orcnet.org ernie!bert!moria!%s</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This will produce a pure UUCP-style bang path from an address that specifies
|
|
a fully qualified domain name. Some mailers provide a special file for this;
|
|
<B
|
|
CLASS="COMMAND"
|
|
>sendmail</B
|
|
>, for instance, uses the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>uucpxtable</TT
|
|
>.</P
|
|
><P
|
|
>The reverse transformation (colloquially called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>domainizing</I
|
|
> ) is sometimes required when sending
|
|
mail from a UUCP network to the Internet. As long as the mail sender
|
|
uses the fully qualified domain name in the destination address, this
|
|
problem can be avoided by not removing the domain name from the
|
|
envelope address when forwarding the message to the smart
|
|
host. However, there are still some UUCP sites that are not part of
|
|
any domain. They are usually domainized by appending the pseudo-domain
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>uucp</SPAN
|
|
>.</P
|
|
><P
|
|
>The pathalias database provides the main routing information in
|
|
UUCP-based networks. A typical entry looks like this (site name
|
|
and path are separated by tabs):
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>moria.orcnet.org ernie!bert!moria!%s
|
|
moria ernie!bert!moria!%s</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This makes any message to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> be
|
|
delivered via <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>ernie</SPAN
|
|
> and
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert</SPAN
|
|
>. Both
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>'s fully qualified name and
|
|
its UUCP name have to be given if the mailer does not have a separate way to
|
|
map between these namespaces.</P
|
|
><P
|
|
>
|
|
|
|
If you want to direct all messages to hosts inside a domain to its
|
|
mail relay, you may also specify a path in the pathalias database,
|
|
giving the domain name preceded by a dot as the target. For example, if
|
|
all hosts in <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>sub.org</SPAN
|
|
> can be reached
|
|
through <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>swim!smurf</SPAN
|
|
>, the pathalias
|
|
entry might look like this:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>.sub.org swim!smurf!%s</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Writing a pathalias file is acceptable only when you are running a site
|
|
that does not have to do much routing. If you have to do routing for a
|
|
large number of hosts, a better way is to use the <B
|
|
CLASS="COMMAND"
|
|
>pathalias</B
|
|
>
|
|
command to create the file from map files. Maps can be maintained much more
|
|
easily, because you may simply add or remove a system by editing the system's
|
|
map entry and recreating the map file. Although the maps published by the
|
|
Usenet Mapping Project aren't used for routing very much anymore, smaller
|
|
UUCP networks may provide routing information in their own set of maps.</P
|
|
><P
|
|
>
|
|
|
|
|
|
A map file mainly consists of a list of sites that each system polls
|
|
or is polled by. The system name begins in the first column and is
|
|
followed by a comma-separated list of links. The list may be continued
|
|
across newlines if the next line begins with a tab. Each link
|
|
consists of the name of the site followed by a cost given in
|
|
brackets. The cost is an arithmetic expression made up of numbers and
|
|
symbolic expressions like DAILY or WEEKLY. Lines beginning with a hash
|
|
sign are ignored.</P
|
|
><P
|
|
>As an example, consider <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
>, which
|
|
polls <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>swim.twobirds.com</SPAN
|
|
> twice a day
|
|
and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert.sesame.com</SPAN
|
|
> once per week.
|
|
The link to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>bert</SPAN
|
|
> uses a
|
|
slow 2,400 bps modem. <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> would
|
|
publish the following maps entry:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>moria.orcnet.org
|
|
bert.sesame.com(DAILY/2),
|
|
swim.twobirds.com(WEEKLY+LOW)
|
|
moria.orcnet.org = moria</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The last line makes <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>moria</SPAN
|
|
> known
|
|
under its UUCP name, as well. Note that its cost must be specified as
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>DAILY/2</SPAN
|
|
> because calling
|
|
twice a day actually halves the cost for this link.</P
|
|
><P
|
|
>Using the information from such map files, <B
|
|
CLASS="COMMAND"
|
|
>pathalias</B
|
|
> is
|
|
able to calculate optimal routes to any destination site listed in the paths
|
|
file and produce a pathalias database from this which can then be used
|
|
for routing to these sites.</P
|
|
><P
|
|
> <B
|
|
CLASS="COMMAND"
|
|
>pathalias</B
|
|
> provides a couple of other features like
|
|
site-hiding (i.e., making sites accessible only through a gateway). See
|
|
the <B
|
|
CLASS="COMMAND"
|
|
>pathalias</B
|
|
> manual page for details and a
|
|
complete list of link costs.</P
|
|
><P
|
|
>Comments in the map file generally contain additional information on
|
|
the sites described in it. There is a rigid format in which to specify
|
|
this information so that it can be retrieved from the maps. For
|
|
instance, a program called <B
|
|
CLASS="COMMAND"
|
|
>uuwho</B
|
|
> uses a database
|
|
created from the map files to display this information in a nicely
|
|
formatted way. When you register your site with an organization that
|
|
distributes map files to its members, you generally have to fill out
|
|
such a map entry. Below is a sample map entry (in fact, it's the one
|
|
for Olaf's site):
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>#N monad, monad.swb.de, monad.swb.sub.org
|
|
#S AT 486DX50; Linux 0.99
|
|
#O private
|
|
#C Olaf Kirch
|
|
#E okir@monad.swb.de
|
|
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
|
|
#L 49 52 03 N / 08 38 40 E
|
|
#U brewhq
|
|
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
|
|
#
|
|
monad brewhq(DAILY/2)
|
|
# Domains
|
|
monad = monad.swb.de
|
|
monad = monad.swb.sub.org</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The whitespace after the first two characters is a tab. The meaning of
|
|
most of the fields is pretty obvious; you will receive a detailed
|
|
description from whichever domain you register with. The
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>L</SPAN
|
|
> field is the most fun to find out:
|
|
it gives your geographical position in latitude/longitude and is used to
|
|
draw the PostScript maps that show all sites for each country, as well as
|
|
worldwide.<A
|
|
NAME="X-087-2-FNMA07"
|
|
HREF="#FTN.X-087-2-FNMA07"
|
|
>[2]</A
|
|
></P
|
|
></DIV
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNMA06"
|
|
HREF="x-087-2-mail.routing.html#X-087-2-FNMA06"
|
|
>[1]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>Maps for sites registered with the UUCP Mapping Project are distributed
|
|
through the newsgroup <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>comp.mail.maps</SPAN
|
|
> ;
|
|
other organizations may publish separate maps for their networks.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNMA07"
|
|
HREF="x-087-2-mail.routing.html#X-087-2-FNMA07"
|
|
>[2]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>They are posted regularly in
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>news.lists.ps-maps</SPAN
|
|
>.
|
|
Beware. They're HUGE.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-mail.address.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-mail.elm.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Email Addresses</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-mail.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>Configuring elm</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |