X.400

Last updated

X.400 is a suite of ITU-T recommendations that define the ITU-T Message Handling System (MHS).

Contents

At one time, the designers of X.400 were expecting it to be the predominant form of email, but this role has been taken by the SMTP-based Internet e-mail. [1] Despite this, it has been widely used within organizations and was a core part of Microsoft Exchange Server until 2006; variants continue to be important in military and aviation contexts.

History

The first X.400 Recommendations were published in 1984 (Red Book), and a substantially revised version was published in 1988 (Blue Book). New features were added in 1992 (White Book) and subsequent updates. Although X.400 was originally designed to run over the OSI transport service, an adaptation to allow operation over TCP/IP, RFC 1006, has become the most popular way to run X.400.

Developed in cooperation with ISO/IEC, the X.400-series recommendations specify OSI standard protocols for exchanging and addressing electronic messages. The companion F.400-series of recommendations define Message Handling Services built on Message Handling Systems (MHS), as well as access to and from the MHS for public services. In the late 1990s, the ITU-T consolidated recommendations F.400 and X.400 and published the ITU-T F.400/X.400 (06/1999) recommendation "Message handling system and service overview".

The X.400-series recommendations define the technical aspects of the MHS: ITU-T Rec. X.402 | (ISO/IEC 10021-2) defines the overall system architecture of an MHS, ITU-T Rec. X.411 | (ISO/IEC 10021-4) defines the Message Transfer Service (MTS) and its functional component the Message Transfer Agent (MTA), and ITU-T Rec. X.413 | (ISO/IEC 10021-5) defines the Message Store. All ITU-T recommendations provide specific terms for descriptions of system entities and procedures. For example, messages (email) exchanged among people is referred to as Interpersonal Messaging (IPM); electronically structured business documents (e.g., invoices, purchase orders, dispatch advice, etc.) exchanged among trading partners’ computers fall under the EDI protocols.

Message handling is a distributed information processing task that integrates two related subtasks: message transfer and message storage. The ITU-T Recommendations define specific protocols for a wide range of communication tasks. For example, the P1 protocol is used explicitly for communication among MTAs, P3 between the user agent and an MTA, and P7 between the user agent and message store.

In the 1994 version, P7 was enhanced to provide folders in the message store, allow storage of submitted messages, and provide many automatic actions such as auto-foldering and correlation of replies, delivery reports and receipt notifications with submitted messages.

X.400 message content standards are defined for communication between user agents. These are modelled as conceptual protocols that treat P1 and P3/P7 as providing an underlying reliable transport of message contents. The message content standard for interpersonal messaging, IPM, defined in ITU-T Rec. X.420 | ISO/IEC 10021-7 was named P2 in the Red Book. The extended version of IPM in the Blue Book was given content-type 22 (for P2 version 2) and is often referred to informally as P22, although that term is not used in the standards. The message content standard for EDI is defined in ITU-T Rec. F.435 | ISO/IEC 10021-8 and ITU-T Rec. X.435 | ISO/IEC 10021-9, and informally referred to as P35. A voice messaging content type is defined in ITU-T Recs. F.440 and X.440.

Exchange Server 2007 does not use the MTA object, and the X.400 connector (which must use the MTA) is gone in Exchange Server 2007. There are no longer any X.400 default proxy e-mail addresses in Exchange Server 2007. [2]

Important features of X.400 include structured addressing, ASN.1 binary code enabling multimedia content (predating and more efficient than MIME), and integrated security capabilities. As X.400 inter-domain relay services were assumed by ITU to be run by PTTs, X.400 incorporated fields for the automated transfer of messages between X.400 and other PTT services, such as Telex, facsimile and physical postal mail. ISO later added open routing standards (ITU-T Rec. X.412 | ISO/IEC 10021-10 and ITU-T Rec. X.404 | ISO/IEC 10021-11), but the initial misconception that X.400 required PTT relay services, coupled with PTT volume-based charges for these, were factors that inhibited the widespread uptake of X.400.

Implementation

