Vai al contenuto

X.400

Da Wikipedia, l'enciclopedia libera.

X.400 è un insieme di raccomandazioni, fornite dall'ITU-T, che definiscono il sistema di gestione dei messaggi MHS (Message Handling System).

Negli anni '80 e '90, i progettisti di X.400 si aspettavano che diventasse la forma predominante di posta elettronica; tuttavia, questo ruolo fu ricoperto dalla posta elettronica Internet basata su SMTP. Il suo utilizzo attuale risiede all'interno delle organizzazioni governative e fino al 2006 è stato una parte fondamentale del servizio di Microsoft Exchange Server; le varianti inoltre continuano ad essere importanti nei contesti militari e aeronautici.

Storia

[modifica | modifica wikitesto]

Le prime Raccomandazioni X.400 furono pubblicate nel 1984 (Red Book), mentre una versione sostanzialmente rivisitata fu pubblicata nel 1988 (Blue Book). Successivamente furono aggiunte nuove funzionalità nel 1992 (White Book), dai quali ne conseguirono aggiornamenti. Sebbene X.400 fosse stato originariamente progettato per essere eseguito sul livello di trasporto OSI, il sempre più crescente utilizzo del protocollo TCP/IP lo rese sempre più marginale.

Sviluppate in collaborazione tra ISO e IEC, le Raccomandazioni X.400 specificavano i protocolli standard OSI per lo scambio di messaggi. La serie di raccomandazioni F.400, pubblicate nello stesso periodo, definiva i servizi di gestione dei messaggi basati sui sistemi di gestione dei messaggi (MHS), nonché l'accesso da e verso l'MHS per i servizi pubblici. Alla fine degli anni '90, l'ITU-T decise di consolidare le raccomandazioni F.400 e X.400 e pubblicò quindi nel giugno 1999 la raccomandazione ITU-T F.400/X.400 intitolata "Sistema di gestione dei messaggi e panoramica dei servizi".

Le raccomandazioni della serie X.400 definiscono i vari aspetti tecnici dell'MHS:

  • La raccomandazione ITU-T X.402 (ISO / IEC 10021-2) definisce l'architettura complessiva del sistema di un MHS,
  • La raccomandazione ITU-T X.411 (ISO / IEC 10021-4) definisce il Message Transfer Service (MTS) e il suo componente funzionale Message Transfer Agent (MTA);
  • La raccomandazione ITU-T X.413 (ISO / IEC 10021-5) definisce il Message Store (MS).

Tutte le raccomandazioni ITU-T forniscono termini specifici per le descrizioni delle entità e delle procedure del sistema. Ad esempio, i messaggi (e-mail) scambiati tra le persone vengono indicati come Interpersonal Messaging (IPM).

La gestione dei messaggi è un sistema distribuito che integra due processi principali: quello per il trasferimento dei messaggi e quello per la loro archiviazione.

Le Raccomandazioni ITU-T definiscono protocolli specifici per un'ampia gamma di attività di comunicazione: per esempio, il protocollo P1 viene utilizzato esplicitamente per la comunicazione tra i vari MTA; il protocollo P3 tra lo User Agent (UA) e un MTA; infine, il protocollo P7 tra l'UA e il Message Store (MS).

Nella versione del 1994, il protocollo P7 è stato migliorato per fornire cartelle nel Message Store, consentire l'archiviazione dei messaggi inviati e fornire molte azioni automatiche come l'inserimento automatico di cartelle e la correlazione di risposte, i report degli invii dei messaggi e le notifiche di ricezione con i relativi messaggi inviati.

Gli standard dei contenuti dei messaggi X.400 sono definiti per la comunicazione tra i vari UA. Questi vengono modellati come protocolli concettuali che usano P1 e P3/P7 per fornire un trasporto affidabile dei messaggi.

Nel protocollo P2, così nominato nel Red Book e definito nella Raccomandazione ITU-T X.420 | ISO / IEC 10021-7, si trova lo standard del contenuto per la messaggistica interpersonale, IPM (Interpersonal Messaging). Nella versione estesa di IPM, descritta successivamente nel Blue Book, è stato assegnato il tipo di contenuto 22 (stante per P2 versione 2) ed è spesso indicata informalmente come P22, sebbene tale termine non sia utilizzato negli standard. Lo standard del contenuto dei messaggi per EDI è invece definito nelle ITU-T Rec. F.435 | ISO/IEC 10021-8 e ITU-T Rec. X.435 | ISO/IEC 10021-9 e informalmente denominato P35. Un tipo di contenuto di messaggistica vocale è definito nel ITU-T Rec. F.440 e X.440.

Tra le caratteristiche più importanti di X.400 troviamo:

  • l'indirizzamento strutturato;
  • l'ASN.1, un linguaggio astratto, seriale e standardizzato che abilita la trasmissione di contenuti multimediali (precedente e più efficiente di MIME);
  • diverse funzionalità di sicurezza integrate.

