Summary
- RFC 1664, published in August 1994 as an Experimental RFC, proposed DNS PX records to distribute templates that gateways could use to map X.400 and RFC 822 addresses.
- PX described address correspondence. SMTP MX records handled mail routing; neither PX nor the RFC proves that a message was delivered or that the proposal was widely deployed.
A directory for translation, not transport
An X.400 address and an RFC 822 mailbox could refer to the same recipient while expressing that identity in different forms. A gateway between the systems needed a rule for translating one form into the other. The awkward part was not carrying the message across the gateway; it was keeping the mapping data consistent wherever gateways used it.
RFC 1327 had already specified the wider mapping framework. Its global tables included rules for mapping RFC 822 domains and X.400 organisational units, with longest-match behavior helping a gateway choose a relevant entry. RFC 1664 proposed a distribution mechanism for that kind of mapping information: a new DNS resource record called PX, with type code 26. Its preference and mapping fields let a gateway retrieve candidate correspondences and apply them locally.
That distinction mattered because DNS already had a mail-routing record. RFC 1664 says SMTP routing uses MX; PX supplements that information by describing address mappings. A PX answer was not the message, a route for its next SMTP hop, or a receipt from the recipient’s system. The gateway still had to perform the conversion and handle delivery under the relevant mail protocols.
The proposal grew out of a limited experiment, not a demonstrated global service. The RFC reports that some of its authors had tried storing mapping data in .it PTR records and found the test useful for a few applications. It also identifies deployment costs: DNS name servers needed modifications to support a new record type, and the Internet’s heterogeneous installations meant changes would take time. The document discusses a gradually distributed X.400 naming tree and anticipates separate deployment guidance; those passages describe a plan, not evidence that it was completed.
RFC 1664 labels itself Experimental and says it is not an Internet standard. RFC 2163 later obsoleted it with a MIXER-oriented mapping proposal. That sequence establishes a later specification, not broad adoption of PX. RFC 1649’s contemporaneous management guidance makes the operational burden visible: gateways participating in the X.400/Internet service needed globally consistent mapping tables and coordination. The record’s historical significance is therefore a design problem made explicit—how to distribute shared translation rules—rather than proof that DNS became a universal X.400 directory.
Sources
- RFC 987 — Mapping between X.400 and RFC 822
- RFC 1327 — Mapping between X.400(1988) and RFC 822
- RFC 1649 — Operational requirements for X.400 management domains
- RFC 1664 — Using the Internet DNS to distribute RFC 1327 mail address mapping tables
- RFC 2156 — MIXER: Mapping between X.400 and RFC 822
- RFC 2163 — Using the Internet DNS to distribute MIXER conformant global address mapping
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
