Passa al contenuto principale

2. Ruoli degli attori responsabili

La posta elettronica Internet è un servizio altamente distribuito, con una varietà di attori che svolgono ruoli diversi. Questi attori rientrano in tre tipi fondamentali:

  • Utente (User)

  • Servizio di gestione dei messaggi (Message Handling Service - MHS)

  • Dominio di gestione amministrativa (ADMD)

Sebbene sia correlato a un'architettura tecnica, l'attenzione sugli attori riguarda le responsabilità dei partecipanti, piuttosto che la funzionalità dei moduli. Per questo motivo, le etichette utilizzate sono diverse da quelle utilizzate nei diagrammi classici dell'architettura di posta elettronica.

2.1. Attori utente​

Gli utenti sono le fonti e i destinatari dei messaggi. Gli utenti possono essere persone, organizzazioni o processi. Possono avere uno scambio che itera e possono espandere o contrarre l'insieme di utenti che partecipano a un insieme di scambi. Nella posta elettronica Internet, ci sono quattro tipi di utenti:

  • Autori (Authors)

  • Destinatari (Recipients)

  • Gestori dei ritorni (Return Handlers)

  • Mediatori (Mediators)

La Figura 2 mostra i flussi primari e secondari dei messaggi tra di loro. Come euristica pragmatica: gli attori utente possono generare, modificare o guardare l'intero messaggio.

         ++==========++
         ||  Author  ||<..................................<..
         ++=++=++=++=++                                     .
         || || ||     ++===========++                    .
         || || ++====>|| Recipient ||                    .
         || ||        ++=====+=====++                    .
         || ||               .                           .
         || ||               ..........................>.+
         || ||                                           .
         || ||               ...................         .
         || ||               .                 .         .
         || ||               V                 .         .
         || ||         +-----------+    ++=====+=====++  .
         || ++========>| Mediator  +===>|| Recipient ||  .
         ||            +-----+-----+    ++=====+=====++  .
         ||                  .                 .         .
         ||                  ..................+.......>.+
         ||                                              .
         ||    ..............+..................         .
         ||    .             .                 .         .
         \/    V             V                 '         .
         +-----------+    +-----------+    ++=====+=====++  .
         | Mediator  +===>| Mediator  +===>|| Recipient ||  .
         +-----+-----+    +-----+-----+    ++=====+=====++  .
               .                .                 .         .
               .................+.................+.......>..

        Legend: === lines indicate primary (possibly indirect)
                    transfers or roles
                ... lines indicate supporting transfers or roles

               Figure 2: Relationships among User Actors

Dal punto di vista dell'utente, tutte le attività di trasferimento dei messaggi sono eseguite da un servizio di gestione dei messaggi (MHS) monolitico, anche se il servizio effettivo può essere fornito da molte organizzazioni indipendenti. Gli utenti sono clienti di questo servizio unificato.

Ogni volta che un attore MHS invia informazioni a un autore o a un mittente (Originator) nella sequenza di gestione di un messaggio, tale attore è un utente.

2.1.1. Autore (Author)​

L'autore è responsabile della creazione del messaggio, del suo contenuto e dell'elenco degli indirizzi dei destinatari. L'MHS trasferisce il messaggio dall'autore e lo consegna ai destinatari. L'MHS ha un ruolo di mittente (Sezione 2.2.1) che è correlato al ruolo dell'autore.

2.1.2. Destinatario (Recipient)​

Il destinatario è un consumatore del messaggio consegnato. L'MHS ha un ruolo di ricevitore (Sezione 2.2.4) che è correlato al ruolo del destinatario. Questo è etichettato come Recv nella Figura 3.

Qualsiasi destinatario può chiudere il ciclo di comunicazione utente creando e inviando un nuovo messaggio che risponde all'autore. Un esempio di forma automatizzata di risposta è la notifica di disposizione del messaggio (Message Disposition Notification - MDN), che informa l'autore sulla gestione del messaggio da parte del destinatario. (Vedere la Sezione 4.1.)

