1. Introduzione

Nei suoi trentacinque anni di storia, la posta Internet è cambiata in modo significativo in termini di scala e complessità, diventando un servizio infrastrutturale globale. Questi cambiamenti sono stati evolutivi, piuttosto che rivoluzionari, riflettendo un forte desiderio di preservare sia la sua base installata che la sua utilità. Oggi, la posta Internet si distingue per molti operatori indipendenti, molti componenti diversi per fornire servizi agli utenti, nonché molti componenti diversi che trasferiscono messaggi.

Gli standard tecnici sottostanti per la posta Internet comprendono una ricca gamma di capacità funzionali. Queste specifiche formano il nucleo:

• Simple Mail Transfer Protocol (SMTP) ([RFC0821], [RFC2821], [RFC5321]) sposta un messaggio attraverso Internet.

• Internet Mail Format (IMF) ([RFC0733], [RFC0822], [RFC2822], [RFC5322]) definisce un oggetto messaggio.

• Multipurpose Internet Mail Extensions (MIME) [RFC2045] definisce un miglioramento dell'oggetto messaggio che consente l'uso di allegati multimediali.

La collaborazione pubblica su attività tecniche, operative e di policy della posta elettronica, comprese quelle che rispondono alle sfide dell'abuso della posta elettronica, ha portato una gamma molto più ampia di partecipanti nella comunità tecnica. Per collaborare in modo produttivo su questo sistema ampio e complesso, tutti i partecipanti devono lavorare da una visione comune di esso e utilizzare un linguaggio comune per descriverne i componenti e le interazioni tra di essi. Ma le molte differenze di prospettiva attualmente rendono difficile sapere esattamente cosa intende un altro partecipante.

È la necessità di risolvere queste differenze che motiva questo documento, che descrive le realtà del sistema attuale. La posta Internet è oggetto di lavori tecnici, operativi e di policy in corso e le discussioni sono spesso ostacolate da diversi modelli di progettazione del servizio di posta elettronica e diversi significati per gli stessi termini.

Per fungere da necessario quadro di riferimento comune, questo documento descrive l'architettura avanzata della posta Internet, riflettendo il servizio attuale. Il documento si concentra su:

• Catturare i perfezionamenti al modello di posta elettronica

• Chiarire i ruoli funzionali per i componenti architetturali

• Chiarire le questioni relative all'identità, attraverso il servizio di posta elettronica

• Definire la terminologia per i componenti architetturali e le loro interazioni

1.1. Storia

La prima architettura standardizzata per la posta elettronica in rete specificava una semplice divisione tra il mondo dell'utente, sotto forma di Message User Agent (MUA), e il mondo del trasferimento, sotto forma di Message Handling Service (MHS), che è composto da Message Transfer Agent (MTA) [RFC1506]. L'MHS accetta un messaggio da un utente e lo consegna a uno o più altri utenti, creando un ambiente di scambio virtuale MUA-to-MUA.

Come mostrato nella Figura 1, questa architettura definisce due livelli logici di interoperabilità. Uno è direttamente tra gli utenti. L'altro è tra i componenti lungo il percorso di trasferimento. Inoltre, c'è interoperabilità tra i livelli, prima quando un messaggio viene inviato dall'utente all'MHS e successivamente quando viene consegnato dall'MHS all'utente.

Il servizio operativo si è evoluto, sebbene gli aspetti fondamentali del servizio, come l'indirizzamento della casella di posta e lo stile del formato del messaggio, rimangano notevolmente costanti. La distinzione originale tra livello utente e livello di trasferimento rimane, ma con elaborazioni in ciascuno. Il termine "posta Internet" viene utilizzato per riferirsi all'intera raccolta di componenti e servizi utente e di trasferimento.

Per la posta Internet, il termine "end-to-end" si riferisce solitamente a un singolo invio e all'insieme di consegne che risultano da un singolo transito dell'MHS. Un'eccezione comune è il dialogo di gruppo mediato attraverso una mailing list; in questo caso, si verificano due invii prima che i destinatari previsti ricevano il messaggio di un autore, come discusso nella sezione 2.1.4. In effetti, alcuni usi della posta elettronica considerano l'intero servizio di posta elettronica, inclusi autore e destinatario, come un componente subordinato. Per questi servizi, "end-to-end" si riferisce a punti esterni al servizio di posta elettronica. Esempi sono voicemail su e-mail [RFC3801], EDI (Electronic Data Interchange) su e-mail [RFC1767] e facsimile su e-mail [RFC4142].

                                     +--------+
                  ++================>| Utente |
                  ||                 +--------+
                  ||                      ^
      +--------+  ||          +--------+  .
      | Utente +==++=========>| Utente |  .
      +---+----+  ||          +--------+  .
          .       ||               ^      .
          .       ||   +--------+  .      .
          .       ++==>| Utente |  .      .
          .            +--------+  .      .
          .                 ^      .      .
          .                 .      .      .
          V                 .      .      .
      +---+-----------------+------+------+---+
      |   .                 .      .      .   |
      |   .................>.      .      .   |
      |   .                        .      .   |
      |   ........................>.      .   |
      |   .                               .   |
      |   ...............................>.   |
      |                                       |
      |     Message Handling Service (MHS)    |
      +---------------------------------------+

      Legenda: === le linee indicano trasferimenti o ruoli
                   primari (possibilmente indiretti)
               ... le linee indicano trasferimenti o ruoli
                   di supporto

            Figura 1: Modello di base del servizio di posta Internet

