Summary

  • RFC 1429 described BITNET LISTSERV's DISTRIBUTE service sending one message copy over a heavily loaded link, then splitting delivery closer to recipients where topology information permitted. The author reported 2–6 million messages a day through the system in February 1993.
  • The operator checklist required a nearby entry site, compatible mail handling, a master-nodes file no older than two months and permission for workloads above 10,000 daily recipients. A fast backbone was only as good as the map and the people maintaining it.

The clever part of a large mailing list was sending less mail. In RFC 1429, Eric Thomas described a DISTRIBUTE request: hand one server the recipient list and the message, then let the BITNET LISTSERV backbone carry a single copy across heavily loaded links and split it near the destination clusters. He reported 2–6 million messages a day moving through that machinery. A list owner could borrow the machinery without operating the whole backbone.

But the first decision had to happen before the job card was written: which server should receive the request? Thomas offered a blunt example. Sending a California list to a Swedish server would be absurd if most readers were in the United States. The sender needed a nearby, well-connected DISTRIBUTE site. A campus could have T1 IP access and still reach BITNET through a 9.6-kilobit leased line. The fast scheme could begin with the wrong bottleneck.

The operator also needed a map fit for the day. RFC 1429 told senders to verify that the site's Master nodes file was no more than two months old. Some sites, Thomas wrote, failed to update their tables because of staffing shortages. That was the hidden dependency in the elegant one-copy story. Topology knowledge told the backbone where to aggregate work; stale knowledge could send it down a poor path. The RFC tied performance mainly to the quality and accuracy of that information, with system load as another factor.

The mail wrapper separated a few jobs that an ordinary list could confuse. The SMTP MAIL FROM address should reach a human able to handle failure to reach the server. Inside the submitted mail, the RFC822 From field should receive later delivery problems and bounces. Put the list's submission address there and the failures could loop back into the list. The protocol did not make accountability automatic; the operator had to place the right mailbox at each boundary.

Inside the request came a JOB card, DISTRIBUTE MAIL, a recipient list marked BSMTP, and finally the message. In production, ECHO=NO suppressed a resource-usage report. For testing, DEBUG=YES showed how recipients would be routed without delivery; TRACE=YES reported the routing while delivering. The RFC printed a worked debug trace: three recipients forwarded through one LISTSERV site at UGA, two posted locally. It was a view of a proposed distribution path, not a receipt that five humans read the mail.

The numbers were specific to the author's 1993 account. The memo gave 5–15 minutes as typical turnaround for reasonably connected BITNET recipients and 5–20 minutes for Internet destinations that could be handed near their organizations. Destinations with no topology information could take much longer. It told senders expecting more than 10,000 recipients a day to ask the local LISTSERV administrator for permission and discuss restrictions or scheduled downtime. Technical capacity had a named local owner.

That is why the two-month file check matters more than the boast about millions of messages. The service moved duplication away from every list sender and toward a shared, topology-aware network. Its map, entry point, line capacity and administrators decided whether the shortcut was real. An old map could preserve the appearance of a fast distribution system while quietly moving the cost back onto the wrong link.