5. Mediatori
Il trasferimento di base dei messaggi dall'Autore ai Destinatari viene realizzato utilizzando un'infrastruttura di comunicazione asincrona di tipo store-and-forward in una sequenza di trasmissioni indipendenti attraverso un certo numero di MTA. Un compito molto diverso è una sequenza di pubblicazioni e consegne, attraverso Mediatori. Un Mediatore inoltra un messaggio attraverso un processo di ri-pubblicazione. Il Mediatore condivide alcune funzionalità con il relè MTA di base, ma ha maggiore flessibilità sia nell'indirizzamento che nel contenuto rispetto a quella disponibile per gli MTA.
Questo è l'insieme fondamentale di informazioni sui messaggi che viene comunemente impostato da tutti i tipi di Mediatori:
RFC5321.HELO/.EHLO: Impostato da - Mediatore Originatore
RFC3461.ENVID: Impostato da - Mediatore Originatore
RFC5321.RcptTo: Impostato da - Mediatore Autore
RFC5321.Received: Impostato da - Mediatore Destinatario
Il mediatore può registrare informazioni ricevute per indicare la consegna all'indirizzo originale e l'invio all'indirizzo alias. La traccia dei campi di intestazione Received: può includere tutto, dalla pubblicazione originale, attraverso il relay, fino alla consegna finale.
L'aspetto di un Mediatore che lo distingue da qualsiasi altro MUA che crea un messaggio è che un Mediatore preserva l'integrità e il tono del messaggio originale, inclusi aspetti essenziali delle sue informazioni di origine. Il Mediatore può anche aggiungere commenti.
Esempi di messaggi MUA che un Mediatore non crea includono:
Nuovo messaggio che Inoltra (Forwards) un messaggio esistente:
Sebbene questa azione fornisca un modello di base per una classe di Mediatori, la sua occorrenza tipica non è, di per sé, un esempio di Mediatore. Il nuovo messaggio è visto come proveniente dall'Attore che sta effettuando l'inoltro, piuttosto che dall'Autore originale.
Un nuovo messaggio incapsula il messaggio originale ed è visto come proveniente dal nuovo Originatore. Questo Mediatore Originatore può aggiungere commenti e può modificare il contenuto del messaggio originale. Poiché il messaggio inoltrato è un componente del messaggio inviato dal nuovo Originatore, il nuovo messaggio crea un nuovo dialogo. Tuttavia, il Destinatario finale vede ancora il messaggio contenuto come proveniente dall'Autore originale.
Risposta (Reply):
Quando un Destinatario risponde all'Autore di un messaggio, il nuovo messaggio non è normalmente visto come un inoltro dell'originale. Il suo focus è il nuovo contenuto, sebbene possa contenere tutto o parte del materiale del messaggio originale. Il materiale precedente è semplicemente contestuale e secondario. Questo include le risposte automatizzate, come gli avvisi di assenza dall'ufficio, come discusso nella Sezione 4.2.1.
Annotazione (Annotation):
L'integrità del messaggio originale è solitamente preservata, ma uno o più commenti sul messaggio vengono aggiunti in modo da distinguere il commento dal testo originale. Lo scopo principale del nuovo messaggio è fornire un commento da un nuovo Autore, simile a una Risposta.
Il resto di questa sezione descrive esempi comuni di Mediatori.
5.1. Alias
Una funzione di un MDA è determinare la posizione interna di una casella di posta per effettuare la consegna. Un Alias è una semplice funzione di reindirizzamento che fornisce uno o più nuovi indirizzi email Internet, piuttosto che un singolo indirizzo interno; il messaggio continua attraverso il servizio di trasferimento, per la consegna a uno o più indirizzi alternativi. Sebbene solitamente implementata come parte di un MDA, questa è una funzione del Destinatario. Essa re-invia il messaggio, sebbene tutte le informazioni di gestione, a parte l'indirizzo del Destinatario della busta (rfc5321.RcptTo), vengano conservate. In particolare, l'indirizzo di Ritorno (rfc5321.MailFrom) è invariato.
La particolarità di questo meccanismo di inoltro è quanto assomigli strettamente al normale relay store-and-forward degli MTA. La sua unica differenza significativa è che cambia il valore RFC5321.RcptTo. Poiché questo cambiamento è così piccolo, l'aliasing può essere visto come una parte dell'attività di relay di posta di basso livello. Tuttavia, questo piccolo cambiamento ha un grande impatto semantico: il Destinatario nominato ha scelto un nuovo Destinatario.
NOTA: Quando l'elenco di sostituzione include più di un indirizzo, l'alias ha crescenti probabilità di avere problemi di consegna. Qualsiasi rapporto di problema va all'Autore originale, non all'amministratore della voce alias. Ciò rende la risoluzione del problema più difficile, poiché l'Autore originale non ha conoscenza del meccanismo di Alias.
Includendo l'insieme fondamentale di informazioni sui messaggi elencato all'inizio di questa sezione, l'Alias tipicamente cambia:
RFC5322.To/.CC/.BCC: Impostato da - Autore
Questi campi conservano i loro indirizzi originali.
RFC5321.MailFrom: Impostato da - Autore
Il vantaggio di conservare il valore MailFrom originale è garantire che un Attore correlato all'ADMD di origine sappia che si è verificato un problema di consegna. D'altra parte, la responsabilità di gestire i problemi, durante il transito dalla casella di posta del Destinatario originale alla casella di posta alias, ricade solitamente su quel Destinatario originale, poiché il meccanismo di Alias è strettamente sotto il controllo di quel Destinatario. Conservare l'indirizzo MailFrom originale impedisce questo.
5.2. Ri-Speditore (ReSender)
Chiamato anche Re-Direttore (ReDirector), le azioni del Ri-Speditore differiscono dall'inoltro perché il Mediatore "unisce" le informazioni di indirizzamento di un messaggio per collegare l'Autore del messaggio originale con il Destinatario del nuovo messaggio. Questa connessione consente loro di avere uno scambio diretto, utilizzando le loro normali funzioni di risposta MUA, mentre registrano anche informazioni di riferimento complete sul Destinatario che ha agito come Mediatore. Quindi, il nuovo Destinatario vede il messaggio come proveniente dall'Autore originale, anche se il Mediatore aggiunge commenti.
Includendo l'insieme fondamentale di informazioni sui messaggi elencato all'inizio di questa sezione, queste identità sono rilevanti per un messaggio ri-spedito:
RFC5322.From: Impostato da - Autore originale
I nomi e gli indirizzi per l'Autore originale del contenuto del messaggio vengono conservati. La parte in forma libera (display-name) dell'indirizzo può essere modificata per fornire un riferimento informale al Ri-Speditore.
RFC5322.Reply-To: Impostato da - Autore originale
Se questo campo è presente nel messaggio originale, viene conservato nel messaggio ri-spedito.
RFC5322.Sender: Impostato da - Autore Originatore o Mediatore Originatore
RFC5322.To/.CC/.BCC: Impostato da - Autore originale
Questi campi specificano i destinatari del messaggio originale.
RFC5322.Resent-From: Impostato da - Mediatore Autore
Questo indirizzo è quello del Destinatario originale che sta reindirizzando il messaggio. Altrimenti, le stesse regole si applicano al campo Resent-From: come per un campo RFC5322.From originale.
RFC5322.Resent-Sender: Impostato da - Mediatore Originatore
L'indirizzo dell'Attore responsabile della ri-sottomissione del messaggio. Come con RFC5322.Sender, questo campo può essere omesso quando contiene lo stesso indirizzo di RFC5322.Resent-From.
RFC5322.Resent-To/-CC/-BCC: Impostato da - Mediatore Autore
Gli indirizzi dei nuovi Destinatari che sono ora in grado di rispondere all'Autore originale.
RFC5321.MailFrom: Impostato da - Mediatore Originatore
L'Attore responsabile della ri-sottomissione (RFC5322.Resent-Sender) è anche responsabile della specifica del nuovo indirizzo MailFrom.
5.3. Mailing List
Una Mailing List riceve messaggi come destinatario esplicito e poi li ri-pubblica a un elenco di membri iscritti. La Mailing List esegue un compito che può essere visto come un'elaborazione del Ri-Speditore. Oltre a inviare il nuovo messaggio a un numero potenzialmente elevato di nuovi Destinatari, la Mailing List può modificare il contenuto, ad esempio rimuovendo allegati, convertendo il formato e aggiungendo commenti specifici per la lista. Le Mailing List archiviano anche i messaggi pubblicati dagli Autori. Tuttavia, il messaggio conserva la caratteristica di provenire dall'Autore originale.
Includendo l'insieme fondamentale di informazioni sui messaggi elencato all'inizio di questa sezione, queste identità sono rilevanti per un elaboratore di Mailing List durante la sottomissione di un messaggio:
RFC2919.List-Id: Impostato da - Mediatore Autore
RFC2369.List-*: Impostato da - Mediatore Autore
RFC5322.From: Impostato da - Autore originale
I nomi e gli indirizzi email per l'Autore originale del contenuto del messaggio vengono conservati.
RFC5322.Reply-To: Impostato da - Mediatore o Autore originale
Sebbene problematico, è comune che una Mailing List assegni il proprio indirizzo al campo di intestazione Reply-To: dei messaggi che pubblica. Questa assegnazione intende garantire che le risposte vadano a tutti i membri della lista, piuttosto che solo all'Autore originale da solo. Come Attore Utente, una Mailing List è l'Autore del nuovo messaggio e può legittimamente impostare il valore Reply-To:. Come Mediatore che tenta di rappresentare il messaggio per conto del suo Autore originale, creare o modificare un campo Reply-To: può essere visto come una violazione dell'intento di quell'Autore. Quando il Reply-To viene modificato in questo modo, una risposta intesa solo per l'Autore originale andrà invece all'intera lista. Quando la Mailing List non imposta il campo, una risposta intesa per l'intera lista può invece andare solo all'Autore originale. Nel migliore dei casi, ogni scelta è una questione di cultura di gruppo per la particolare lista.
RFC5322.Sender: Impostato da - Autore Originatore o Mediatore Originatore
Questo campo specifica tipicamente l'indirizzo dell'Attore responsabile delle operazioni della Mailing List. Le mailing list che operano in modo simile a un semplice relay MTA conservano quante più informazioni di gestione originali possibili, incluso il campo RFC5322.Sender originale. (Si noti che questa modalità operativa fa sì che la Mailing List si comporti molto come un Alias, con una possibile differenza nel numero di nuovi destinatari.)
RFC5322.To/.CC: Impostato da - Autore originale
Questi campi di solito contengono l'elenco originale degli indirizzi dei destinatari.
RFC5321.MailFrom: Impostato da - Mediatore Originatore
Poiché una Mailing List può modificare il contenuto di un messaggio in qualsiasi modo, essa è responsabile di quel contenuto; cioè, è un Autore. Come tale, l'indirizzo di Ritorno è specificato dalla Mailing List. Sebbene sia plausibile per la Mailing List riutilizzare l'indirizzo di Ritorno impiegato dall'Originatore originale, le notifiche inviate a quell'indirizzo dopo che un messaggio è stato elaborato da una Mailing List potrebbero essere problematiche.
5.4. Gateway
Un Gateway esegue il lavoro di routing e trasferimento di base del relay dei messaggi, ma è anche autorizzato a modificare contenuto, struttura, indirizzo o attributi secondo necessità per inviare il messaggio in un ambiente di messaggistica che opera secondo standard diversi o politiche potenzialmente incompatibili. Quando un Gateway collega due diversi servizi di messaggistica, il suo ruolo è facile da identificare e comprendere. Quando collega ambienti che seguono standard tecnici simili, ma hanno politiche amministrative significativamente diverse, è facile considerare un Gateway semplicemente come un MTA.
La distinzione critica tra un MTA e un Gateway è che un Gateway può apportare modifiche sostanziali a un messaggio per mappare tra gli standard. In quasi tutti i casi, questa mappatura comporta un certo grado di perdita semantica. La sfida della progettazione del Gateway è ridurre al minimo questa perdita. I gateway standardizzati per la posta Internet sono fac-simile [RFC4143], segreteria telefonica [RFC3801] e servizio di messaggistica multimediale (MMS) [RFC4356].
Un Gateway può impostare qualsiasi campo di identità disponibile per un MUA. Includendo l'insieme fondamentale di informazioni sui messaggi elencato all'inizio di questa sezione, queste identità sono tipicamente rilevanti per i Gateway:
RFC5322.From: Impostato da - Autore originale
I nomi e gli indirizzi per l'Autore originale del contenuto del messaggio vengono conservati. Come per tutte le informazioni di indirizzamento originali nel messaggio, il Gateway può tradurre gli indirizzi secondo necessità per continuare a essere utili nell'ambiente di destinazione.
RFC5322.Reply-To: Impostato da - Autore originale
È meglio che un Gateway conservi queste informazioni, se presenti. La capacità di un Destinatario di eseguire una risposta con successo è un tipico test della funzionalità del Gateway.
RFC5322.Sender: Impostato da - Autore Originatore o Mediatore Originatore
Questo campo può conservare il valore originale o essere impostato su un nuovo indirizzo.
RFC5322.To/.CC/.BCC: Impostato da - Destinatario originale
Questi campi conservano tipicamente i loro indirizzi originali.
RFC5321.MailFrom: Impostato da - Autore Originatore o Mediatore Originatore
L'Attore responsabile della gestione del messaggio può specificare un nuovo indirizzo per ricevere notifiche sulla gestione.
5.5. Filtro di Confine (Boundary Filter)
Per imporre i confini di sicurezza, le organizzazioni possono sottoporre i messaggi ad analisi per verificarne la conformità con le loro politiche di sicurezza. Un esempio è il rilevamento di contenuti classificati come spam o virus. Un filtro può modificare il contenuto per renderlo sicuro, ad esempio rimuovendo il contenuto ritenuto inaccettabile. Tipicamente, queste azioni aggiungano contenuto al messaggio che registra le azioni.