Lo scambio di posta Internet end-to-end viene realizzato utilizzando un'infrastruttura standardizzata con questi componenti e caratteristiche:

• Un oggetto email

• Indirizzamento globale

• Una sequenza asincrona di meccanismi di trasferimento punto a punto

• Nessun requisito per accordi preventivi tra MTA o tra autori e destinatari

• Nessun requisito per accordi preventivi tra servizi di trasferimento punto a punto su Internet aperto

• Nessun requisito per l'autore, l'originatore o i destinatari di essere online contemporaneamente

La parte end-to-end del servizio è l'oggetto email, chiamato "messaggio". In generale, il messaggio stesso distingue le informazioni di controllo, per la gestione, dal contenuto dell'autore.

Un precetto per la progettazione della posta su Internet aperto è consentire l'interoperabilità User-to-User e MTA-to-MTA senza accordi preventivi e diretti tra le autorità amministrative indipendenti responsabili della gestione di un messaggio. Tutti i partecipanti si affidano all'avere i servizi principali universalmente supportati e accessibili, direttamente o tramite gateway che agiscono come traduttori tra la posta Internet e gli ambienti di posta elettronica conformi ad altri standard. Data l'importanza della spontaneità e della serendipità nelle comunicazioni interpersonali, non richiedere tale accordo preventivo tra i partecipanti è un vantaggio fondamentale della posta Internet e rimane un requisito fondamentale per essa.

All'interno delle reti localizzate ai margini dell'Internet pubblico, è spesso richiesto un accordo amministrativo preventivo e può includere controllo degli accessi, vincoli di instradamento e configurazione del servizio di query delle informazioni. Sebbene l'autenticazione del destinatario sia stata solitamente richiesta per l'accesso ai messaggi sin dall'inizio della posta Internet, negli ultimi anni è stata richiesta anche per l'invio dei messaggi. In questi casi, un server convalida l'identità del client, tramite protocolli di sicurezza espliciti o tramite query infrastrutturali implicite per identificare i partecipanti "locali".

1.2. Il ruolo di questa architettura

Un servizio Internet è un'integrazione di capacità correlate tra due o più nodi partecipanti. Le capacità vengono realizzate attraverso Internet da uno o più protocolli. Ciò che collega un protocollo a un servizio è un'architettura. Un'architettura specifica come i protocolli implementano il servizio definendo i componenti logici di un servizio e le relazioni tra di essi. Da quella visione logica, un servizio definisce cosa viene fatto, un'architettura definisce dove si trovano i pezzi (in relazione l'uno all'altro) e un protocollo definisce come vengono eseguite particolari capacità.

Come tale, un'architettura descriverà più formalmente un servizio a un livello relativamente alto. Un protocollo che implementa una parte di un servizio si conformerà all'architettura in misura maggiore o minore, a seconda dei compromessi pragmatici che fanno quando cercano di implementare l'architettura nel contesto dei vincoli del mondo reale. Il mancato rispetto preciso di un'architettura non è un fallimento del protocollo, né il mancato rispetto preciso di un protocollo è un fallimento dell'architettura. Laddove un protocollo varia dall'architettura, sarà ovviamente appropriato spiegarne il motivo della varianza. Tuttavia, tale varianza non è un segno contro un protocollo: fortunatamente, l'IETF preferisce il codice in esecuzione alla purezza architettonica.

In questo caso particolare, questa architettura tenta di definire i componenti logici della posta elettronica Internet e lo fa post hoc, cercando di catturare i principi architettonici che gli attuali protocolli di posta elettronica incarnano. In misura diversa, i protocolli di posta elettronica si conformeranno a questa architettura più o meno bene. Nella misura in cui questa architettura differisce da quei protocolli, le ragioni sono generalmente ben comprese e sono necessarie per l'interoperabilità. Le differenze non sono un segno che i protocolli devono essere corretti. Tuttavia, questa architettura è un miglior tentativo di un modello logico della posta elettronica Internet e, nella misura in cui lo sviluppo di nuovi protocolli varia da questa architettura, è necessario che i progettisti comprendano tali differenze e le spieghino attentamente.

1.3. Convenzioni del documento

I riferimenti ai campi strutturati di un messaggio utilizzano una notazione puntata in due parti. La prima parte cita il documento che contiene la specifica per il campo e la seconda parte è il nome del campo. Quindi <RFC5322.From> è il campo di intestazione IMF From: in un'intestazione di contenuto e-mail e <RFC5321.MailFrom> è l'indirizzo nel comando SMTP "Mail From".

Quando si verificano senza il qualificatore IMF (RFC 5322), i nomi dei campi di intestazione vengono visualizzati con un suffisso due punti. Ad esempio, From:.

I riferimenti alle etichette per attori, funzioni o componenti hanno la prima lettera maiuscola.