Summary

  • RFC 1465 turned X.400 community, domain, relay, contact, network, protocol, priority and validity information into a common table format while directory-based routing was not yet ready.
  • Its START date scheduled when a declaration should apply; local receipt, installation, address validation, connection, message custody and final delivery remained separate evidence.

The table existed because the network did not offer one uniform road.

An X.400 Message Transfer Agent might speak TP0 over X.25, TP4 over CLNS, or RFC 1006 over TCP/IP. Supporting the same stack was not enough: two machines also had to be on interconnected networks. Some destinations would not accept a connection from an unregistered peer. A manager therefore needed more than an address. The manager needed a route through a community of relays, each with known connection methods and administrative agreements.

RFC 1465, published as Experimental in May 1993, proposed a short-term answer. It expected X.500 directory routing eventually to hold and distribute this information. Until that future arrived, a common document format would let the international X.400 community maintain static routes and use multi-stack MTAs as relays.

Four files made one control plane

The format divided responsibility among four document types. A COMMUNITY document named the community, its coordination point, its document server and the accepted network/stack vocabulary. A RELAY-MTA document described a relay’s connection details. A DOMAIN document mapped an X.400 address subtree to a responsible person and one or more relays. PERSON documents supplied contacts.

Those links were operationally useful precisely because they were not one object. A relay key could include management-domain components merely to make the string unique; RFC 1465 warned that the result was a key, not an address. A person key could be an O/R address or a directory name. A domain record could name a primary relay without making the relay the domain, the administrator or the recipient.

The community’s coordinator controlled a shared vocabulary and served the documents. Domain managers supplied route declarations. Relay managers configured connections. Local operators still had to convert the distributed record into working software state. The table linked their responsibilities but did not collapse them.

START was advance notice, not a health check

Every document carried an update date and a mandatory start date; an end date was optional. RFC 1465 explicitly allowed publication before the start date. Without automated tools, relay managers needed time to prepare their systems.

That was a subtle and powerful feature. A future-valid route could be reviewed and distributed before a cutover. But it made the evidentiary boundary unavoidable. The source file could say START=930201 while one site had installed it, another had only received it and a third had not seen it. Once the date arrived, the declaration was valid according to the document. The RFC did not create a distributed acknowledgement proving that every local MTA was ready.

An optional end date had the same limit in reverse. It expressed expiry in the record. Whether an old entry disappeared from every generated table required evidence from each installation. Six years later, RFC 2626’s audit appendix found RFC 1465’s two-digit yymmdd tokens. That scanner result identifies an interpretation risk; it does not establish that any deployed relay mishandled the millennium.

Priority chose the next attempt

RFC 1465 gave relays priorities and distinguished primary from secondary service. The routing procedure selected matching domains, considered reachability, preferred primary relays and higher priorities, then selected a service type. If a connection failed, the sender could try another service and then another relay. With no alternative, it retried the chosen relay.

This is a decision tree, not a receipt. “Primary” described the relay’s role in the community. A priority ranked choices. Neither field measured current load, current uptime or acceptance of this message. Even the word “reachable” appeared at different layers: the document contained contact hours for people, connection information for machines and a routing procedure that still had to encounter live network state.

The RFC asked communities to define update procedures and cautioned that automated updates needed careful study. It also warned that many relays imposed substantial work: local routing tables had to remain current and connections had to be monitored continuously. Redundancy could improve robustness, but only if the alternatives were configured and functioning.

A lower-layer change could invalidate a stable record

The most concrete failure boundary appears in the called and calling addresses. Some X.400 systems validated the network address presented by the caller. RFC 1465 noted that an X.25 switch reconfiguration could change that calling address and stop a relay from connecting to peers, even though nothing at higher layers had changed.

The domain name, relay key, priority and service label could all remain identical. The real connection would still fail because a lower-layer observation no longer matched the peer’s installed validation state.

Optional fields reveal how operators were expected to close that gap. Hardware and software details could help diagnose communication problems if kept current. A local-domain address with a nonexistent user could support connectivity tests. An echo server could support availability tests. These were observations performed against the service; they were not properties automatically proved by the route document.

Later documents named the scaling problem

RFC 1649 retained the same operational setting in 1994. Without a well-deployed directory, X.400 routing used static tables keyed by destination O/R addresses. A complete table for every MTA would be too large and change too quickly, so relay MTAs reduced the distribution burden. RFC 1711 then classified GO-MHS as an operational X.400 service using mostly static, community-wide table rules and indirect routing.

Neither document supplies a global adoption denominator or a delivery ledger. They show that the arrangement belonged to an operating service, not that every participant held consistent state.

In 1995, RFC 1802 made the gap explicit. Centrally maintained and advertised tables had been optimised as far as possible, it said, but did not scale; manual propagation and installation could not guarantee consistency among MTAs scattered around the world. Project Long Bud proposed migration to X.500-based routing. Directory-capable MTAs would read routes directly, while tools would continue generating static tables for older MTAs.

The migration plan did not erase the evidence problem. It required participants to register, test connection information with another participant, preserve default routes, keep directory data accurate and announce new routes after testing. The RFC recorded a small initial set of operational MTAs, while describing the larger effort as a proposed pilot without large-scale resources committed. RFC 1801 supplied the longer-term technical design and goals; neither text proves a completed global transition.

From declaration to delivery, seven receipts

An auditable route change would need at least seven linked records: the coordinator’s accepted document and hash; its publication time and validity window; each manager’s retrieval; each MTA’s generated or installed table; a live match on network, stack and address validation; the selected connection and custody response; and the final delivery or non-delivery result.

RFC 1465 supplied a disciplined grammar for the first part of that chain. Its historical achievement was to make administrative intent portable across incompatible networks. Its historical warning is just as useful: a portable declaration remains a declaration until running systems answer it.