X.400 es un conjunto de recomendaciones UIT-T que definen el Sistema de Manejo de Mensajes (MHS) UIT-T.
En un momento dado, los diseñadores de X.400 esperaban que fuera la forma predominante de correo electrónico, pero este papel ha sido asumido por el correo electrónico de Internet basado en SMTP . [1] A pesar de esto, se ha utilizado ampliamente dentro de las organizaciones y fue una parte central de Microsoft Exchange Server hasta 2006; las variantes siguen siendo importantes en contextos militares y de aviación.
A principios de los años 1980 se exploraron cuestiones de diseño de protocolos para el correo informático. [2]
Las primeras Recomendaciones X.400 se publicaron en 1984 ( Libro Rojo ), y en 1988 se publicó una versión sustancialmente revisada ( Libro Azul ). En 1992 se añadieron nuevas características ( Libro Blanco ) y en las actualizaciones posteriores. Aunque X.400 se diseñó originalmente para funcionar sobre el servicio de transporte OSI , una adaptación para permitir el funcionamiento sobre TCP/IP , RFC 1006, se ha convertido en la forma más popular de ejecutar X.400.
Desarrolladas en cooperación con ISO / IEC , las recomendaciones de la serie X.400 especifican los protocolos estándar OSI para intercambiar y direccionar mensajes electrónicos. Las recomendaciones de la serie F.400 que las acompañan definen los servicios de tratamiento de mensajes basados en sistemas de tratamiento de mensajes (MHS), así como el acceso a y desde los MHS para servicios públicos. A finales de los años 90, 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 del sistema y servicio de tratamiento de mensajes".
Las recomendaciones de la serie X.400 definen los aspectos técnicos del MHS: la Rec. UIT-T X.402 ( ISO / IEC 10021-2) define la arquitectura general del sistema de un MHS, la Rec. UIT-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 Rec. UIT-T X.413 ( ISO / IEC 10021-5) define el Almacén de Mensajes. Todas las recomendaciones UIT-T proporcionan términos específicos para las descripciones de las entidades y 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 las computadoras de los socios comerciales caen bajo los protocolos EDI .
El manejo de mensajes es una tarea de procesamiento de información distribuida que integra dos subtareas relacionadas: transferencia de mensajes y 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 , P3 entre el agente de usuario y un MTA, y P7 entre el agente de usuario y el almacenamiento de mensajes.
En la versión de 1994, P7 se mejoró para proporcionar carpetas en el almacén de mensajes, permitir el almacenamiento de mensajes enviados y proporcionar muchas acciones automáticas como carpetas automáticas y correlación de respuestas, informes de entrega y notificaciones de recepción con 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 proveedores de un transporte fiable subyacente de contenidos de mensajes. El estándar de contenido de mensajes para mensajería interpersonal, IPM, definido en la Rec. UIT-T X.420 | ISO/IEC 10021-7 se denominó P2 en el Libro Rojo. A la versión ampliada de IPM en el Libro Azul se le asignó el tipo de contenido 22 (para la versión 2 de P2) y a menudo se la denomina informalmente P22, aunque ese término no se utiliza en los estándares. El estándar de contenido de mensajes para EDI se define en la Rec. UIT-T F.435 | ISO/IEC 10021-8 y la Rec. UIT-T X.435 | ISO/IEC 10021-9, y se denomina informalmente P35. Un tipo de contenido de mensajería de voz se define en las Recs. UIT-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 hay direcciones de correo electrónico proxy X.400 predeterminadas 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 contenido multimedia (anterior y más eficiente que MIME ) y capacidades de seguridad integradas. Como la UIT asumió que los servicios de retransmisión entre dominios de X.400 debían ser administrados por los PTT , X.400 incorporó campos para la transferencia automática de mensajes entre X.400 y otros servicios PTT, como télex , fax y correo postal físico. Posteriormente, la ISO agregó estándares de enrutamiento abierto (ITU-T Rec. X.412 | ISO/IEC 10021-10 y ITU-T Rec. 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 basados en el volumen de PTT para estos, fueron factores que inhibieron la adopción generalizada de X.400.
Desde finales de los años 1980, muchos países importantes se comprometieron a adoptar la pila OSI, a través de GOSIP ( Government Open Systems Interconnection Profiles ) . En los Estados Unidos, esto se hizo en forma de la "Estándar federal de procesamiento de información" (FIPS #146) del NIST de 1990. A su vez, los principales fabricantes de computadoras se comprometieron a producir productos compatibles con OSI, incluido X.400. El servidor Exchange de Microsoft se desarrolló en este período de tiempo y se basó internamente en X.400/X.500; la versión inicial " también podía enviar mensajes a través de Messaging API (MAPI), X.400 o Simple Mail Transfer Protocol (SMTP) ". [4] Sin embargo, en la práctica, la mayoría de estos se produjeron de manera deficiente y rara vez se pusieron en funcionamiento.
En América del Norte, muchos grandes contratistas de defensa y universidades ya se habían comprometido con los estándares de Internet y TCP/IP , incluido SMTP para correo electrónico. Allí, X.400 todavía se utiliza en algunas aplicaciones, como el ejército, los servicios de inteligencia y la aviación, principalmente porque el protocolo X.400 admite el 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 utiliza para la transmisión de mensajes EDI entre aplicaciones.
En Europa, Sudamérica y Asia, X.400 está ampliamente implementado [ cita requerida ] , especialmente para servicios EDI.
El X.400 se ha ampliado para su uso en aplicaciones militares (véase Sistema de tratamiento de mensajes militares ) y en la aviación (véase Sistema de tratamiento de mensajes aeronáuticos ) .
Además, la OTAN utiliza el STANAG 4406 como estándar para la mensajería militar basada en el X.400. [5]
Uno de los problemas principales que X.400 intentó solucionar fue el de la imposibilidad de entregar correctamente un correo electrónico cuando la dirección no se especificaba correctamente. En ese momento, los formatos de direcciones variaban de una plataforma a otra, por lo que era difícil para los usuarios saber cómo escribirlas correctamente. Cualquier error hacía que la entrega fallara de plano. Esto contrastaba con el servicio postal "real", donde incluso direcciones parciales se enviaban a una oficina de correos muertos donde intentarían entregarla incluso si faltaba alguna información o era incorrecta. [a]
Para resolver este problema, el esquema de direcciones X.400 incluía varios campos redundantes que podían utilizarse para facilitar la entrega del mensaje. Por ejemplo, había campos separados para el nombre y el apellido, así como para las iniciales. El servidor se identificaba con varios campos, incluido el nombre de la empresa u organización, así como el país. La idea era que una dirección con el nombre de la empresa mal escrito, por ejemplo, aún contuviera suficiente información (el nombre de la persona y el país) para que el mensaje se enrutara correctamente.
En aquella época, se creía que el correo electrónico lo proporcionarían los grandes proveedores de servicios, a menudo las compañías telefónicas nacionales. Esto significaba que, siempre que el mensaje llegara al proveedor de servicios, indicado por la parte "Administration Management Domain" (ADMD) de la dirección, el sistema probablemente sabría quién era el usuario en cuestión. Como este proveedor de servicios probablemente tenía alcance nacional, simplemente proporcionar el código de país correcto podría ser suficiente información para enrutar el mensaje correctamente.
Sin embargo, este modelo falla cuando los servicios de correo electrónico son proporcionados por la empresa u organización del usuario, o cuando no se conoce el proveedor del servicio. En este caso, no existe una base de datos de usuarios a escala nacional y basta un nombre de organización inadecuado para que falle. Este es el modelo dominante en la actualidad, donde las empresas utilizan un servidor interno, o incluso más comúnmente, utilizan un proveedor como Microsoft 365, o Gmail , que es invisible fuera de la organización, e incluso para los usuarios. En este modelo, el ADMD es desconocido o es el mismo que la propia organización.
Este sistema de direcciones de varias partes también hizo que el formato fuera complejo; los usuarios no estaban seguros de qué campos eran importantes y tendían a proporcionar todo lo que podían. Esto hizo que cosas triviales, como imprimir la dirección en una tarjeta de visita o escribirla en el cliente de correo electrónico, fueran más difíciles que con sistemas más simples como los que se encuentran en SMTP. Muchos creen que la dificultad de manejo de este formato de direcciones es uno de los factores que explican la falta de éxito de X.400. [8]
Una dirección X.400 se denomina técnicamente dirección de origen/destinatario (OR). Tiene dos propósitos:
Una dirección X.400 consta de varios elementos, entre ellos:
Las propias normas originalmente no especificaban cómo debían escribirse estas direcciones de correo electrónico (por ejemplo, en una tarjeta de visita) o incluso si los identificadores de campo debían estar en mayúsculas o minúsculas, o qué conjuntos de caracteres estaban permitidos. La RFC 1685 especificó una codificación, basada en un borrador de 1993 de la Recomendación F.401 de la UIT-T, que parecía algo así:
En 1984 había dos formas de formatos de dirección:
En las Recomendaciones X.400 de 1988 se definieron cuatro formas de direccionamiento. El formato de 1984, Forma 1, Variante 1, se renombró como dirección O/R mnemotécnica y el formato de 1984, Forma 1, Variante 3 y Forma 2 se combinaron y se renombraron como dirección O/R de terminal. Las nuevas formas introducidas fueron la forma O/R numérica (una variación de la Forma 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.
La confusión causada por el formato de direccionamiento X.400 condujo a la creación del estándar X.500 para servicios de directorio . La idea era crear un directorio de direcciones de correo electrónico jerárquico y estandarizado con funcionalidad de replicación y distribución que permitiera a múltiples organizaciones producir un único directorio público. Por ejemplo, cada Dominio de Gestión de Administración (proveedor de servicios) podría cargar opcionalmente su directorio a un servidor X.500 compartido y luego permitir que los Agentes de Usuario X.400 busquen en esta base de datos durante la creación de correos electrónicos, evitando así la necesidad de saber algo sobre la dirección más allá del nombre del destinatario y algún tipo de nombre organizacional como una empresa. [11]
Desafortunadamente, el protocolo X.500 resultó ser tan complejo y difícil de manejar como el X.400, y esto llevó a la creación del Protocolo ligero de acceso a directorios , o LDAP, que estandarizó un subconjunto simple de los protocolos X.500 adecuados para su uso por parte del software de usuario final que busca direcciones. LDAP se utiliza ampliamente en servicios de directorio como Active Directory de Microsoft . [11]
Además, el objetivo de proporcionar una base de datos de direcciones universal era fundamentalmente defectuoso cuando se propuso. En la era de las empresas nacionales de telecomunicaciones como British Telecom o France Télécom , los nombres y números de teléfono de las personas se consideraban información pública y ya se recopilaban en dichos directorios en forma de guía telefónica . Extender esto a las direcciones de correo electrónico parecía obvio.
Sin embargo, este simplemente no era el caso en la década de 1980; en ese momento, el correo electrónico a menudo se asociaba con usuarios comerciales o gubernamentales, y esas organizaciones trataban las direcciones de sus miembros como valiosas, o incluso confidenciales. No había ningún incentivo para que las organizaciones compartieran estos datos con el público. Como lo expresó RFC2693, "imaginemos a la CIA agregando su directorio de agentes a un grupo mundial X.500". [12]
X.400 ha pasado de ser "el sistema de correo que todos usaremos algún día" a "solo se usa en casos gubernamentales/militares limitados, e incluso esos están desapareciendo".
{{cite journal}}: Requiere citar revista |journal=( ayuda )