X.400

X.400 es un conjunto de recomendaciones de la UIT-T que definen el Sistema de Gestión de Mensajes (MHS) de la UIT-T. En su momento, los diseñadores de X.400 esperaban que fuera la forma predominante de correo electrónico, pero este papel lo ha asumido el correo electrónico de Internet basado en SMTP . ^{[ 1 ]} A pesar de ello, se ha utilizado ampliamente dentro de las organizaciones y fue una parte fundamental de Microsoft Exchange Server hasta 2006; sus variantes siguen siendo importantes en contextos militares y de aviación.

A principios de la década de 1980 se exploraron cuestiones de diseño de protocolos para correo electrónico. ^{[ 2 ]}

Las primeras Recomendaciones X.400 se publicaron en 1984 ( Libro Rojo ), y una versión sustancialmente revisada se publicó en 1988 ( Libro Azul ). Se añadieron nuevas características en 1992 ( Libro Blanco ) y en actualizaciones posteriores. Aunque X.400 se diseñó originalmente para funcionar sobre el servicio de transporte OSI , una adaptación para permitir su funcionamiento sobre TCP/IP , RFC 1006, se ha convertido en la forma más popular de ejecutar X.400.

Desarrolladas en colaboración con ISO / IEC , las recomendaciones de la serie X.400 especifican los protocolos estándar OSI para el intercambio y el direccionamiento de mensajes electrónicos. Las recomendaciones complementarias de la serie F.400 definen los servicios de gestión de mensajes basados ​​en sistemas de gestión de mensajes (MHS), así como el acceso a los MHS para los servicios públicos. A finales de la década de 1990, la UIT-T consolidó las recomendaciones F.400 y X.400 y publicó la recomendación UIT-T F.400/X.400 (06/1999) «Descripción general de los sistemas y servicios de gestión de mensajes».

Las recomendaciones de la serie X.400 definen los aspectos técnicos del MHS: la recomendación ITU-T X.402 ( ISO / IEC 10021-2) define la arquitectura general del sistema MHS, la recomendación ITU-T X.411 ( ISO / IEC 10021-4) define el Servicio de Transferencia de Mensajes (MTS) y su componente funcional, el Agente de Transferencia de Mensajes (MTA) , y la recomendación ITU-T X.413 ( ISO / IEC 10021-5) define el Almacén de Mensajes. Todas las recomendaciones de la ITU-T proporcionan términos específicos para describir las entidades y los procedimientos del sistema. Por ejemplo, los mensajes (correo electrónico) intercambiados entre personas se denominan Mensajería Interpersonal (IPM); los documentos comerciales estructurados electrónicamente (por ejemplo, facturas, órdenes de compra, avisos de envío, etc.) intercambiados entre los ordenadores de los socios comerciales se rigen por los protocolos de Intercambio Electrónico de Datos (EDI) .

El procesamiento de mensajes es una tarea de procesamiento de información distribuida que integra dos subtareas relacionadas: la transferencia y el almacenamiento de mensajes. Las Recomendaciones de la UIT-T definen protocolos específicos para una amplia gama de tareas de comunicación. Por ejemplo, el protocolo P1 se utiliza explícitamente para la comunicación entre MTA , el P3 entre el agente de usuario y un MTA, y el P7 entre el agente de usuario y el almacén de mensajes.

En la versión de 1994, P7 se mejoró para proporcionar carpetas en el almacenamiento de mensajes, permitir el almacenamiento de los mensajes enviados y ofrecer muchas acciones automáticas, como la organización automática en carpetas y la correlación de respuestas, informes de entrega y notificaciones de recepción con los mensajes enviados.

Los estándares de contenido de mensajes X.400 se definen para la comunicación entre agentes de usuario. Estos se modelan como protocolos conceptuales que tratan a P1 y P3/P7 como un transporte subyacente confiable de contenidos de mensajes. El estándar de contenido de mensajes para mensajería interpersonal, IPM, definido en la Recomendación ITU-T X.420 | ISO/IEC 10021-7, se denominó P2 en el Libro Rojo. La versión extendida de IPM en el Libro Azul recibió el tipo de contenido 22 (para P2 versión 2) y a menudo se la conoce informalmente como P22, aunque ese término no se usa en los estándares. El estándar de contenido de mensajes para EDI se define en las Recomendación ITU-T F.435 | ISO/IEC 10021-8 y ITU-T X.435 | ISO/IEC 10021-9, y se la conoce informalmente como P35. Un tipo de contenido de mensajería de voz se define en las Recomendación ITU-T F.440 y X.440.

Exchange Server 2007 no utiliza el objeto MTA, y el conector X.400 (que debe utilizar el MTA) ha desaparecido en Exchange Server 2007. Ya no existen direcciones de correo electrónico proxy predeterminadas X.400 en Exchange Server 2007. ^{[ 3 ]}

Entre las características importantes de X.400 se incluyen el direccionamiento estructurado, el código binario ASN.1 que permite el contenido multimedia (anterior y más eficiente que MIME ) y capacidades de seguridad integradas. Dado que la UIT asumió que los servicios de retransmisión entre dominios X.400 serían gestionados por PTT , X.400 incorporó campos para la transferencia automatizada de mensajes entre X.400 y otros servicios PTT, como télex , fax y correo postal físico. Posteriormente, la ISO añadió estándares de enrutamiento abiertos (Recomendación UIT-T X.412 | ISO/IEC 10021-10 y Recomendación UIT-T X.404 | ISO/IEC 10021-11), pero la idea errónea inicial de que X.400 requería servicios de retransmisión PTT, junto con los cargos por volumen de PTT para estos, fueron factores que inhibieron la adopción generalizada de X.400.

