X.400

X.400 é um conjunto de recomendações da ITU-T que define padrões para Rede de Comunicações de Dados para Sistemas de Tratamento de Mensagens (MHS - Message Handling System) — mais conhecido como "E-mail". Entretanto o X.400 nunca atingiu a presença universal do Webmail, podendo ser visto apenas em algumas organizações e produtos proprietários de e-mail.

Recomendação X.400
Sistemas de Correio Eletrônico
--------------------------------------------

Introdução

---------------------------------------------

Sistemas e serviços de tratamento de mensagens habilitam os usuários a trocar mensagens na base do armazena-e-envia (store-and-forward). Uma mensagem submetida por um usuário, o originador, é conduzida pelo Sistema de Transferência de Mensagens (MTS -Message Transfer System), o principal componente de um grande Sistema de Tratamento de Mensagens (MHS - Message Handling System), e é subsequentemente enviada para um ou mais usuários, os receptores da mensagem.

Um MHS compreende uma variedade de entidades funcionais interconectadas:


MTA (Message Transfer Agents) Agentes de Transferência de Mensagens, cooperam para executar a função de armazena-e-envia da transmissão da mensagem.
MS (Message Stores) Armazenamento de Mensagens, possibilitam armazenamento para mensagens e habilitam sua submissão, recuperação e gerenciamento.
UA (User Agents) Agentes de Usuário, auxiliam o usuário a editar suas mensagens e a acessar o MHS.
AU (Access Units) Unidades de Acesso, fornecem ligação a outros sistemas e serviços de comunicação de várias classes.
PDAU(Physical Delivery Access Unit).Unidade de Acesso de Entrega Fisica, fornece a comunicação entre o correio eletrônico e o correio convencional

--------------------------------------------

Descrição do Modelo de MHS

--------------------------------------------
Neste modelo, um Usuario pode ser qualquer pessoa ou processo. Um Usuário é referenciado como qualquer um emissor ou receptor. Elementos do serviço de tratamento de mensagens definem o conjunto de tipos de mensagens e capacidades que habilitam um emissor a transferir mensagens destes tipos para um ou mais receptores.
Um emissor prepara mensagens com o auxilio de seu Agente de Usuário. Um Agente de Usuário é uma processo de aplicação que interage com o Sistema de Transferencia de Mensagens(MTS) ou um Armazenador de Mensagens(MS), para submeter uma mensagem em vez de um simples usuário. O MTS envia a mensagem submetida a ele, a um ou mais Agentes do Usuário (UA) receptores, ou MS, e pode retornar notificações ao emissor.Funções executadas somente pelo UA e não padroniazdas como parte dos Elementos de Serviço do Tratamento de Mensagens são chamadas funções locais. Um UA pode aceitar remeter mensagens diretamente do MTS, ou pode usar as capacidades de um MS para receber mensagens remetidas por subsequente recuperadas pelo UA.

O MTS compreende um número de Agentes de Transferência de Mensagens(MTAs). Operando juntos, de um modo armazena-e-envia (store-and-forward), o MTA transfere mensagens e envia-as para o receptor apropriado.

Acessado por usuários indiretos de MHS é executado por AUs. Envio para usuários indiretos de MHS é executado por AUs, assim como no caso de envio físico, pela Unidade de Acesso de Envio Físico(PDAU).

O Armazenador de Mensagens (MS) é uma capaciade de propósito geral do MHS que atua como um intermediário entre o UA e o MTA. O MS é uma entidade funcional cujo propósito primário é armazenar e permitir retransmissão de mensagens enviadas. O MHS também permite submissão de, e alertando o UA.

Uma coleção de UAs, MSs, AUs e MTAs é chamada de Sistema de Tratamento de Mensagens(MHS - Mesage Handling System).

-------------------------------------------------

Serviço de Tratamento de Mensagens

-------------------------------------------------
O Serviço de Tratamento de Mensagens (MTS - Message Transfer Service) é basicamente uma aplicação independente que nos possibilita o armazenamento e envio de mensagens.

Submissão e Envio
Basicamente há duas intereções entre o MTA e o UA e/ou MS: Submisão: é a interação onde o UA ou Ms transfere para o MTA o conteúdo da mensagem e o envelope de submissão. Envio: é a interação onde o MTA pransfere para o UA ou MS receptor o conteúdo da mensagem e o envelope de envio.

Transferência
Iniciando no MTA originador, a mensagem é transferida de MTA em MTA até que chegue no MTA receptor, o qual, então, irá enviá-la para o UA ou MS receptor. Durante a transmissão o MTA recebe a mensagem e não efetua nenhuma alteração em seu conteúdo, salvo em caso de necessiade de conversão.