Poiché ITU riteneva che i servizi di inoltro interdominio X.400 dovessero essere gestiti autonomamente dai vari enti governativi di Poste e Telecomunicazioni, X.400 incorporava campi per il trasferimento automatico di messaggi tra X.400 e altri servizi PTT[1], come il fax e la posta fisica. Questa idea sbagliata di fondo fu tra le cause per le quali X.400 non raggiunse mai quella diffusione inizialmente sperata, nonostante negli anni ci furono diversi tentativi da parte di ISO di aggiungere funzionalità per ampliare il suo utilizzo.

Implementazione

[modifica | modifica wikitesto]

Dalla fine degli anni '80, molti Stati si impegnarono nel definire il modello OSI, attraverso il GOSIP - Government Open Systems Interconnection Profiles. A loro volta, i principali produttori di computer si impegnarono altresì a produrre prodotti compatibili con OSI, incluso X.400. Il server Exchange di Microsoft venne sviluppato in questo periodo di tempo e basato internamente su X.400/X.500, con la versione iniziale che, almeno teoricamente, riusciva ad inviare messaggi tramite Messaging API (MAPI), X.400 o Simple Mail Transfer Protocol (SMTP).[2] In pratica, tuttavia, la maggior parte di questi protocolli non furono implementati a dovere e, di conseguenza, raramente vennero veramente utilizzati.

In Nord America, anche molti grandi appaltatori della difesa e università si erano già impegnati a favore di Internet e degli standard TCP/IP, incluso SMTP per la posta elettronica. X.400 era ed è tuttora utilizzato in alcune applicazioni, come i servizi militari, di intelligence e l'aviazione: il motivo principale è perché le funzioni X.400 per l'integrità e la sicurezza furono sviluppate e implementate molto prima delle loro controparti nel protocollo SMTP ( S/MIME, PGP e SMTP-TLS). Sempre per lo stesso motivo, in alcuni contesti viene ancora utilizzato per la trasmissione di messaggi EDI tra diversi applicativi.

X.400 è stato esteso per l'uso in applicazioni militari (vedi gli MMHS, Military Message Handling System) e aviazione (vedi AMHS, Aeronautical Message Handling System).

Assegnazione degli indirizzi

[modifica | modifica wikitesto]

Una delle principali innovazioni che X.400 ha provato a portare avanti era la risoluzione alla consegna di un messaggio quando l'indirizzo non veniva digitato correttamente. Negli anni '80 e '90, i formati degli indirizzi elettronici variavano da piattaforma a piattaforma, pertanto era difficile per gli utenti sapere come digitarli correttamente. Ciò era in contrasto con il servizio postale "reale", in cui anche gli indirizzi parziali sono dapprima reindirizzati a un ufficio di lettere non recapitate, salvo poi essere consegnati laddove sia possibile interpretare gli errori di battitura.

Per risolvere questo problema, lo schema di indirizzi X.400 includeva diversi campi ridondanti che potevano essere utilizzati per aiutare a recapitare il messaggio. Ad esempio, c'erano campi separati per nome e cognome e un campo per le iniziali. Il server era identificato con più campi, incluso il nome di un'azienda o di un'organizzazione, nonché il paese di origine. L'idea di base era quella che un indirizzo con un qualsiasi campo scritto in maniera errata contenesse comunque informazioni sufficienti affinché il messaggio potesse essere instradato correttamente. Ad esempio, il nome della persona e il paese in alcuni contesti potevano essere già sufficienti.

All'epoca si pensava che in futuro la posta elettronica sarebbe stata fornita dalle multinazionali delle telecomunicazioni o dalle compagnie telefoniche nazionali. Ciò significava che, fintanto che il messaggio raggiungeva il fornitore di servizi, indicato nel campo "Administration Management Domain" (ADMD) dell'indirizzo, il sistema avrebbe probabilmente intuito l'utente destinatario. Poiché questo fornitore di servizi era probabilmente di portata nazionale, fornire semplicemente il codice del paese corretto poteva essere un'informazione sufficiente per instradare correttamente il messaggio.

Tuttavia, questo modello fallisce nel momento in cui i servizi di posta elettronica sono forniti dall'azienda o dall'organizzazione dell'utente o quando il fornitore del servizio non è noto. In questo caso, non esiste un database di utenti su scala nazionale ed è sufficiente un nome di organizzazione improprio per causarne il fallimento.

Questo appena descritto è il modello dominante oggi: infatti, gli indirizzi email attuali vengono forniti dalle aziende, le quali utilizzano un server interno o, ancora più comunemente, utilizzano un provider come Microsoft 365 o Gmail. In questo caso, l'ADMD è sconosciuto o uguale all'organizzazione stessa.

Oltretutto, Il sistema di indirizzamento diviso in più parti di X.400 ha reso il formato abbastanza complesso; gli utenti infatti non erano sicuri di quali campi fossero importanti e pertanto tendevano a fornire tutte le informazioni che potevano. Ciò ha reso alcune azioni banali, come lo stampare l'indirizzo su un biglietto da visita o il digitarlo nel client di posta elettronica, più difficili rispetto a sistemi più semplici come quelli trovati in SMTP. Molti ritengono che l'ingombro di questo formato di indirizzamento sia stato, col senno di poi, uno dei principali motivi del mancato successo di X.400.[3]