2.1.3. Gestore dei ritorni (Return Handler)​

Chiamato anche "Bounce Handler", il gestore dei ritorni è una forma speciale di destinatario incaricato di gestire le notifiche generate dall'MHS mentre trasferisce o consegna il messaggio. (Vedere la Figura 3.) Questi avvisi possono riguardare fallimenti o completamenti e vengono inviati a un indirizzo specificato dal mittente. Questo indirizzo di gestione dei ritorni (noto anche come indirizzo di ritorno) potrebbe non avere caratteristiche visibili in comune con l'indirizzo dell'autore o del mittente.

2.1.4. Mediatore (Mediator)​

Un mediatore riceve, aggrega, riformula e ridistribuisce i messaggi tra autori e destinatari che sono i principali in scambi (potenzialmente) prolungati. Questa attività è facilmente confusa con gli scambi di trasferimento MHS sottostanti. Tuttavia, ciascuno serve scopi molto diversi e opera in modi molto diversi.

Quando la posta viene consegnata al mediatore specificato nel comando RFC5321.RcptTo per il messaggio originale, l'MHS la gestisce allo stesso modo di qualsiasi altro destinatario. In particolare, l'MHS vede ogni attività di invio e consegna tra fonti e destinatari come indipendente; non vede il successivo re-invio come una continuazione di un processo. Poiché il mediatore origina i messaggi, può ricevere risposte. Quindi, quando invia un messaggio riformulato, il mediatore è un autore, sebbene un autore che in realtà funge da agente di uno o più altri autori. Quindi un mediatore è davvero un utente a tutti gli effetti. I mediatori sono considerati ampiamente nella Sezione 5.

Un mediatore tenta di preservare le informazioni dell'autore originale nel messaggio che riformula, ma è autorizzato ad apportare modifiche significative al contenuto o alla busta del messaggio. L'MHS vede un nuovo messaggio, ma gli utenti ricevono un messaggio che interpretano come proveniente da, o almeno avviato da, l'autore del messaggio originale. Il ruolo di un mediatore non è limitato al semplice collegamento di altri partecipanti; il mediatore è responsabile del nuovo messaggio.

Il ruolo di un mediatore è complesso e contingente, ad esempio, modificando e aggiungendo contenuto o regolando quali utenti sono autorizzati a partecipare e quando. L'esempio comune di questo ruolo è una mailing list di gruppo. In un uso più complesso, una sequenza di mediatori potrebbe eseguire una sequenza di passaggi formali, come la revisione, la modifica e l'approvazione di una richiesta di acquisto.

Un gateway è una forma particolarmente interessante di mediatore. È un ibrido di utente e relè che collega servizi di posta eterogenei. Il suo scopo è emulare un relè. Per una discussione dettagliata, vedere la Sezione 2.2.3.

2.2. Attori del servizio di gestione dei messaggi (MHS)​

Il servizio di gestione dei messaggi (MHS) esegue un singolo trasferimento end-to-end per conto dell'autore per raggiungere gli indirizzi dei destinatari specificati nei comandi RFC5321.RcptTo originali. Gli scambi che sono mediati o iterativi e prolungati, come quelli utilizzati per la collaborazione nel tempo, sono gestiti dagli attori utente, non dagli attori MHS. Come euristica pragmatica, gli attori MHS generano, modificano o guardano solo i dati di trasferimento, piuttosto che l'intero messaggio.

