Summary

  • Mary Ann Horton helped organize the UUCP Mapping Project, which converted volunteered descriptions of dial-up neighbours into published data that each site could use to calculate mail routes.
  • The system worked because mapping, routing, gateway translation and naming were treated as separate responsibilities; its own records also show why stale maps, hidden costs and concentrated relay work could not be ignored.

A route such as duke!research!ucbvax!user asked more of its sender than a modern address does. It named a destination, but it also carried a theory of how to reach it. The route was relative to the sender, dependent on machines continuing to call one another, and exposed to every change in a network whose links were negotiated by administrators and paid for through telephone bills.

Mary Ann Horton’s contribution was not to make those constraints disappear. It was to help turn them into a maintainable public process.

When a drawing stopped being a routing system

In her 2020 USENIX interview, Horton recalled handing out logical Usenet maps at conferences in 1982 and 1983. People seized on them to route email, although Usenet’s news distribution and the broader UUCP mail network were not the same thing. The distinction mattered: a diagram of news links could omit a useful mail connection and push more traffic toward the few sites generous enough to relay it.

Growth defeated the picture. Horton said the logical network had become too branchy by 1984; a geographic map and an eight-page logical map followed, but neither could serve as a continuously updated route table. The problem was no longer artistic. It was administrative: who would report a neighbour, correct an error, price a link and publish the next version?

A USENIX birds-of-a-feather meeting in January 1984 organized the answer as the UUCP Mapping Project. Regional volunteers gathered site descriptions and connection data, reviewed them and posted updates to comp.mail.maps. A retrospective museum account says the meeting enlisted more than 30 volunteers; Horton’s accomplishments page describes a team of about 50. Later accounts cover a wider circle. Those figures describe different moments, not one auditable headcount.

The record also resists a lone-founder story. Horton’s own history says she convened the meeting and led the project’s creation. A 2000 project-conclusion draft credits Karen Summers-Horton with initial leadership under USENIX funding and says Horton ran the project from 1985 until its registration and software-distribution functions closed in 1988. The useful fact is the distributed institution they and many regional maintainers built, not a single heroic title.

Publishing enough topology, but not the secrets

The information boundary was explicit. RFC 850 described a senduuname request that could collect the names of a site’s UUCP neighbours for routing maps. It allowed an administrator to edit the reply. It also warned that the private dialing file must not be sent and that public responses must exclude telephone numbers and passwords.

That is an early version of a problem still present in infrastructure registries: discovery requires disclosure, but operations require secrets. A useful map had to expose adjacency without exposing credentials. Its legitimacy depended on both being true at once.

The map did not discover reality automatically. Administrators decided what to submit. Regional maintainers resolved contradictions. Publication through Usenet distributed a common set of claims, but every claim carried an age and an owner even when the data format did not make those qualities prominent.

A shortest path built from human judgements

Steve Bellovin and Peter Honeyman wrote pathalias, the program that consumed connectivity descriptions. Their paper models the network as a directed graph. Each connection receives a non-negative cost and a routing operator, and a Dijkstra-style calculation produces a least-cost path from the local site to every known destination.

“Least cost” sounds objective until the paper lists what cost might mean. Telephone charge was one input. So were call frequency, transmission speed, reliability and the tendency of experienced operators to prefer one path over another. Corporate and university budgets differed. Some sites dialed out; others waited to be called. Setup time and hours between calls could matter more than nominal line speed.

The metric was therefore a compact policy. It translated economic burden and operating experience into numbers that software could compare.

The authors were unusually candid about the limits. Early submissions were incomplete, contradictory and error-filled. Inferred news maps could understate connectivity and overload cooperative sites. Some reverse links were inferred for hosts that otherwise appeared unreachable. An optimizer could even undo a sender’s deliberate detour around a dead link. The output was a useful local view, not a neutral photograph of the network.

Horton and Adam Buchsbaum worked on smail, which used those local tables to send mail without forcing every user to memorize a bang path. This division of labour was crucial: the shared publication described possible connections; pathalias evaluated them from one site; the mailer executed the choice; administrators still carried the consequences.

A domain was a name, not a hidden route

The next simplification was conceptual. In “What Is a Domain?”, Horton stressed that dots do not specify a sequence of machines. A domain is an absolute name inside an administrative hierarchy. A mail system still needs a table, resolver or gateway to decide the next hop.

RFC 819 made the same contrast. Domains distribute naming authority and responsibility for translation; UUCP source routes remain relative to where the sender stands. RFC 920 went further: a domain is an administrative entity, not a shared topology, protocol, hardware platform or geography.

Horton’s retrospective says the UUCP Project joined BITNET, CSNET and the ARPANET community in the 1986 move toward a shared namespace and provided .com and .edu mail service to more than 150 organizations that did not have direct Internet connections. That number belongs to her record, not an independent census. The architectural point is firmer: a stable public name could front an uneven mix of UUCP, SMTP and gateways.

RFC 976 formalized that accommodation. Rather than invent another incompatible mail family, it adopted the Internet’s domain and message formats for the UUCP zone, classified hosts by capability and required gateways to handle the more capable form. Its worked routes show that user@domain was simpler for a person precisely because a gateway and a table now carried the complexity.

RFC 974’s MX records pushed the indirection further. A domain could identify preferred mail exchangers, and an administrator could change the database to route around a defective host. Stable naming did not eliminate route management. It moved that work into reusable infrastructure.

The map’s ending was part of its design

The UUCP Project’s 2000 conclusion draft says its database was frozen that August because the maps were no longer widely used. It warns that stale data could lose or misdeliver mail and tells remaining users to find alternatives. The document never became an RFC, so it is evidence of the project’s own retirement process, not an adopted Internet standard.

That warning completes Horton’s story. A map does not remain authoritative because a file survives. It remains authoritative while named people accept changes, resolve disputes, publish fresh state and announce when the service should no longer be trusted.

Today, topology and discovery systems are far faster than comp.mail.maps. Their institutional problem is recognizable. A connection is an observation. A route is a decision. A name is a promise of continuity. Keeping the three aligned still requires somebody to publish what changed — and somebody accountable for saying when the map is no longer the territory.

Sources

  1. Wikimedia Commons: Mary Ann Horton 2012 portrait
  2. The Conclusion of the UUCP Mapping Project, Internet-Draft
  3. UC Berkeley EECS profile
  4. Mary Ann Horton: accomplishments
  5. Mary Ann Horton: Internet history
  6. Stargate Internet Museum: The UUCP Project
  7. Stargate Internet Museum: UUCP and email
  8. Pathalias: The Care and Feeding of Relative Addresses
  9. Mary Ann Horton: What Is a Domain?
  10. RFC 1036: Standard for Interchange of USENET Messages
  11. RFC 819: The Domain Naming Convention for Internet User Applications
  12. RFC 850: Standard for Interchange of USENET Messages
  13. RFC 920: Domain Requirements
  14. RFC 974: Mail Routing and the Domain System
  15. RFC 976: UUCP Mail Interchange Format Standard
  16. USENIX interview with Mary Ann Horton