Un indirizzo X.400 funge sia per il mittente, sia per il destinatario: non a caso lo si trova spesso denominato come "OR Name", dalle parole Originator / Recipient. L'indirizzo ha due scopi:

  • Identificazione della casella di posta del mittente o del destinatario;
  • Identificazione del dominio globale e/o della sua locazione.

Un indirizzo X.400 è costituito da diversi campi, tra cui:

  • C (nome del paese, country)
  • ADMD (Administration Management Domain, a volte nella sua forma abbreviata A): di solito un fornitore di servizi di posta pubblica
  • PRMD (Private Management Domain, a volte nella sua forma abbreviata P)
  • O (Nome dell'organizzazione)
  • OU (Organizational Unit Names)
  • G (nome, given name)
  • I (iniziali)
  • S (cognome, surname)

Gli standard originariamente non specificavano come questi indirizzi email dovessero essere scritti, o se gli identificatori di campo dovessero essere maiuscoli o minuscoli, o quali set di caratteri si potessero usare. Solo il documento RFC 1685 aveva un esempio, basato su una bozza del 1993 della Raccomandazione ITU-T F.401, che assomigliava a:

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

Il libro del 1984 (il Red Book) forniva due possibilità per i formati degli indirizzi:

  1. utilizzare principalmente l'ADMD ed un sottoinsieme di altri attributi. Questo modo aveva 3 possibili varianti da poter utilizzare, ognuna con dei gruppi di attributi diversi da dover compilare.
  2. identificare gli utenti mediante indirizzi di terminali telematici (hardware)[4]. Questo modo era univoco.

L'introduzione del sistema di directory X.500

[modifica | modifica wikitesto]

La confusione causata dal formato degli indirizzi X.400 portò alla creazione dello standard X.500 per i servizi di directory. L'idea era quella di creare una directory di indirizzi e-mail gerarchica e standardizzata, con funzionalità di replicazione e distribuzione, che consentissero a più organizzazioni di produrre un'unica directory pubblica. Ad esempio, ciascun ADMD, nel ruolo di service provider, può decidere di caricare la propria directory su un server X.500 condiviso: ciò consente la ricerca di questo database da parte degli UA X.400 durante la creazione della propria email, permettendo loro di dover conoscere solo il nome del destinatario e quello dell'ente organizzativo, ossia ciò che viene definito nel campo O dell'indirizzo.[5]

Ciò nonostante, il protocollo X.500 si rivelò altrettanto complesso e ingombrante esattamente come quello proposto inizialmente da X.400. Ciò ha portato alla creazione del Lightweight Directory Access Protocol, o LDAP, che ha standardizzato un semplice sottoinsieme dei protocolli X.500 al fine di creare software che permettessero la ricerca dei vari indirizzi. LDAP è tuttora ampiamente utilizzato nei servizi di directory come quello di Active Directory di Microsoft.[6]

Inoltre, l'obiettivo di fornire un database di indirizzi universale era fondamentalmente un'idea sbagliata, ma figlia dei suoi tempi. Infatti, nell'era delle società di telecomunicazioni nazionali come British Telecom o France Télécom, i nomi ed i numeri di telefono delle persone erano considerate informazioni pubbliche e già raccolti in tali elenchi sotto forma di elenco telefonico. Estendere questo agli indirizzi e-mail sembrava ovvio; tuttavia, questo semplicemente non era il caso negli anni '80. In quegli anni infatti, la posta elettronica era spesso associata ad utenti aziendali o governativi: tali organizzazioni trattavano questi indirizzi come preziosi o addirittura riservati. Non c'era motivo di condividere queste informazioni; come afferma oltretutto il documento RFC2693, "immaginate che la CIA aggiunga la sua directory di agenti in una pool X.500 mondiale".[7]

Note

[modifica | modifica wikitesto]
  1. ^ Questa la sigla comunemente utilizzata da diversi Stati per indicare il loro servizio statale di Poste, Telegrafi e Telecomunicazioni.
  2. ^ https://www.itprotoday.com/email-and-calendaring/microsoft-exchange-server-50-smoothes-rough-edges.
  3. ^ X400 Debate: Addresses are ugly
  4. ^ A Practical Guide to X.400 Addressing by Roger K Mizumori page 26 ISBN 1-85032-210-4
  5. ^ Collections Canada, http://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf.
  6. ^ Collections Canada, http://www.collectionscanada.gc.ca/iso/ill/document/ill_directory/X_500andLDAP.pdf.
  7. ^ RFC2693, 1999, DOI:10.17487/RFC2693.

Bibliografia

[modifica | modifica wikitesto]

Riferimenti generali

[modifica | modifica wikitesto]

Raccomandazioni ITU-T X.400

[modifica | modifica wikitesto]

Voci correlate

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
Controllo di autoritàGND (DE) 4219354-0
  Portale Crittografia
Estratto da "https://it.wikipedia.org/w/index.php?title=X.400&oldid=139084610"