4. Servizi e Standard

L'architettura della posta Internet comprende sei tipi base di funzionalità, che sono organizzati per supportare un servizio store-and-forward. Come mostrato nella Figura 5, ogni tipo può avere più istanze, alcune delle quali rappresentano ruoli specializzati. Questa sezione considera le attività e le relazioni tra questi componenti, nonché gli standard di posta Internet che si applicano ad essi.

• Messaggio (Message)
• Agente Utente del Messaggio (Message User Agent, MUA)
  • MUA Autore (Author MUA, aMUA)
  • MUA Destinatario (Recipient MUA, rMUA)
• Agente di Sottomissione del Messaggio (Message Submission Agent, MSA)
  • Funzioni MSA focalizzate sull'Autore (aMSA)
  • Funzioni MSA focalizzate sull'MHS (hMSA)
• Agente di Trasferimento del Messaggio (Message Transfer Agent, MTA)
• Agente di Consegna del Messaggio (Message Delivery Agent, MDA)
  • Funzioni MDA focalizzate sul Destinatario (rMDA)
  • Funzioni MDA focalizzate sull'MHS (hMDA)
• Archivio Messaggi (Message Store, MS)
  • MS Autore (aMS)
  • MS Destinatario (rMS)

Questa figura mostra i moduli funzionali e i protocolli standardizzati utilizzati tra di loro.

                 ++========++
                 ||        ||                             +-------+
      ...........++  aMUA  ||<............................+ Disp  |
      .          ||        ||                             +-------+
      .          ++=+==+===++                                 ^
      .  local,imap}|  |{smtp,submission                      .
      .  +-----+    |  |                          +--------+  .
      .  | aMS |<---+  | ........................>| Return |  .
      .  +-----+       | .                        +--------+  .
      .                | .    *****************       ^       .
      .          +-----V-.----*------------+  *       .       .
      .      MSA | +-------+  *   +------+ |  *       .       .
      .          | | aMSA  +-(S)->| hMSA | |  *       .       .
      .          | +-------+  *   +--+---+ |  *       .       .
      V          +------------*------+-----+  *       .       .
//==========\\                *      V {smtp  *       .       .
|| MESSAGE  ||                *   +------+    *  //===+===\\  .
||----------||            MHS *   | MTA  |    *  ||  dsn  ||  .
|| ENVELOPE ||                *   +--+---+    *  \\=======//  .
||  smtp    ||                *      V {smtp  *     ^   ^     .
|| CONTENT  ||                *   +------+    *     .   . //==+==\\
||  imf     ||                *   | MTA  +....*......   . || mdn ||
||  mime    ||                *   +--+---+    *         . \\=====//
\\==========//                * smtp}| {local *         .     ^
      .           MDA         *      | {lmtp  *         .     .
      .      +----------------+------V-----+  *         .     .
      .      | +----------+   *   +------+ |  *         .     .
      .      | |          |   *   |      | +..*..........     .
      .      | |   rMDA   |<-(D)--+ hMDA | |  *               .
      .      | |          |   *   |      | |<.*........       .
      .      | +-+------+-+   *   +------+ |  *       .       .
      .      +------+---------*------------+  *       .       .
      .  smtp,local}|         *****************       .       .
      .             V                                 .       .
      .          +-----+                         //===+===\\  .
      .          | rMS |                         || sieve ||  .
      .          +--+--+                         \\=======//  .
      .             |{imap,pop,local                  ^       .
      .             V                                 .       .
      .       ++==========++                          .       .
      .       ||          ||                          .       .
      .......>||   rMUA   ++...........................       .
              ||          ++...................................
              ++==========++

    Legenda: --- le linee indicano trasferimenti o ruoli primari (possibilmente indiretti)
             === i riquadri indicano oggetti dati
             ... le linee indicano trasferimenti o ruoli di supporto
             *** le linee indicano un servizio aggregato

                 Figura 5: Protocolli e Servizi

4.1. Dati del Messaggio

Lo scopo del Sistema di Gestione dei Messaggi (Message Handling System, MHS) è scambiare un oggetto messaggio IMF tra i partecipanti [RFC5322]. Tutti i suoi meccanismi sottostanti servono a consegnare quel messaggio dal suo Autore (Author) ai suoi Destinatari (Recipients). Un messaggio può essere esplicitamente etichettato per quanto riguarda la sua natura [RFC3458].

Un messaggio comprende una busta (envelope) di gestione del transito e il contenuto del messaggio. La busta contiene le informazioni utilizzate dall'MHS. Il contenuto è diviso in un'intestazione (header) strutturata e un corpo (body). L'intestazione comprende informazioni di tracciamento della gestione del transito e campi strutturati che fanno parte del contenuto del messaggio dell'Autore. Il corpo può essere costituito da righe di testo non strutturate o da un albero di oggetti subordinati multimediali, chiamati "parti del corpo" (body-parts) o, popolarmente, "allegati" (attachments). [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

Inoltre, la posta Internet ha alcune convenzioni per dati di controllo speciali, in particolare:

Notifica dello Stato di Consegna (Delivery Status Notification, DSN):

Una Notifica dello Stato di Consegna (DSN) è un messaggio che può essere generato dall'MHS (MSA, MTA o MDA) e inviato all'indirizzo RFC5321.MailFrom. L'MDA e l'MTA sono mostrati come fonti di DSN nella Figura 5, e la destinazione è mostrata come Return. Le DSN forniscono informazioni sul transito del messaggio, come errori nel trasferimento o consegna riuscita [RFC3461].

Notifica di Disposizione del Messaggio (Message Disposition Notification, MDN):

Una Notifica di Disposizione del Messaggio (MDN) è un messaggio che fornisce informazioni sull'elaborazione post-consegna, come l'indicazione che il messaggio è stato visualizzato [RFC3798] o la forma di contenuto che può essere supportata [RFC3297]. Può essere generata da un rMUA e viene inviata agli indirizzi Disposition-Notification-To. La casella di posta per questo è mostrata come Disp nella Figura 5.

Filtraggio dei Messaggi (SIEVE):

Sieve è un linguaggio di scripting utilizzato per specificare le condizioni per la gestione differenziata della posta, tipicamente al momento della consegna [RFC5228]. Gli script possono essere trasmessi in vari modi, ad esempio come parte MIME in un messaggio. La Figura 5 mostra uno script Sieve che va dall'rMUA all'MDA. Tuttavia, il filtraggio può essere effettuato in molti punti diversi lungo il percorso di transito, e uno qualsiasi o più di essi possono essere soggetti a direttive Sieve, specialmente all'interno di un singolo ADMD. La Figura 5 mostra solo una relazione, per (relativa) semplicità.

4.1.1. Busta (Envelope)

La posta Internet ha un framework frammentato per le informazioni di gestione relative al transito. Le informazioni utilizzate direttamente dall'MHS sono chiamate "busta". Dirigono le attività di gestione da parte del servizio di trasferimento e sono trasportate nei comandi del servizio di trasferimento. Cioè, la busta esiste nel protocollo di trasferimento SMTP [RFC5321].

Le informazioni di tracciamento, come RFC5322.Received, sono registrate nell'intestazione del messaggio e successivamente non vengono modificate [RFC5322].

4.1.2. Campi dell'Intestazione (Header Fields)

I campi dell'intestazione sono coppie nome/valore di attributo che coprono una gamma estensibile di parametri del servizio di posta elettronica, contenuto utente strutturato e meta-informazioni sulle transazioni utente. Il set principale di campi dell'intestazione è definito in [RFC5322]. È pratica comune estendere questo set per diverse applicazioni. Le procedure per la registrazione dei campi dell'intestazione sono definite in [RFC3864]. Un ampio set di registrazioni di campi di intestazione esistenti è fornito in [RFC4021].

Un pericolo nel posizionare informazioni aggiuntive nei campi dell'intestazione è che i gateway spesso le alterano o le eliminano.

4.1.3. Corpo (Body)

Il corpo di un messaggio può essere costituito da righe di testo ASCII o da una composizione strutturata gerarchicamente di allegati multimediali body-part utilizzando MIME ([RFC2045], [RFC2046], [RFC2047], [RFC4288], e [RFC2049]).

4.1.4. Riferimenti di Identità in un Messaggio

La Tabella 1 elenca gli identificatori principali presenti in un messaggio durante il transito.

Strato	Campo	Impostato da
Corpo del messaggio	Intestazione MIME	Autore (Author)
Campi Intestazione Messaggio	From:	Autore (Author)
	Sender:	Originatore (Originator)
	Reply-To:	Autore (Author)
	To:, CC:, BCC:	Autore (Author)
	Message-ID:	Originatore (Originator)
	Received:	Originatore, Relay, Ricevente
	Return-Path:	MDA, da MailFrom
	Resent-*:	Mediatore (Mediator)
	List-Id:	Mediatore (Mediator)
	List-*:	Mediatore (Mediator)
SMTP	HELO/EHLO	Ultimo Client Relay
	ENVID	Originatore (Originator)
	MailFrom	Originatore (Originator)
	RcptTo	Autore (Author)
	ORCPT	Originatore (Originator)
IP	Indirizzo Sorgente	Ultimo Client Relay

Legenda:

• Strato (Layer) - La parte dell'architettura di posta elettronica che utilizza l'identificatore.

• Campo (Field) - Il costrutto del protocollo che contiene l'identificatore.

• Impostato da (Set By) - Il ruolo dell'Attore responsabile della specifica del valore dell'identificatore (questo potrebbe essere diverso dall'Attore che esegue la funzione di riempimento per il costrutto del protocollo).

Tabella 1: Identità stratificate

Questi sono i campi relativi all'indirizzo più comuni:

RFC5322.From: Impostato da - Autore (Author)

I nomi e gli indirizzi degli Autori del contenuto del messaggio sono elencati nel campo From:.

RFC5322.Reply-To: Impostato da - Autore (Author)

Se un Destinatario invia un messaggio di risposta che altrimenti utilizzerebbe gli indirizzi del campo RFC5322.From nel messaggio originale, vengono invece utilizzati gli indirizzi nel campo RFC5322.Reply-To. In altre parole, questo campo sovrascrive il campo From: per le risposte dai Destinatari.

RFC5322.Sender: Impostato da - Originatore (Originator)

Questo campo specifica l'indirizzo responsabile della sottomissione del messaggio al servizio di trasferimento. Questo campo può essere omesso se contiene lo stesso indirizzo di RFC5322.From. Tuttavia, omettere questo campo non significa che non sia specificato alcun Mittente (Sender); significa che questo campo di intestazione è virtuale e che deve essere utilizzato l'indirizzo nel campo From:.

La specifica degli indirizzi di ritorno per le notifiche, contenuti in RFC5321.MailFrom, è fatta dall'RFC5322.Sender. Tipicamente, l'indirizzo di Ritorno è lo stesso dell'indirizzo del Mittente. Tuttavia, alcuni scenari di utilizzo richiedono che siano diversi.

RFC5322.To/.CC: Impostato da - Autore (Author)

Questi campi specificano gli indirizzi dei destinatari MUA. Tuttavia, alcuni o tutti gli indirizzi in questi campi potrebbero non essere presenti nei comandi RFC5321.RcptTo.

La distinzione tra To e CC è soggettiva. Generalmente, un destinatario To è considerato primario e ci si aspetta che intraprenda azioni sul messaggio. Un destinatario CC riceve tipicamente una copia per conoscenza.

RFC5322.BCC: Impostato da - Autore (Author)

Una copia del messaggio può essere inviata a un destinatario la cui partecipazione non deve essere rivelata ai destinatari RFC5322.To o RFC5322.CC e, di solito, neanche agli altri destinatari BCC. Il campo di intestazione BCC: indica una copia del messaggio a tale destinatario. L'uso di questo campo è discusso in [RFC5322].

RFC5321.HELO/.EHLO: Impostato da - Originatore, MSA, MTA

Qualsiasi client SMTP -- inclusi Originatore, MSA o MTA -- può specificare la propria identità di dominio di hosting per l'operazione del comando SMTP HELO o EHLO.

RFC3461.ENVID: Impostato da - Originatore (Originator)

L'MSA può specificare una stringa opaca, da includere in una DSN, come mezzo per assistere il destinatario dell'Indirizzo di Ritorno nell'identificare il messaggio che ha prodotto una DSN o il tracciamento del messaggio.

RFC5321.MailFrom: Impostato da - Originatore (Originator)

Questa è una stringa end-to-end che specifica un indirizzo email per ricevere informazioni di controllo di ritorno, come i messaggi respinti. Il nome di questo campo è fuorviante, perché non è necessario specificare né l'Autore né l'Attore responsabile della sottomissione del messaggio. Piuttosto, l'Attore responsabile della sottomissione specifica l'indirizzo RFC5321.MailFrom. In definitiva, la semplice base per decidere quale indirizzo deve essere nel campo RFC5321.MailFrom è determinare quale indirizzo deve essere informato sui problemi a livello di trasferimento (e possibilmente sui successi).

RFC5321.RcptTo: Impostato da - Autore, MTA Finale, MDA

Questo campo specifica l'indirizzo della casella di posta MUA di un destinatario. La stringa potrebbe non essere visibile nell'intestazione del contenuto del messaggio. Ad esempio, i campi di intestazione dell'indirizzo di destinazione IMF, come RFC5322.To, potrebbero specificare una casella di posta di una mailing list, mentre l'indirizzo RFC5321.RcptTo specifica un membro di quella lista.

RFC5321.ORCPT: Impostato da - Originatore (Originator)

Questo è un parametro opzionale per il comando RCPT, che indica l'indirizzo originale a cui corrisponde l'attuale indirizzo RCPT TO, dopo che è stata eseguita una mappatura durante il transito. Un ORCPT è l'unico modo affidabile per correlare una DSN da un trasferimento di messaggi multi-destinatario con il destinatario previsto.

RFC5321.Received: Impostato da - Originatore, Relay, Mediatore, Dest

Questo campo contiene informazioni di tracciamento, inclusi host di origine, relay, mediatori e nomi di dominio host MSA e/o indirizzi IP.

RFC5321.Return-Path: Impostato da - Originatore (Originator)

L'MDA registra l'indirizzo RFC5321.MailFrom nel campo RFC5321.Return-Path.

RFC2919.List-Id: Impostato da - Mediatore, Autore

Questo campo fornisce un framework di denominazione delle mailing list unico a livello globale, indipendente da host particolari [RFC2919].

L'identificatore è nella forma di un nome di dominio; tuttavia, la stringa è solitamente costruita combinando le due parti di un indirizzo email. Il risultato è raramente un vero nome di dominio, elencato nel Domain Name Service, sebbene possa esserlo.

RFC2369.List-*: Impostato da - Mediatore, Autore

[RFC2369] definisce una raccolta di campi di intestazione del messaggio da utilizzare nelle mailing list. In effetti, forniscono parametri specifici per la lista per le comuni operazioni degli utenti delle mailing list. Gli identificatori per queste operazioni sono per la lista stessa e per l'utente come iscritto [RFC2369].

RFC0791.SourceAddr: Impostato da - L'host mittente SMTP Client che precede immediatamente l'attuale server SMTP ricevente

[RFC0791] definisce l'unità di base del trasferimento dati per Internet: il datagramma IP. Contiene un campo Indirizzo Sorgente che specifica l'indirizzo IP dell'host (interfaccia) da cui è stato inviato il datagramma. Questa informazione è impostata e fornita dal livello IP, rendendola indipendente dai meccanismi a livello di posta. Come tale, è spesso considerata autorevole, sebbene sia possibile fornire indirizzi falsi.

4.2. Servizi a Livello Utente

Le interazioni a livello utente coinvolgono scambi di protocollo, distinti da quelli che avvengono ai livelli inferiori dell'architettura MHS della posta Internet, che è, a sua volta, al di sopra del livello di trasporto Internet. Poiché la motivazione per la posta elettronica, e gran parte del suo utilizzo, è l'interazione tra persone, la natura e i dettagli di questi scambi di protocollo sono spesso determinati dalle esigenze della comunicazione interpersonale e di gruppo. Per accogliere il comportamento idiosincratico inerente a tale comunicazione, possono essere offerte solo linee guida soggettive, piuttosto che regole rigide, per alcuni aspetti del comportamento del sistema. Le mailing list forniscono esempi particolarmente salienti.

4.2.1. Agente Utente del Messaggio (MUA)

Un Agente Utente del Messaggio (MUA) lavora per conto degli Attori Utente e delle applicazioni Utente. È il loro rappresentante all'interno del servizio di posta elettronica.

L'MUA Autore (aMUA) crea un messaggio ed esegue la sottomissione iniziale nell'infrastruttura di trasferimento tramite un Agente di Sottomissione del Messaggio (MSA). Può anche eseguire qualsiasi archiviazione al momento della creazione e pubblicazione nel suo Archivio Messaggi (aMS). Un MUA aMS può organizzare i messaggi in molti modi diversi. Un modello comune utilizza aggregazioni, chiamate "cartelle"; in IMAP, sono chiamate "caselle di posta". Questo modello consente una cartella per i messaggi in fase di sviluppo (Bozze), una cartella per i messaggi in attesa di essere inviati (In coda o Non inviati) e una cartella per i messaggi che sono stati pubblicati con successo per il trasferimento (Inviati). Ma nessuna di queste cartelle è obbligatoria. Ad esempio, IMAP consente di memorizzare le bozze in qualsiasi cartella, quindi non è necessario che sia presente alcuna cartella Bozze.

L'MUA Destinatario (rMUA) lavora per conto del Destinatario per elaborare la posta ricevuta. Questa elaborazione include la generazione di messaggi di controllo disposizione a livello utente, la visualizzazione e la disposizione del messaggio ricevuto, e la chiusura o l'espansione del ciclo di comunicazione utente avviando risposte e inoltrando nuovi messaggi.

NOTA: Sebbene non mostrato nella Figura 5, un MUA stesso può avere un'implementazione distribuita, come un modulo di interfaccia utente "leggero" su un dispositivo vincolato come uno smartphone, con la maggior parte della funzionalità MUA in esecuzione in remoto su un server più capace. Un esempio di tale architettura potrebbe utilizzare IMAP [RFC3501] per la maggior parte delle interazioni tra un client MUA e un server MUA. Un approccio per tali scenari è definito da [RFC4550].

Un Mediatore è una classe speciale di MUA. Esegue la ri-pubblicazione dei messaggi, come indicato nella Sezione 2.1.

Un MUA può essere automatizzato, per conto di un Utente che non è presente nel momento in cui l'MUA è attivo. Un esempio è un servizio di invio massivo che ha una funzione di avvio temporizzato. Questi servizi non devono essere confusi con un Mediatore di mailing list, poiché non c'è alcun messaggio in arrivo che attiva l'attività del servizio automatizzato.

Un MUA popolare e problematico è un risponditore automatico, come uno che invia avvisi di assenza dall'ufficio. Questo comportamento potrebbe essere confuso con quello di un Mediatore, ma questo MUA sta generando un nuovo messaggio. I risponditori automatici possono infastidire gli Utenti delle mailing list a meno che non seguano [RFC3834].

I campi di identità sono rilevanti per un tipico MUA:

• RFC5322.From

• RFC5322.Reply-To

• RFC5322.Sender

• RFC5322.To, RFC5322.CC

• RFC5322.BCC

4.2.2. Archivio Messaggi (MS)

Un MUA può utilizzare un archivio messaggi (MS) a lungo termine. La Figura 5 raffigura l'MS di un Autore (aMS) e l'MS di un Destinatario (rMS). Un MS può essere situato su un server remoto o sulla stessa macchina dell'MUA.

Un MS acquisisce messaggi da un MDA o in modo proattivo tramite un meccanismo locale o anche tramite un meccanismo standardizzato come SMTP(!), o in modo reattivo utilizzando POP o IMAP. L'MUA accede all'MS o tramite un meccanismo locale o utilizzando POP o IMAP. L'uso di POP per accessi a singoli messaggi, piuttosto che per il trasferimento in blocco, è relativamente raro e inefficiente.

4.3. Servizi a Livello MHS

4.3.1. Agente di Sottomissione del Messaggio (MSA)

Un Agente di Sottomissione del Messaggio (MSA) accetta il messaggio inviato dall'aMUA e applica le politiche dell'ADMD ospitante e i requisiti degli standard Internet. Un MSA rappresenta un'insolita dicotomia funzionale. Rappresenta gli interessi dell'Autore (aMUA) durante la pubblicazione del messaggio, per facilitare il successo della pubblicazione; rappresenta anche gli interessi dell'MHS. Nell'architettura, queste responsabilità sono modellate, come mostrato nella Figura 5, dividendo l'MSA in due sottocomponenti, aMSA e hMSA, rispettivamente. Il trasferimento di responsabilità per un singolo messaggio, dall'ambiente di un Autore all'MHS, è chiamato "pubblicazione (posting)". Nella Figura 5, è contrassegnato come la transizione (S), all'interno dell'MSA.

L'hMSA si assume la responsabilità di transito per un messaggio conforme agli standard Internet pertinenti e alle politiche del sito locale. Rifiuta i messaggi non conformi. L'MSA esegue la preparazione finale del messaggio per la sottomissione ed effettua il trasferimento di responsabilità all'MHS, tramite l'hMSA. La quantità di preparazione dipende dalle implementazioni locali. Esempi di compiti aMSA includono l'aggiunta di campi di intestazione, come Date: e Message-ID:, e la modifica di parti del messaggio dalle notazioni locali agli standard Internet, come l'espansione di un indirizzo alla sua rappresentazione formale IMF.

Storicamente, le pubblicazioni di messaggi MUA/MSA basate su standard hanno utilizzato SMTP [RFC5321]. Lo standard attualmente preferito è SUBMISSION [RFC4409]. Sebbene SUBMISSION derivi da SMTP, utilizza una porta TCP separata e impone requisiti distinti, come l'autorizzazione all'accesso.

Queste identità sono rilevanti per l'MSA:

• RFC5321.HELO/.EHLO

• RFC3461.ENVID

• RFC5321.MailFrom

• RFC5321.RcptTo

• RFC5321.Received

• RFC0791.SourceAddr

4.3.2. Agente di Trasferimento del Messaggio (MTA)

Un Agente di Trasferimento del Messaggio (MTA) inoltra la posta per un "hop" a livello applicativo. È come uno switch di pacchetto o un router IP in quanto il suo compito è effettuare valutazioni di routing e spostare il messaggio più vicino ai destinatari. Naturalmente, gli oggetti di posta elettronica sono tipicamente molto più grandi del payload di un pacchetto o datagramma e le latenze end-to-end sono tipicamente molto più elevate. L'inoltro viene eseguito da una sequenza di MTA finché il messaggio non raggiunge un MDA di destinazione. Quindi, un MTA implementa sia la funzionalità client che server MTA; non modifica gli indirizzi nella busta né riformula il contenuto editoriale. Un cambio di forma dei dati, come la codifica di trasferimento del contenuto MIME (Content-Transfer-Encoding), rientra nell'ambito di competenza di un MTA, ma la rimozione o la sostituzione del contenuto del corpo no. Un MTA aggiunge anche informazioni di tracciamento [RFC2505].

NOTA: All'interno di un ADMD di destinazione, i moduli di inoltro di posta elettronica possono apportare varie modifiche al messaggio, prima della consegna. In tali casi, questi moduli agiscono come Gateway, piuttosto che come MTA.

La posta Internet utilizza SMTP ([RFC5321], [RFC2821], [RFC0821]) principalmente per effettuare trasferimenti punto-punto tra MTA peer. Altri meccanismi di trasferimento includono Batch SMTP [RFC2442] e On-Demand Mail Relay (ODMR) SMTP [RFC2645]. Come per la maggior parte dei meccanismi del livello di rete, l'SMTP della posta Internet supporta un livello di base di affidabilità, prevedendo la ritrasmissione dopo un fallimento temporaneo del trasferimento. A differenza dei tipici switch di pacchetto (e dei servizi di messaggistica istantanea), ci si aspetta che gli MTA della posta Internet memorizzino i messaggi in modo da consentire il recupero attraverso interruzioni del servizio, come lo spegnimento del sistema host. Il grado di tale robustezza e persistenza da parte di un MTA può variare. La specifica SMTP di base fornisce un framework per i codici di risposta del protocollo. Un miglioramento estensibile di questo framework è definito in [RFC5248].

Sebbene molto basilare, il meccanismo di routing dominante per la posta Internet è il record DNS MX [RFC1035], che specifica un MTA attraverso il quale è possibile raggiungere il dominio interrogato. Questo meccanismo presume una dorsale (backbone) pubblica, o almeno comune, che consente a qualsiasi MTA collegato di connettersi a qualsiasi altro.

Gli MTA possono svolgere uno di questi ruoli ben consolidati:

MTA di Confine (Boundary MTA):

Un MTA che fa parte di un ADMD e interagisce con MTA in altri ADMD. Questo è anche chiamato MTA Border. Potrebbero esserci diversi MTA di Confine, a seconda della direzione del flusso di posta.

MTA in Uscita (Outbound MTA): Un MTA che inoltra messaggi ad altri ADMD.

MTA in Entrata (Inbound MTA): Un MTA che riceve messaggi SMTP in entrata da relay MTA in altri ADMD, ad esempio, un MTA in esecuzione sull'host elencato come destinazione di un record MX.

MTA Finale (Final MTA):

L'MTA che trasferisce un messaggio all'MDA.

Queste identità sono rilevanti per l'MTA:

• RFC5321.HELO/.EHLO

• RFC3461.ENVID

• RFC5321.MailFrom

• RFC5321.RcptTo

• RFC5322.Received: Impostato da - Server Relay

• RFC0791.SourceAddr

4.3.3. Agente di Consegna del Messaggio (MDA)

Un trasferimento di responsabilità dall'MHS all'ambiente di un Destinatario (casella di posta) è chiamato "consegna (delivery)". Nell'architettura, come illustrato nella Figura 5, la consegna avviene all'interno di un Agente di Consegna del Messaggio (MDA) ed è indicata come una transizione (D) dal componente MDA orientato all'MHS (hMDA) al componente MDA orientato al Destinatario (rMDA).

Un MDA può fornire funzionalità distintive, basate sull'indirizzo, rese possibili dalle sue informazioni dettagliate sulle proprietà dell'indirizzo di destinazione. Queste informazioni possono anche essere presenti altrove nell'ADMD del Destinatario, come in un Relay di Confine (Boundary) organizzativo. Tuttavia, sono richieste per l'MDA, non foss'altro perché l'MDA deve sapere dove consegnare il messaggio.

Come un MSA, un MDA svolge due ruoli, come mostrato nella Figura 5. Il trasferimento formale di responsabilità, chiamato "consegna", è effettuato tra i due componenti che incarnano questi ruoli ed è indicato come "(D)" nella Figura 5. La parte MHS (hMDA) funziona principalmente come un motore server SMTP. Un ruolo aggiuntivo comune è reindirizzare il messaggio a un indirizzo alternativo, come specificato nelle preferenze del destinatario. Il compito della parte Destinatario dell'MDA (rMDA) è eseguire qualsiasi azione di consegna specificata dal Destinatario.

Il trasferimento nell'MDA è realizzato mediante un normale meccanismo di trasferimento MTA. Il trasferimento da un MDA a un MS utilizza un protocollo di accesso, come POP o IMAP.

NOTA: Il termine "consegna" può riferirsi alla funzione formale MHS specificata qui o alla prima volta che un messaggio viene visualizzato a un Destinatario. Un test semplice e pratico per verificare se si applica la definizione basata su MHS è vedere se può essere generata una DSN.

Queste identità sono rilevanti per l'MDA:

RFC5321.Return-Path: Impostato da - Autore Originatore o Mediatore Originatore

L'MDA registra l'indirizzo RFC5321.MailFrom nel campo RFC5321.Return-Path.

RFC5322.Received: Impostato da - Server MDA

Un MDA può registrare un campo di intestazione Received: per indicare informazioni di tracciamento, inclusi nomi di dominio host sorgente e ricevente e/o indirizzi IP.

4.4. Modalità di Transizione

Dal sito di origine al punto di consegna, la posta Internet segue solitamente un modello "push". Cioè, l'Attore che detiene il messaggio avvia il trasferimento alla posizione successiva, tipicamente con SMTP [RFC5321] o il Protocollo di Trasferimento Posta Locale (LMTP) [RFC2033]. Con un modello "pull", l'Attore che detiene il messaggio attende che l'Attore nella posizione successiva avvii una richiesta di trasferimento. I meccanismi standardizzati per il trasferimento MHS basato su pull sono ETRN [RFC1985] e ODMR [RFC2645].

Dopo la consegna, l'MUA (o MS) del Destinatario può ottenere accesso facendosi spingere (push) il messaggio o facendo sì che il ricevitore dell'accesso tiri (pull) il messaggio, ad esempio utilizzando POP [RFC1939] e IMAP [RFC3501].

4.5. Implementazione e Operatività

Una discussione su qualsiasi architettura di sistema interessante spesso si impantana quando si confondono architettura e implementazione. Un'architettura definisce le funzioni concettuali di un servizio, divise in moduli concettuali discreti. Un'implementazione di quell'architettura può combinare o separare componenti architettonici, a seconda delle esigenze di un particolare ambiente operativo. Ad esempio, un sistema software che esegue principalmente l'inoltro di messaggi è un MTA, ma può anche includere funzionalità MDA. Questo stesso sistema MTA potrebbe essere in grado di interfacciarsi con servizi di posta elettronica non Internet e quindi agire sia come MTA che come Gateway.

Allo stesso modo, i moduli implementati possono essere configurati per formare elaborazioni dell'architettura. Un esempio interessante è un MS distribuito. Una parte potrebbe essere un server remoto e un'altra parte potrebbe essere locale all'MUA. Come discusso in [RFC1733], esistono tre relazioni operative tra tali MS:

Online:

L'MS è remoto e i messaggi sono accessibili solo quando l'MUA è collegato all'MS in modo che l'MUA recuperi di nuovo tutto o parte di un messaggio da una sessione all'altra.

Offline:

L'MS è locale all'Utente e i messaggi vengono completamente spostati da qualsiasi archivio remoto, piuttosto che essere (anche) conservati lì.

Disconnesso (Disconnected):

Un rMS e un uMS sono mantenuti sincronizzati, per tutto o parte del loro contenuto, mentre sono collegati. Quando sono disconnessi, la posta può arrivare all'rMS e l'Utente può apportare modifiche all'uMS. I due archivi vengono risincronizzati quando vengono ricollegati.