Notificações
Quando um MTA efetua o envio da mensagem ou no caso de não conseguir, ele emite uma notificação do ocorrido para o originador.

--------------------------------------------------

Serviço de Mensagens Interpessoais (IPM)

--------------------------------------------------
O Serviço de Mensagens Interpessoais é um recurso fornecido pelo serviço de transferência de mensagens que possibilita que um usuário se comunique com outro, usando para isso as facilidades do serviço de transferência de mensagens.

Estrutura das Mensagens Interpessoais (IP)
O conteúdo específico que é enviado de um UA de IPM a outro é o resultado da composição do originador e uma mensagem enviada, chamada mensagem IP. A estrutura pode ser vista na figura abaixo.


--------------------------------------------

Nomeando e Endereçando

---------------------------------------------
Usuário e Listas de Distribuição são identificados por nome O/R. Nomes O/R (Originador /Receptor - Originator/Recipient) são compreendidos como nomes de diretórios e/ou endereços.

Nomes de Diretórios
Os usuário do MHS podem ser identificados por um nome, chamado nome de diretório. A estrutura e componentes dos nomes de diretório podem ser vistos na série de Recomendações X.500.

Endereços O/R
Os endereços O/R contém informação necessária para que o MHS esteja habilitado a identificar o usuário a quem deve enviar a mensagem ou retornar uma notificação. Um endereço O/R é uma conjunto de informações chamado atributos.
Atributos Geográficos: nome do país, nome do domínio.
Atributos Complementares: nome, sobrenome, nome da organização, nome da uidade organizacionl, etc.
Endereço Físico ou de Rede

----------------------------------------------

Uso de Diretórios pelo MHS

----------------------------------------------
O uso de Diretórios no tratamento de mensagens se dá nas seguintes situações:
Nomeação Amigável: o originador ou receptor de uma mensagem pode ser identificado através de seu nome de diretório, no lugar da orientação de endereço O/R. A qualquer momento o MHS pode obter a informação consultando o diretório.
Listas de Distribuição: Um grupo cujos membros estão armazenados em um diretório pode ser usado como um DL. O originador simplesmente india o nome da lista.
Capacidades de UA Receptor: as característicasdo de MHS do receptor (ou originador) podem ser armazenadas no seu diretóro.
Autenticação: antes de duas entidades do MHS ( dois MTAs, ou um UA e um MTA) se comunicarem uma com a outra, cada uma pode estabelecer a identidade da outra.

--------------------------------------------

Listas de Distribuição em MHS

--------------------------------------------
O recurso de usar uma lista de distribuição (DL -Distribution List) é uma capacidade opcional do MHS provida pelo serviço de transferência de mensagens. A expansão da DL permite enviar uma mensagem para um grupo de receptores.
Propriedades de uma DL
Membros: usuários e outras DLs podem receber mensagens endereçadas a uma DL.
Permissão de Submissão: uma lista de usuários ou outas DLs as quais tem permissão de fazer uso do DL para enviar mensagens aos membros desta.
Ponto de Expansão: cada DL possue um endereço O/R único. Este endereço O/R identifica o ponto de expansão, o qual é o domínio ou MTA onde os nomes dos membros da DL são adicionados a lista de receptores.
Proprietário: um usuário que é responsável pelo gerenciamento da DL.

---------------------------------------------

Recursos de Segurança do MHS