Desde finales de la década de 1980, muchos países importantes se comprometieron con la pila OSI, a través de GOSIP ( Perfiles de Interconexión de Sistemas Abiertos Gubernamentales ) . En Estados Unidos, esto se materializó en el Estándar Federal de Procesamiento de Información (FIPS #146) del NIST de 1990. A su vez, los principales proveedores de computadoras se comprometieron a producir productos compatibles con OSI, incluido X.400. El servidor Exchange de Microsoft se desarrolló en este período y se basó internamente en X.400/X.500, con la versión inicial que indicaba que podía enviar mensajes mediante la API de mensajería (MAPI), X.400 o el Protocolo simple de transferencia de correo (SMTP) . ^{[ 4 ]} Sin embargo, en la práctica, la mayoría de estos productos eran de mala calidad y rara vez se ponían en funcionamiento.

En Norteamérica, muchos contratistas de defensa y universidades ya se habían comprometido con los estándares de Internet y TCP/IP , incluido SMTP para el correo electrónico. Allí, X.400 todavía se usa en algunas aplicaciones, como en el ámbito militar, los servicios de inteligencia y la aviación, principalmente porque el protocolo X.400 admite cifrado y sus funciones de integridad y seguridad se desarrollaron e implementaron mucho antes que sus contrapartes SMTP ( S/MIME , PGP y SMTP-TLS). Por razones similares, a veces se usa para la transmisión de mensajes EDI entre aplicaciones.

En Europa, Sudamérica y Asia, el estándar X.400 está bastante extendido , especialmente para servicios EDI.

X.400 se ha extendido para su uso en aplicaciones militares (véase Sistema de gestión de mensajes militares ) y en aviación (véase Sistema de gestión de mensajes aeronáuticos) . Además, la OTAN utiliza STANAG 4406 como estándar para la mensajería militar basada en X.400. ^{[ 5 ]}

Uno de los problemas principales que X.400 intentó solucionar fue el fallo en la entrega de un correo electrónico cuando la dirección no estaba especificada correctamente. En aquel entonces, los formatos de direccionamiento variaban de una plataforma a otra, por lo que a los usuarios les resultaba difícil saber cómo escribirlos correctamente. Cualquier error provocaba que la entrega fallara por completo. Esto contrastaba con el servicio postal "real", donde incluso las direcciones incompletas se enviaban a una oficina de correos no entregados , donde intentaban entregar el correo aunque faltara información o esta fuera incorrecta. ^{[ a ]}

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.^[8]

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

• Mailbox identification – either the originator or recipient.
• Global domain identification – where a given mailbox is located.
• 1984 defined an OR address as an X.400 address that identified where the user is located.
• 1988 defines it as a combination of a directory name (distinguished name) and an X.400 address.^[9]

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

• C (Country name)
• DC (Domain Component)
• ADMD (Administration Management Domain, short-form A), usually a public mail service provider
• PRMD (Private Management Domain, short-form P)
• O (Organization name)
• OU (Organizational Unit Names), OU is equivalent to OU0, can have OU1, OU2...
• G (Given name)
• I (Initials)
• S (Surname)

Las normas originales no especificaban cómo debían escribirse estas direcciones de correo electrónico (por ejemplo, en una tarjeta de visita), ni siquiera si los identificadores de campo debían estar en mayúsculas o minúsculas, ni qué conjuntos de caracteres estaban permitidos. El RFC 1685 especificaba una codificación, basada en un borrador de 1993 de la Recomendación F.401 de la UIT-T, que tenía el siguiente aspecto:

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

En 1984 existían dos formatos de dirección:

• Formulario 1: (con 3 variantes)  – utiliza principalmente ADMD y un subconjunto de otros atributos.
• Forma 2: (sin variantes)  – identifica a los usuarios mediante direcciones de terminales telemáticas (hardware). ^{[ 10 ]}

En las Recomendaciones X.400 de 1988, se definieron cuatro formas de direccionamiento. El formato Formulario 1, Variante 1 de 1984 pasó a denominarse dirección O/R mnemotécnica, y los formatos Formulario 1, Variante 3 y Formulario 2 de 1984 se combinaron y se denominaron dirección O/R terminal. Se introdujeron nuevos formatos: el formulario O/R numérico (una variación del Formulario 1, Variante 2) y la dirección O/R postal.

El primer uso a gran escala se llevó a cabo en Estados Unidos en el marco de un contrato de comunicaciones militares entre 1992 y 1997.

• X.500
• ASN.1
• Normalización
• Organización de normalización
• Unión Internacional de Telecomunicaciones (UIT)
• Comisión Electrotécnica Internacional (IEC)
• Organización Internacional de Normalización (ISO)
• Intercambio electrónico de datos (Estándar ANSI)
• Sistema de gestión de mensajes (protocolo de correo electrónico de Novell no relacionado)

• RFC 1615 - Migración de X.400(84) a X.400(88)
• RFC 1649 - Requisitos operativos para los dominios de gestión X.400 en la comunidad GO-MHS

• Betanov, Cemil (1993). Introducción a X.400 . Boston: Artech House. ISBN 0-89006-597-7.
• Radicati, Sara (1992). Correo electrónico: Introducción a los estándares de gestión de mensajes X.400 . McGraw-Hill. ISBN 0-07-051104-7.
• Rhoton, John (1997). X.400 y SMTP . Elsevier. ISBN 1-55558-165-X.

• Preguntas frecuentes sobre la norma X.400 de Harald T. Alvestrand : una lista completa de recursos sobre la serie de normas X.400 (última actualización: 1995).