La figura 3 mostra le relazioni tra i partecipanti al trasferimento in Internet Mail. Sebbene mostri l'Originatore (etichettato come Origin) distinto dall'Autore, e il Ricevitore (etichettato come Recv) distinto dal Destinatario, ogni coppia di ruoli ha solitamente lo stesso Attore. I trasferimenti comportano tipicamente uno o più Relay. Tuttavia, è possibile una consegna diretta dall'Originatore al Ricevitore. I servizi di posta intra-organizzativi hanno solitamente un solo Relay.

         ++==========++                        ++===========++
         ||  Author  ||                        || Recipient ||
         ++====++====++   +--------+           ++===========++
               ||         | Return |                  /\
               ||         +-+------+                  ||
               \/           .    ^                    ||
           +---------+      .    .                +---++---+
           |         |      .    .                |        |
        /--+---------+----------------------------+--------+----\
        |  |         |      .    .      MHS       |        |    |
        |  | Origin  +<......    .................+  Recv  |    |
        |  |         |           ^                |        |    |
        |  +---++----+           .                +--------+    |
        |      ||                .                    /\        |
        |      ||  ..............+..................  ||        |
        |      \/  .             .                 .  ||        |
        |  +-------+-+        +--+------+        +-+--++---+    |
        |  |  Relay  +=======>|  Relay  +=======>|  Relay  |    |
        |  +---------+        +----++---+        +---------+    |
        |                          ||                           |
        |                          ||                           |
        |                          \/                           |
        |                     +---------+                       |
        |                    | Gateway +-->...                  |
        |                     +---------+                       |
        \-------------------------------------------------------/

       Legend: === and || lines indicate primary (possibly
                   indirect) transfers or roles
               ... lines indicate supporting transfers or roles

               Figure 3: Relationships among MHS Actors

2.2.1. Originatore (Originator)​

L'Originatore garantisce che un messaggio sia valido per l'invio e quindi lo sottopone a un Relay. Un messaggio è valido se è conforme sia agli standard Internet Mail che alle politiche operative locali. L'Originatore può semplicemente rivedere il messaggio per verificarne la conformità e rifiutarlo se rileva errori, oppure può creare parte o tutte le informazioni necessarie. Di fatto, l'Originatore è responsabile delle funzioni dell'Agente di Invio Mail (Mail Submission Agent).

L'Originatore opera con duplice fedeltà. Serve l'Autore e può essere la stessa entità. Ma il suo ruolo nell'assicurare la validità significa che rappresenta anche l'operatore locale del MHS, ovvero il dominio di gestione amministrativa locale (ADministrative Management Domain - ADMD).

L'Originatore esegue inoltre qualsiasi attività amministrativa post-invio, relativa all'Autore e associata al trasferimento e alla consegna dei messaggi. In particolare, queste attività riguardano l'invio di avvisi di errore e di consegna, l'applicazione delle politiche locali e la gestione dei messaggi dell'Autore che si rivelano problematici per Internet. L'Originatore è responsabile del contenuto del messaggio, anche quando non ne è responsabile. L'Autore crea il messaggio, ma l'Originatore gestisce eventuali problemi di trasmissione con esso.

2.2.2. Relè (Relay)​

Il Relè esegue l'instradamento del servizio di trasferimento a livello MHS e lo store-and-forward trasmettendo o ritrasmettendo il messaggio ai suoi Destinatari. Il Relè aggiunge informazioni di tracciamento [RFC2505] ma non modifica le informazioni di busta né la semantica del contenuto del messaggio. Può modificare la rappresentazione del contenuto del messaggio, come cambiare la forma della codifica di trasferimento da binaria a testo, ma solo se richiesto per soddisfare le capacità del prossimo hop nel MHS.

Una rete di Message Handling System (MHS) consiste in un insieme di Relè. Questa rete si trova al di sopra di qualsiasi rete a commutazione di pacchetti sottostante che possa essere utilizzata e al di sotto di qualsiasi Gateway o altro Mediator.

In altre parole, gli scenari di posta elettronica possono comportare tre distinti livelli architetturali, ciascuno fornendo il proprio tipo di dati per il servizio di store-and-forward:

  • Mediator Utente (User Mediators)

  • Relè MHS (MHS Relays)

  • Commutatori di Pacchetti (Packet Switches)