---------------------------------------------
Os recursos nessa sessão cobrem a aplicação dos aspectos de segurança para proteger mensagens diretamente submetidas ao MHS por um agente de usuário, Armazenador de Mensagens, ou uma unidade de acesso.Eles não cobrem as aplicações dos aspectos de segurança para proteger comunicação entre usuários e o MHS, ou comunicação MH-user a MH-user (uma grande parte dessa cominicação é protegida entre dois UAs). Deste modo eles não aplicam, por exemplo, comunicação entre um terminal remoto do usuário e seu UA, ou a comunicação entre estes equipamentos de terminal do usuário e outros usuários no MHS.
Muitos dos elementos de serviço da segurança de mensagens fornecem um originador para a capacidade de receptor, e requerem o uso de agentes de usuarios com capacidades de segurança. Eles não requerem o uso de um MTS com aspectos de segurança. (Como um exemplo, confidencialidade de conteúdo pode ser aplicado enclausurando o conteúdo da mensagem pelo originador, e desencapsulando pelo receptor, com vários parâmetros de segurança transferidos junto com o envelope da mensagem. Deste modo uma mensagem pode ser transferida por um MTS o qual manipule o formato do conteúdo (desformatando octetos), e transparentemente manipulando os campos de segurança do envelope.)
Alguns dos elementos de serviço de segurança das mensagens envolvem uma interação com o MTS,e requer o uso de MTA com recursos de segurança. (Como um exemplo, não repudiação de uma submissão requer que o MTA, para o qual a mensagem é submetida, contenha mecanismos para gerar uma evidência do campo de submissão.)
Alguns elementos de serviço de segurança de mensagens aplicados no MS tão bem como nos UAs e MTAs, semelhantes a rotulação de segurança de mensagens. No geral, contudo, o MS é transparente para os aspectos de segurança que são aplicados entre os UAs originadores e receptores.
O escopo dos elementos de serviço de segurança de mensagens é mostrado na tabela abaixo. Ela descreve os elementos de serviço em termos de qual componente do MHS é o fornecedor ou qual é o usuário do serviço de segurança. Por exemplo, a sondagem de autenticação da origem é fornecida pelo UA originador, e pode ser usada pelo MTAs através dos quais a sondagem passa.
Elementos de Serviço MTS MTS MTS
do usuário do usuário
Originador Receptor
Autenticação da Origem da Mensagem P U U
Relatório da Autenticação da Origem U P -
Sondagem da Autenticação da Origem P U -
Evidência do Remessa U - P
Evidência da Submissão U P -
Gerenciamento de Segurança de Acesso P U P
Integridade do Conteúdo P - U
Confidencialidade do Conteúdo P - U
Confidencialidade do Fluxo da Mensagem P - -
Integridade da Sequência da Mensagem P - U
Não-Rejeição da Origem P - U
Não-Rejeição da Submissão U P -
Não-Rejeição da Remessa U - P
Rotulação da Segurança de Mensagem P U U

P - o componente MHS é um fornecedor do serviço.
U - o componente MHS é um usuário do serviço.

Gerenciamento de Segurança
Aspectos de uma chave assimétrica de um esquema de gerenciamento para suportar as características abaixo são fornecidas pela estrutura de autenticação do sistema de diretórios, descrito na recomendação X.509. O diretório armazena cópias certificadas de chaves públicas para os usuário do MHS as quais podem ser usadas para providenciar autenticação e para facilitar a troca de chaves para uso de mecanismos de confidencialidade de dados e integridade de dados. O atestado pode ser lido do diretório usando o protocolo de acesso a diretório descrito na recomendação X.519.


---------------------------------------------

Elementos de Serviço

---------------------------------------------
Elementos de Serviço são recursos, funções ou caacidades do MHS.
Eles são relacionados com vários serviçs oferecidos pelo MHS. Há Elementos de serviço para o MTS, que oferecem capacidade básica de envio e recepção de mensagens entre UAS, para o MS, para o IPMS, etc. Alguns Elementos de Serviço:
Gerenciamento de Acesso (Access Management)
Permissão para Receptor Alternativo (Alternative recipient allowed)
Indicação de Autorização de Usuário(Authorizing users indication)
Indicação de Enriptação de Parte do Corpo da Mensagem (Body part encryption indicaton)
Proibição de Conversão (Conversion proibition)
Notificação de Envio (Delivery notification)
Conversão Explicita (Explicit conversion)
Autenticação da Origem da Mensagem (Message origin authentication)
Indicação do Originador (Originator Indication)
Alerta de Mensagem Armazenada (Stored message alert)
Uso de Listas de Distribuição (Use of distribuition list)

--------------------------------------------------------------------------------


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 the ISO, 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) Message handling system and service overview Recommendation.

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 a 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.

As with most ISO standards dealing with application-level networking, X.400 failed to compete successfully with SMTP, the Internet-based equivalent in North America. However, in Europe, South America, and Asia, X.400 is quite widely implemented, especially for EDI services. In North America X.400 is still used in some applications, such as the military, intelligence services and aviation, mainly because the X.400 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.

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 a 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.

Important features of X.400 include structured addressing, ASN.1 binary encoding 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.

X.400 has been extended for use in military applications (see MMHS) and aviation (see AMHS.)


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

C (Country name)
ADMD (Administration Management Domain), usually a public mail service provider
PRMD (Private Management Domain)
O (Organization name)
OU (Organizational Unit Names)
G (Given name)
I (Initials)
S (Surname)
The standards themselves originally did not specify how these email addresses should be written (for instance on a business card); 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;P=Uninett;A=;C=no" - the unwieldiness of this addressing format is believed by many to be one factor in the lack of success of X.400. [1]