From the late 1980s, many major countries committed to the OSI stack, via GOSIP - Government Open Systems Interconnection Profiles. In the United States this was in the form of the 1990 NIST "Federal Information Processing Standard" (FIPS #146). In turn, major computer vendors committed to producing OSI-compliant products, including X.400. Microsoft's Exchange Server was developed in this time period, and internally based on X.400/X.500 - with the initial release "equally happy to dispatch messages via Messaging API (MAPI), X.400, or Simple Mail Transfer Protocol (SMTP)". [3] In practice however, most of these were poorly produced, and seldom put into operation.

In North America, many large defense contractors and universities had also already committed to the Internet and TCP/IP standards, including SMTP for email. There, X.400 is still used in some applications, such as the military, intelligence services and aviation, mainly because the X.400 protocol supports encryption, and its functions for integrity and security were developed and deployed much earlier than their SMTP counterparts (S/MIME, PGP and SMTP-TLS). For similar reasons, it is sometimes used for transmission of EDI messages between applications.

In Europe, South America, and Asia, X.400 is quite widely implemented[ citation needed ], especially for EDI services.

X.400 has been extended for use in military applications - see Military Message Handling System - and aviation - see Aeronautical Message Handling System.
Furthermore, NATO uses STANAG 4406 as a standard for Military Messaging based on X.400. [4]

Addressing

One of the core issues X.400 attempted to address was the failure of an email to be properly delivered when the address was not specified correctly. At the time, addressing formats varied from platform to platform, so it was difficult for users to know how to properly type them in. Any error caused the delivery to fail outright. This was in contrast to the "real" postal service, where even partial addresses would be routed to a dead letter office where they will attempt to deliver it even if some of the information is missing or wrong. [lower-alpha 1]

To solve this problem, the X.400 address scheme included several redundant fields that could be used to help deliver the message. For instance, there were separate fields for first and last name, as well as initials. The server was identified with multiple fields, including a company or organization name, as well as the country. The idea was that an address with a misspelt name of the company, for instance, would still contain enough information, the person's name and country, for the message to be properly routed.

At the time, it was believed that email would be provided by large service providers, often the national telephone companies. This meant that as long as the message reached the service provider, indicated by the "Administration Management Domain" (ADMD) portion of the address, the system would likely know of the user in question. As this service provider was likely national in scope, simply providing the right country code could be enough information to route the message properly.

However, this model fails when the email services are provided by the user's company or organization, or when the service provider is not known. In this case, there is no national-scale database of users and an improper organization name is enough to cause it to fail. This is the dominant model today, where companies use an internal server, or even more commonly, use a provider like Microsoft 365, or Gmail, which is invisible outside the organization, and even to the users. In this model, the ADMD is unknown or the same as the organization itself.

This multi-part addressing system also led to the format being complex; users were not sure which fields were important and tended to provide all that they could. This made trivial things, like printing the address on a business card or typing it into the email client more difficult than simpler systems like those found in SMTP. The unwieldiness of this addressing format is believed by many to be one factor in the lack of success of X.400. [6]

An X.400 address is technically referred to as an Originator/Recipient (OR) address. It has two purposes:

An X.400 address consists of several elements, including:

The standards themselves originally did not specify how these email addresses should be written (for instance on a business card) or even whether the field identifiers should be upper or lower case, or what character sets were allowed. RFC 1685 specified one encoding, based on a 1993 draft of ITU-T Recommendation F.401, which looked like:

"G=Harald;S=Alvestrand;O=Uninett;PRMD=Uninett;A=;C=no"

1984 had two forms for address formats:

In the 1988 X.400 Recommendations, four forms of addressing were delineated. The 1984 Form 1, Variant 1 format was renamed as the mnemonic O/R address and the 1984 Form 1, Variant 3 and Form 2 format were combined and renamed the terminal O/R address. New forms introduced were the numeric O/R form (a variation of Form 1, Variant 2) and the postal O/R address.

The first large-scale use was conducted in the U.S. under a military communication contract in 1992 to 1997.

X.500 directories

The confusion caused by the X.400 addressing format led to the creation of the X.500 standard for directory services. The idea was to create a hierarchical and standardized email address directory with replication and distribution functionality that allowed multiple organizations to produce a single public directory. For instance, each Administration Management Domain (service provider) could optionally upload their directory to a shared X.500 server, and then allow this database to be searched by the X.400 User Agents during email creation, thereby avoiding needing to know anything about the address other than the recipient's name and some sort of organizational name like a company. [9]

Unfortunately, the X.500 protocol proved to be every bit as complex and unwieldy as X.400, and this led to the creation of the Lightweight Directory Access Protocol, or LDAP, that standardized a simple subset of the X.500 protocols suitable for use by end-user software searching for addresses. LDAP is widely used in directory services like Microsoft's Active Directory. [9]

Additionally, the goal of providing a universal address database was fundamentally flawed by the time it was proposed. In the era of national telecommunications companies like British Telecom or France Télécom, people's names and phone numbers were considered public information and already collected into such directories in the form of the phone book. Extending this to email addresses seemed obvious.
However, this was simply not the case in the 1980s; at that time, email was often associated with business or government users, and those organizations treated their member addresses as valuable, or even confidential. There was no incentive for the organizations to share this data with the public. As RFC2693 put it, "imagine the CIA adding its directory of agents to a world-wide X.500 pool". [10]

See also

Notes

  1. In one famous example of postal service capability, a letter reached air-crash survivor Helen Klaben after being addressed only "To the woman that spent 45 days in the arctic". [5]

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

The Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services play an important role in developing intranet and Internet applications by allowing the sharing of information about users, systems, networks, services, and applications throughout the network. As examples, directory services may provide any organized set of records, often with a hierarchical structure, such as a corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number.

Within the Internet email system, a message transfer agent (MTA), or mail transfer agent, or mail relay is software that transfers electronic mail messages from one computer to another using the Simple Mail Transfer Protocol. In some contexts the alternative names mail server, mail exchanger, and MX host can be used to describe an MTA.

<span class="mw-page-title-main">OSI model</span> Model of communication of seven abstraction layers

The Open Systems Interconnection model is a conceptual model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

<span class="mw-page-title-main">X.25</span> Standard protocol suite for packet switched wide area network (WAN) communication

X.25 is an ITU-T standard protocol suite for packet-switched data communication in wide area networks (WAN). It was originally defined by the International Telegraph and Telephone Consultative Committee in a series of drafts and finalized in a publication known as The Orange Book in 1976.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

X.500 is a series of computer networking standards covering electronic directory services. The X.500 series was developed by the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T). ITU-T was formerly known as the Consultative Committee for International Telephony and Telegraphy (CCITT). X.500 was first approved in 1988. The directory services were developed to support requirements of X.400 electronic mail exchange and name lookup. The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) were partners in developing the standards, incorporating them into the Open Systems Interconnection suite of protocols. ISO/IEC 9594 is the corresponding ISO/IEC identification.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