Il livello inferiore è il servizio IP di Internet. Gli scenari di posta elettronica più elementari comportano Relè e Commutatori.

Quando un Relè smette di tentare di trasferire un messaggio, diventa un Autore perché invia un messaggio di errore all'indirizzo di ritorno (Return Address). Il potenziale di loop viene evitato omettendo un Return Address da questo messaggio.

2.2.3. Gateway​

Un Gateway è un ibrido di Utente e Relè che collega servizi di posta eterogenei. Il suo scopo è emulare un Relè e più si avvicina a ciò, meglio è. Un Gateway opera come Utente quando ha bisogno della capacità di modificare il contenuto del messaggio.

Le differenze tra i servizi di posta possono essere piccole come lievi variazioni sintattiche, ma di solito comprendono distinzioni semantiche significative. Una differenza potrebbe essere indirizzi email gerarchici e specifici della macchina anziché uno spazio dei nomi globale e piatto. Un'altra differenza potrebbe essere il supporto per contenuti solo testuali o multimediali. Pertanto la funzione di Relè in un Gateway presenta una sfida di progettazione significativa se le prestazioni risultanti devono apparire quasi continue. La sfida è garantire la funzionalità Utente-a-Utente tra i servizi, nonostante le differenze nella loro sintassi e semantica.

Il test di base della progettazione di un Gateway è se un Autore da un lato del Gateway può inviare un messaggio utile a un Destinatario dall'altro lato, senza richiedere modifiche a componenti dei servizi di posta dell'Autore o del Destinatario se non l'aggiunta del Gateway. Per ciascuno di questi servizi altrimenti indipendenti, il Gateway appare come un partecipante nativo. Ma il test ultimo della progettazione di un Gateway è se l'Autore e il Destinatario possono sostenere un dialogo. In particolare, il MUA di un Destinatario può formulare automaticamente una Risposta valida che raggiungerà l'Autore?

2.2.4. Ricevitore (Receiver)​

Il Ricevitore esegue la consegna finale o invia il messaggio a un indirizzo alternativo. Può anche eseguire filtraggio e altre applicazioni di policy immediatamente prima o dopo la consegna.

2.3. Attori Amministrativi​

Gli Attori Amministrativi possono essere associati a diverse organizzazioni, ciascuna con la propria autorità amministrativa. Questa indipendenza operativa, unita alla necessità di interazione tra i gruppi, fornisce la motivazione per distinguere tra i domini di gestione amministrativa (ADministrative Management Domains - ADMD). Ciascun ADMD può avere politiche operative molto diverse e processi decisionali basati sulla fiducia. Un esempio ovvio è la distinzione tra posta scambiata all'interno di un'organizzazione e posta scambiata tra organizzazioni indipendenti. Le regole per gestire entrambi i tipi di traffico tendono a essere piuttosto diverse. Tale differenza richiede di definire i confini di ciascuno, e ciò richiede il costrutto ADMD.

Il funzionamento dei servizi Internet Mail è effettuato da diversi fornitori (o operatori). Ciascuno può essere un ADMD indipendente. Questa indipendenza nelle decisioni amministrative definisce confini che distinguono diverse porzioni del servizio Internet Mail. Un dipartimento che gestisce un Relay locale, un dipartimento IT che gestisce un Relay aziendale e un ISP che gestisce un servizio di posta condiviso pubblico possono essere configurati in molte combinazioni di relazioni amministrative e operative. Ciascuno è un ADMD distinto, potenzialmente con un complesso insieme di componenti funzionali. La figura 4 illustra le relazioni tra gli ADMD. Il vantaggio del costrutto ADMD è che facilita la discussione su progetti, politiche e operazioni che devono distinguere tra questioni interne ed esterne.