X.400 addresses are ugly
Contrast the following two strings:
G=Harald; S=Alvestrand; O=sintef; OU=delab; PRMD=uninett; ADMD=uninett; C=no
Harald.Alvestrand@delab.sintef.no
(This, btw, is an old address of mine; don't use it)
There are several apparent differences:

The second one is shorter
The first one has labels for pieces of the address
One element (uninett) occurs twice in the first, but not in the second
The order of the elements "delab" and "sintef" is reversed
Typing the first requires more keys to be used
There are also differences that aren't apparent on the surface, but become clear when you investigate underlying technology:
ADMDs and PRMDs often expect to route on the "C,ADMD,PRMD" triple only, and ADMDs route mostly on the "C,ADMD" tuple; Internet mailers route on "delab.sintef.no" as an unit.
ADMD is a name assigned by the provider you buy service from. This means that you advertise your service provider every time you show your E-mail address.
"delab.sintef.no" is resolvable from an unique root using the DNS from any node on the Internet. There is no algorithm executable in real time that allows you to decide whether "PRMD=uninett; ADMD=uninett; C=no" is a valid triple or not from any X.400 node.
The use of the ADMD field brings to mind what Rob Frieden writes in his "International Telecommunications Handbook" (ISBN 0-89006-568-3):
The greatest degree of negotiating clout will lie with users who generate large traffic volumes and can migrate to other suppliers, or who can install their own equipment
The ADMD name is a bar to migrating to another supplier; the routing habit is a bar to "installing your own equipment" - that is, PRMDs cross-connecting to other PRMDs or ADMDs. In some countries, it's even illegal....
There are also some important commonalities:

Both are (mostly) hierarchical in nature, with administrators at a "higher level" assigning names at the "level below"
Both use a restricted character set for naming
Both can be separated into components, and those components are important to the mail network.
Both purport to be globally unique addressing schemes
Neither maps cleanly into the other.
You might be convinced of the superiority of one scheme over the other already, but read on....
Attribute-based addressing
X.400 was designed with attributed addresses. The complete set of attributes is rather large; this table comes from RFC 1685, which in turn copied it from F.401 annex F (this was added to the standard in early 1993; before this, there was no standardized way to write down an X.400 address, which led to some confusion):

Attribute Type Abbreviation Label
(where necessary)

Given Name Given name G
Initial Initials I
Surname Surname S
Generation Qualifier Generation Q
Common Name Common Name CN
Organization Organization O
Organizational Unit 1 Org.Unit.1 OU1
Organizational Unit 2 Org.Unit.2 OU2
Organizational Unit 3 Org.Unit.3 OU3
Organizational Unit 4 Org.Unit.4 OU4
Private Management Domain Name PRMD P
Administration Management Domain Name ADMD A
Country Country C
Physical Delivery Personal Name PD-person PD-PN

Extension of Postal O/R Address
Components PD-ext.address PD-EA
Extension of Physical Delivery Address
Components PD-ext.delivery PD-ED
Physical Delivery Office Number PD-office number PD-OFN
Physical Delivery Office Name PD-office PD-OF
Physical Delivery Organization Name PD-organization PD-O
Street Address PD-street PD-S
Unformatted Postal Address PD-address PD-A1
PD-A2
(there are individual labels for PD-A3
each line of the address) PD-A4
PD-A5
PD-A6
Unique Postal Name PD-unique PD-U
Local Postal Attributes PD-local PD-L
Postal Restante Address PD-restante PD-R
Post Office Box Address PD-box PD-B
Postal Code PD-code PD-PC
Physical Delivery Service Name PD-service PD-SN
Physical Delivery Country Name PD-country PD-C

X.121 Network Address X.121 X.121
E.163/E.164 Network Address ISDN ISDN
PSAP Network Address PSAP PSAP
User Agent Numeric ID N-ID N-ID
Terminal Identifier T-ID T-ID
Terminal Type T-TY T-TY
Domain Defined Attribute DDA:
DDA:

where the notation identifies the type of domain defined
attribute.


Most of these aren't used very much; those with PD- in front of them are used with X.400 networks that support delivery of mail by printing it onto paper and sending it to the postal service, and the only one I've seen used out of the network crowd is the X.121, which some ADMDs use to address fax machines through the telephone network.
[soap....] I regard attribute-based addressing as a mistake.
This stems from the fact that attribte labels tend to make people believe that the named entity should have some property associated with the label; for instance, they expect something to be an organization just because it is named in the "organization" field, and something "should be" a person just because it has a "surname" field.

They also expect address hierarchies to conform to organizational charts, thinking that OU1=trondheim; OU2=sales means that there is a Trondheim office controlling the Trondheim sales department. (Trondheim is a city), or expect an user to work for an organization just because he uses its O field, while he is in fact a customer of their service. [....soap]

Other problems include the use of "country": SITA, the airline industry network, has unilaterally started to use "C=WW" for "world wide", because several of its customers refused to be locked into a statement about which country they were located in, and the ISODE Consortium, with offices in the UK and USA, uses "C=FI" because their service provider happens to be operating out of Finland.

X.400 extensions to the addressing format
X.400 (88) brought fresh life into addressing.
It added an extension mechanism, allowed most attributes to be written using the Teletex charset (Japanese characters, and most accents, but NOT greek, Arabic or Sanskrit), and then added the proviso that you had to make all the mailboxes addressable using the older PrintableString attributes, because you couldn't expect everyone in the world to be fluent Kanji typists.

It also added the "Common Name", "because it seems so silly to talk about the surname of a process or mailing list", adding further to the confusion, and not helping ease of mapping at all.

There have been moves afoot to add the possibility of putting Internet-style addresses into X.400 addresses as a new attribute, making life easier for the Internet gateways, but rather harder for those whose UAs haven't even found out what a Common Name is yet.

Another interesting twist is the "special ADMD values", SPACE for indicating "You may route on the C,PRMD tuple, and if you are connected to any ADMD in the country, you can expect it to be delivered", which works with at least some UK ADMDs, and the zero ("0") for indicating that you are in a PRMD that is connected to no ADMD, so if you don't have a route directly to it, you can drop the message immediately.
The latter one hasn't exactly been a raging success...

Weird examples of Internet adressing
Well..all isn't well with the "simple" Internet address format either. Look at some of these examples (user names ONLY changed to protect the guilty):
SOME_USER@HP-SWITZERLAND-desk1////////HPMEXT1/THIERRY#b#PARIDANT#o#HP8700#o#Y0.om.hp.com
(current leader in category "abusive domain name". Apparently worked!)
GIS_+a_RCI_+lGivenname_Surname+i%MHS+d_20D08E2B01F53FDC-20D08E2B02F53FDC%RCI_Incorporated@mcimail.com
(current leader in category "abusive user naming"; it couldn't be
replied to either)
John_Smith%Dept_Server%Widget_Dept@company.gateway.com
(rabid rewriters may think they know what a percent sign is for)
(produced by Banyan Vines gateways; I don't have a working example)
70621.567@compuserve.com
(most cryptic address format in widespread use)

Common to most of these are:
Attempts to gateway stuff from another E-mail
Considering the "internet style" of things as something one can happily ignore.
The native Internet address style tolerates these abuses. I don't think it condones or promotes them.


X.400

Unter X.400 hat die ISO in Zusammenarbeit mit der ITU Mailbox- oder sogenannte Message-Handling-Systeme (MHS, ISO 10021) standardisiert. Darüber hinaus wurden auch die Protokolle, die Service-Spezifikationen und die Art und Weise festgelegt, wie X.400 implementiert werden soll.
Als Oberbegriff definieren X.400 und MOTIS ein allgemein gültiges Modell der elektronischen Nachrichtenübermittlung, das Message-Handling-Modell (MHS). Durch X.400 wird das komplexe Gebiet der elektronischen Post transparenter gemacht. Dabei lehnt man sich stark an die bekannten Konzepte der Briefpostvermittlung an.

Benutzer werden in diesem Modell durch User Agents (UA) repräsentiert. Miteinander kommunizierende Message Transfer Agents (MTA) leiten Nachrichten von einem User Agent an einen oder mehrere andere User Agents speichervermittelt (Store-and-Forward-Verfahren) weiter.


--------------------------------------------------------------------------------

Referências:

--------------------------------------------------------------------------------

[CCI88] CCITT Blue Book volume VIII - Fascicle VIII.7. "Data Communication Networks, Message Handling Systems". Recommendations X.400 - X.420 (1988).

[TAN94] TANENBAUM, Andrew S. Redes de Computadores. Campus, Rio de Janeiro, 1994.

[BRI94] BRISA. Arquiteturas de Redes de Computadores. Makron Books, São Paulo, 1994.

[1]Betanov, Cemil (1993). Introduction to X.400. Boston: Artech House. ISBN 0-89006-597-7.
[2]http://en.wikipedia.org/wiki/X.400"
[3]http://www.faqs.org/rfcs/rfc1649.html


Comentários

Postagens mais visitadas deste blog

Redação Ti Nota 10 - Klauss

Prova Discursiva nota 10 - Banca Cespe

Portugues - Orações