FCAPS is the ISO Telecommunications Management Network model and framework for network management. FCAPS is an acronym for fault, configuration, accounting, performance, security, the management categories into which the ISO model defines network management tasks. In non-billing organizations accounting is sometimes replaced with administration.

The Common Management Information Protocol (CMIP) is the OSI specified network management protocol.

The Open Systems Interconnection protocols are a family of information exchange standards developed jointly by the ISO and the ITU-T. The standardization process began in 1977.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

<span class="mw-page-title-main">Microsoft Mail</span> Several Microsoft email products

Microsoft Mail was the name given to several early Microsoft e-mail products for local area networks, primarily two architectures: one for Macintosh networks, and one for PC architecture-based LANs. All were eventually replaced by the Exchange and Outlook product lines.

Message Handling System (MHS) is an important early email protocol developed by Action Technologies, Inc. (ATI) in 1986. Novell licensed it in 1988 then later bought it.

<span class="mw-page-title-main">RM-ODP</span> Reference model in computer science

Reference Model of Open Distributed Processing (RM-ODP) is a reference model in computer science, which provides a co-ordinating framework for the standardization of open distributed processing (ODP). It supports distribution, interworking, platform and technology independence, and portability, together with an enterprise architecture framework for the specification of ODP systems.

A mailbox is the destination to which electronic mail messages are delivered. It is the equivalent of a letter box in the postal system.

ISO/IEC 10021, Information technology – Message Handling Systems (MHS) is the ISO/IEC standard which defines the overall system and service of an MHS and serves as a general overview of MHS.

A mailbox provider, mail service provider or, somewhat improperly, email service provider is a provider of email hosting. It implements email servers to send, receive, accept, and store email for other organizations or end users, on their behalf.

References

  1. Ned Freed (13 July 2021). "Ticket #14". Emailcore (Mailing list). Retrieved 15 July 2021. X.400 has changed from "the mail system we'll all be using someday" to "only used in limited government/military cases, and even those are disappearing"
  2. How the Exchange Server 2007 Core Services Work Together
  3. Redmond, Tony (31 March 1997). "Microsoft Exchange Server 5.0 Smoothes the Rough Edges". IT Pro Today. Retrieved 22 December 2018.
  4. "STANAG 4406 Military Messaging" . Retrieved 3 November 2023.
  5. Klaben, Helen (1964). Hey, I'm Alive!. Hodder & Stoughton. OCLC   12628846.
  6. X400 Debate: Addresses are ugly
  7. A Practical Guide to X.400 Addressing by Roger K Mizumori ISBN   1-85032-210-4
  8. A Practical Guide to X.400 Addressing by Roger K Mizumori page 26 ISBN   1-85032-210-4
  9. 1 2 "X.500 and LDAP" (PDF). Collections Canada.
  10. Ellison, C.; Frantz, B.; Lampson, B.; Rivest, R.; Thomas, B.; Ylonen, T. (1999). "RFC2693". doi: 10.17487/RFC2693 .{{cite journal}}: Cite journal requires |journal= (help)

General references

Further reading

ITU-T X.400 Recommendations