L'impatto architetturale della necessità di confini tra gli ADMD è discusso in [Tussle]. Il più significativo è che le entità che comunicano attraverso i confini ADMD hanno tipicamente l'onere aggiuntivo di far rispettare le politiche organizzative riguardanti le comunicazioni esterne. A un livello più banale, l'instradamento della posta tra gli ADMD può essere un problema, come la necessità di instradare la posta tra partner organizzativi su percorsi specialmente attendibili.

Questi sono tre tipi di base di ADMD:

Edge: : Servizi di trasferimento indipendenti nelle reti al margine del servizio Internet Mail aperto.

Consumer: : Può essere un tipo di servizio Edge, come è comune per l'accesso email basato su web.

Transit: : Fornitori di Servizi di Posta (MSP) che offrono capacità a valore aggiunto per gli ADMD Edge, come aggregazione e filtraggio.

Il servizio di transito a livello di posta è diverso dalla commutazione a livello di pacchetto. I trasferimenti di pacchetti end-to-end passano solitamente attraverso router intermedi; lo scambio di email attraverso Internet aperto può essere direttamente tra i Boundary MTA degli ADMD Edge. Questa distinzione tra interazione diretta e indiretta evidenzia le differenze discusse nella Sezione 2.2.2.

       +--------+     +---------+     +-------+     +-----------+
       |  ADMD1 |<===>|  ADMD2  |<===>| ADMD3 |<===>|   ADMD4   |
       |  ----- |     |  -----  |     | ----- |     |   -----   |
       |        |     |         |     |       |     |           |
       | Author |     |         |     |       |     | Recipient |
       |   .    |     |         |     |       |     |     ^     |
       |   V    |     |         |     |       |     |     .     |
       |  Edge..+....>|.Transit.+....>|-Edge..+....>|..Consumer |
       |        |     |         |     |       |     |           |
       +--------+     +---------+     +-------+     +-----------+

       Legend: === lines indicate primary (possibly indirect)
                   transfers or roles
               ... lines indicate supporting transfers or roles

            Figure 4: Administrative Domain (ADMD) Example

Le reti Edge possono utilizzare standard di posta proprietari internamente. Tuttavia, la distinzione tra servizi di trasferimento di rete Transit e di rete Edge è significativa perché evidenzia la necessità di preoccuparsi dell'interazione e della protezione tra amministrazioni indipendenti. In particolare, questa distinzione richiede maggiore attenzione nel valutare le transizioni di responsabilità e le relazioni di responsabilità e autorizzazione tra i partecipanti al trasferimento dei messaggi.

Le interazioni dei componenti ADMD sono soggette alle politiche di quel dominio, che coprono preoccupazioni come queste:

  • Affidabilità (Reliability)

  • Controllo degli accessi (Access control)

  • Responsabilità (Accountability)

  • Valutazione e modifica dei contenuti (Content evaluation and modification)

Queste politiche possono essere implementate in diversi componenti funzionali, secondo le necessità dell'ADMD. Per esempio, vedere [RFC5068].

I servizi Consumer, Edge e Transit possono essere offerti da fornitori che operano servizi componenti o insiemi di servizi. Inoltre, è possibile che un ADMD ospiti servizi per altri ADMD.

Questi sono esempi comuni di ADMD:

Fornitori di Servizi Aziendali: : Questi ADMD gestiscono i dati interni e/o i servizi di posta all'interno di un'organizzazione.

Fornitori di Servizi Internet (ISP): : Questi ADMD gestiscono i servizi di comunicazione dati sottostanti, utilizzati da uno o più Relay e Utenti. Gli ISP non sono responsabili dell'esecuzione delle funzioni email, ma possono fornire un ambiente in cui tali funzioni possono essere eseguite.

Fornitori di Servizi di Posta: : Questi ADMD gestiscono servizi di posta elettronica, come per consumatori o aziende clienti.

Le preoccupazioni operative pratiche richiedono che i fornitori siano coinvolti in questioni di amministrazione e applicazione. Questo coinvolgimento può estendersi agli operatori di servizi di pacchetti di livello inferiore.