When sending mail to a host in a UUCP environment, simply knowing the
user and hostname might not be enough: When you are in Europe
and want to send a message to a person in the United States - how
should the intermediate sites know where to forward the message to?
In earlier times, the solution was the so-called bang path, being a list
of hosts through which to forward the message, separated by exclamation
marks (`!') and followed by the user's name.
To send a letter to Janet User on a machine named
moria, you would have used the path eek!foo!bar!swim!moria!janet.
This would have sent the mail from your host to eek, from there on
to foo, and so on, until it finally reached moria.
The number of machines to traverse before reaching the destination
host is usually referred to as the number of network hops.
This technique is called source routing, because it leaves the
responsibility of finding a route to the recipient with the sender.
This is very different from the way we have seen IP handle routing, where
the actual routing decisions are made by the forwarding
host.
The obvious drawback of source routing is that it requires you to remember much about the network topology, fast links, etc. Second, changes in the network topology - like links being deleted or hosts being removed - may cause messages to fail simply because you weren'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. One thing, however, that made the use of source routing necessary was the presence of ambiguous hostnames: For example, if there are two sites named moria, one in the U.S., and one in France. Which site now does moria!janet refer to? This can be made clear by specifying what path to reach moria through.
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 Usenet Maps, which are distributed regularly through Usenet.
Using the connectivity information provided in the maps, smart mail software relieves the sender of the message from finding a path to the recipient host. You only give it the destination address as moria!janet or janet@moria.uucp, and using the maps, it is able to construct a path from your site to moria.
This is only a slight variation of source routing, and is sometimes called system routing. Now, the only effect of changes in the network is that the host's mail routing databases have to be updated. Usually, they are kept up-to-date by rebuilding them every time updated UUCP maps are published.
It is important to know that the bang path routes used by the mail software do not have to be strict, that is eek and foo from the above example are not required to be direct UUCP neighbors. This is called loose source routing, and only requires that the mail transport software on eek is able to find a route to foo. For example, eek might have a UUCP neighbor, ernie, which has a link to bert, which in turn is a neighbor of foo. The mailer on eek will then amend the path, so that after processing on eek, the message would be sent to ernie with a new recipient address of bert!foo!bar!swim!moria!janet.
A benefit of loose routing is that instead of complete paths, a path from a well-known site to the recipient site suffices. Well-known means, of course, that all hosts know how to route messages to this site. For example, uunet is frequently given as a starting point of routes. When you specify a path starting with uunet, the mail software will try to get the message to uunet, which will then route your message (or probably no-one will). For example, you could send your mail to uunet!moria!janet, and leave it to uunet to find a route to moria. Unnecessary to say that this method is highly inefficient.