Conversione del contenuto in Exchange Server

SI APPLICA A:2016 2019 Subscription Edition

La conversione del contenuto è il processo che consente di formattare correttamente un messaggio in base al destinatario. La decisione di eseguire la conversione del contenuto su un messaggio dipende dalla destinazione e dal formato del messaggio in fase di elaborazione. I tipi di conversione del contenuto che si verificano in Exchange 2016 ed Exchange 2019 sono invariati rispetto a Exchange 2013:

• Conversione dei messaggi per destinatari esterni: questo tipo di conversione del contenuto include le opzioni di conversione TNEF (Transport Neutral Encapsulation Format) e le opzioni di codifica dei messaggi per i destinatari esterni. I messaggi inviati ai destinatari all'interno dell'organizzazione di Exchange non richiedono questo tipo di conversione del contenuto. Questo tipo di conversione del contenuto viene gestito dal classificatore nel servizio Trasporto sul server Cassette postali. La classificazione di ogni messaggio avviene non appena un nuovo messaggio viene inserito nella coda di invio. Sul messaggio, oltre alla risoluzione dei destinatari e del routing e prima del suo inserimento nella coda di recapito, viene eseguita la conversione del contenuto. Se un singolo messaggio contiene più destinatari, il classificatore del contenuto determina la codifica appropriata per ciascun destinatario dei messaggi. Questa funzionalità non acquisisce alcun errore di conversione del contenuto rilevato dal classificatore durante la conversione di messaggi inviati a destinatari esterni.

• Conversione MAPI per destinatari interni: questo tipo di conversione del contenuto viene gestito dal servizio Trasporto cassette postali. Il servizio Trasporto cassette postali è presente nei server Cassette postali per trasmettere i messaggi tra i database delle cassette postali sul server locale e il servizio Trasporto nei server Cassette postali. In modo particolare il servizio Invio Trasporto cassette postali trasmette i messaggi dalla casella della posta in uscita del mittente al servizio Trasporto su un server Cassette postali. Il servizio Recapito Trasporto cassette postali trasmette i messaggi dal servizio Trasporto su un server Cassette postali alla casella di posta in arrivo del destinatario. Il servizio Invio Trasporto cassette postali converte tutti i messaggi in uscita da MAPI e il servizio Recapito Trasporto cassette postali converte tutti i messaggi in entrata in MAPI. L'analisi della conversione del contenuto consente di acquisire questi errori di conversione MAPI. Per ulteriori informazioni, vedere Managing Content Conversion Tracing.

Formati dei messaggi Exchange e Outlook

Nel seguente elenco sono descritti i formati di base dei messaggi disponibili in Exchange e Outlook:

• Testo normale: un messaggio di testo normale usa solo testo US-ASCII come descritto in RFC 5322. Il messaggio non può contenere caratteri diversi o altri formati di testo. Per un messaggio di testo normale possono essere utilizzati i seguenti due formati:

  • Le intestazioni e il corpo dei messaggi sono costituiti da testo US-ASCII. Gli allegati devono essere codificati con Uuencode. Uuencode è l'abbreviazione di "Unix-to-Unix encoding" e definisce un algoritmo di codifica che consente di memorizzare allegati binari nel corpo di un messaggio di posta elettronica utilizzando caratteri di testo US-ASCII.

  • Il messaggio è con codifica MIME con un valore Content-Type pari text/plaina e un valore Content-Transfer-Encoding per le parti di 7bit testo di un messaggio multiparte. Tutti gli allegati sono codificati con Quoted-Printable o Base64. Per impostazione predefinita, quando si compone e si invia un messaggio di testo normale in Outlook, il messaggio viene codificato con MIME con un valore Content-Type pari atext/plain.

• HTML: un messaggio HTML supporta la formattazione del testo, le immagini di sfondo, le tabelle, i punti elenco e altri elementi grafici. Per definizione, un messaggio in formato HTML deve esse codificato in base allo standard MIME per preservare questi elementi di formattazione.

• RTF (Rich Text Format): RTF supporta la formattazione del testo e altri elementi grafici. RTF è sinonimo di TNEF (TNEF e RTF possono essere usati in modo intercambiabile). Il formato dei messaggi RTF è completamente diverso dal formato di documento RTF disponibile in Word.

• TNEF: il formato di incapsulamento neutro del trasporto è un formato specifico di Microsoft per incapsulare le proprietà dei messaggi MAPI. Un messaggio TNEF contiene una versione di testo normale del messaggio e un allegato binario che riunisce la versione formattata originale del messaggio. Di solito, questo allegato è denominato Winmail.dat. L'allegato Winmail.dat include le informazioni seguenti:

  • La versione formattata originale del messaggio (ad esempio, tipi di carattere, dimensioni del testo e colori del testo)
  • Gli oggetti OLE (ad esempio, le immagini incorporate o i documenti Office incorporati)
  • Funzionalità speciali di Outlook, (ad esempio moduli personalizzati, pulsanti di voto o convocazioni di riunione)
  • Allegati normali che si trovavano nel messaggio originale

  Il messaggio di testo normale risultante può essere rappresentato nei seguenti formati:

  • Un messaggio conforme a RFC 5322 composto solo da testo US-ASCII con un allegato Winmail.dat con codifica Uuencode
  • Un messaggio con codifica MIME multipart con un allegato Winmail.dat

  Outlook e altri client di posta elettronica che leggono perfettamente il formato TNEF, elaborano l'allegato Winmail.dat e visualizzano il contenuto del messaggio originale senza visualizzare l'allegato Winmail.dat. Un client di posta elettronica che non legge il formato TNEF può presentare un messaggio TNEF nei seguenti modi:

  • Viene visualizzata la versione in testo normale del messaggio e il messaggio contiene un allegato denominato Winmail.dat, Win.dat o un altro nome generico, ad esempio Att nnnnn.dat o Att nnnnn.eml dove il segnaposto nnnnn rappresenta un numero casuale.
  • Viene visualizzata la versione in testo normale del messaggio. L'allegato TNEF viene ignorato o rimosso. Ne risulta un messaggio di testo normale.
  • I server di messaggistica che leggono il formato TNEF possono essere configurati per la rimozione degli allegati TNEF dai messaggi in arrivo. Ne risulta un messaggio di testo normale. Inoltre, alcuni client di posta elettronica possono non riuscire a leggere il formato TNEF, ma sono in grado di riconoscere e ignorare gli allegati in tale formato. Ne risulta un messaggio di testo normale.

  Alcune utilità di terze parti sono in grado di convertire gli allegati Winmail.dat.

  TNEF viene letto da tutte le versioni di Exchange a partire da Exchange Server versione 5.5.

• Summary Transport Neutral Encapsulation Format (STNEF): STNEF equivale a TNEF. Tuttavia, i messaggi STNEF sono codificati in modo diverso rispetto ai messaggi TNEF. In particolare, i messaggi STNEF sono sempre codificati con MIME e hanno sempre il valore BinaryContent-Transfer-Encoding . Quindi non è presente alcuna rappresentazione in testo normale del messaggio e il corpo del messaggio non contiene alcun allegato Winmail.dat distinto. L'intero messaggio è rappresentato utilizzando solo dati binari. I messaggi che utilizzano il valore Content-Transfer-Encoding di Binary possono essere trasferiti solo tra server di messaggistica SMTP che supportano e annunciano le estensioni BINARYMIME e CHUNKING secondo quanto definito in RFC 3030. I messaggi vengono trasferiti tra i server di messaggistica utilizzando sempre il comando BDAT, al posto del comando DATA standard.

  STNEF è riconosciuto da tutte le versioni di Exchange a partire da Exchange 2000. STNEF viene usato automaticamente per tutti i messaggi trasferiti tra i server Exchange nell'organizzazione dalla modalità nativa Exchange Server 2003.

  Exchange non invia mai messaggi STNEF a destinatari esterni. Solo i messaggi TNEF possono essere inviati a destinatari esterni all'organizzazione di Exchange.

Opzioni di conversione del contenuto per destinatari esterni

Le opzioni di conversione del contenuto impostabili in un'organizzazione di Exchange possono essere raggruppate nelle seguenti categorie:

• Opzioni di conversione TNEF: queste opzioni di conversione specificano se TNEF deve essere conservato o rimosso dai messaggi che lasciano l'organizzazione di Exchange.
• Opzioni di codifica dei messaggi: queste opzioni specificano le opzioni di codifica dei messaggi, ad esempio i set di caratteri MIME e non MIME, la codifica dei messaggi e i formati degli allegati.

Queste opzioni di conversione e codifica sono indipendenti le une dalle altre. Ad esempio, l'uscita dei messaggi TNEF dall'organizzazione di Exchange non è legata alle impostazioni di codifica MIME o di testo normale di tali messaggi.

È possibile specificare la conversione del contenuto nei vari livelli dell'organizzazione di Exchange come descritto nell'elenco seguente:

• Impostazioni di dominio remoto: i domini remoti definiscono le impostazioni per i trasferimenti di messaggi in uscita tra l'organizzazione di Exchange e i domini esterni. Anche se non si creano voci del dominio remoto per domini specifici, esiste un dominio remoto predefinito, denominato Predefinito, che si applica a tutti gli spazi degli indirizzi remoti (*). Per ulteriori informazioni sui domini remoti, vedere Remote Domains.

• Impostazioni utente di posta elettronica e contatto di posta elettronica: gli utenti di posta elettronica e i contatti di posta elettronica sono simili perché entrambi hanno indirizzi di posta elettronica esterni e contengono informazioni su persone esterne all'organizzazione di Exchange. La differenza principale è che gli utenti di posta possono essere utilizzati per accedere a Active Directory e alle risorse nell'organizzazione. Per ulteriori informazioni, vedere Recipients.

• Impostazioni di Outlook: è possibile impostare queste opzioni di formattazione e codifica dei messaggi in Outlook:

  • Formato messaggio: è possibile impostare il formato di messaggio predefinito per tutti i messaggi. Inoltre, quando si compone un messaggio specifico, è possibile ignorare il formato predefinito.
  • Formato dei messaggi Internet: è possibile controllare se i messaggi TNEF vengono inviati a destinatari remoti o se vengono convertiti in un formato più compatibile. Inoltre, è possibile specificare diverse opzioni di codifica per i messaggi inviati a destinatari remoti. Queste impostazioni non si applicano ai messaggi inviati ai destinatari nell'organizzazione di Exchange.
  • Formato del messaggio del destinatario Internet (Outlook 2010 o versioni precedenti): è possibile controllare se i messaggi TNEF vengono inviati a contatti specifici nella cartella Contatti. Le opzioni di conversione non sono disponibili nell'organizzazione di Exchange.
  • Opzioni di codifica dei messaggi del destinatario Internet (Outlook 2010 o versioni precedenti): è possibile controllare le opzioni di codifica MIME o testo normale per contatti specifici nella cartella Contatti. Le opzioni di conversione non sono disponibili nell'organizzazione di Exchange.
  • Opzioni internazionali: è possibile controllare i set di caratteri usati nei messaggi.

  Per altre informazioni su queste impostazioni, vedere Opzioni di conversione TNEF e Opzioni di codifica dei messaggi in Exchange Server.

Concetti relativi alla struttura dei messaggi di posta elettronica

Per comprendere meglio le opzioni di conversione del contenuto per i destinatari esterni, è necessario comprendere la struttura dei messaggi di posta elettronica. Un messaggio SMTP si basa su testo normale in formato US-ASCII a 7 bit per la composizione e l'invio di messaggi di posta elettronica. Un messaggio SMTP standard è costituito dai seguenti elementi:

• Busta messaggio: la busta del messaggio è definita in RFC 5321. Contiene le informazioni necessarie per trasmettere e recapitare il messaggio. I destinatari non vedono mai la busta del messaggio, perché viene generata dal processo di trasmissione del messaggio e non è parte integrante del contenuto.

• Contenuto del messaggio: il contenuto del messaggio è definito in RFC 5322. È composto dai seguenti elementi:

  • Intestazione messaggio: l'intestazione del messaggio è una raccolta di campi di intestazione. I campi di intestazione consistono di un nome di campo, seguito da due punti (:) e dal corpo del campo, e terminano con una combinazione di caratteri ritorno a capo/avanzamento riga (CR/LF).

    Un nome di campo deve essere composto da caratteri di testo US-ASCII stampabili, ad eccezione dei due punti (:). In particolare, sono consentiti i caratteri ASCII con valori compresi tra 33 e 57 e tra 59 e 126.

    Il corpo di un campo può essere composto da qualsiasi carattere in formato US-ASCII, ad eccezione dei caratteri di ritorno a capo (CR) e avanzamento riga (LF). Tuttavia, il corpo di un campo può contenere la combinazione di caratteri CR/LF quando è utilizzato in un'intestazione su più righe. L'intestazione su più righe corrisponde alla divisione del corpo di un singolo campo di intestazione in più righe, come descritto nella sezione 2.2.3 di RFC 5322. Altri requisiti di sintassi del corpo del campo sono descritti nelle sezioni 3 e 4 di RFC 5322.

  • Corpo del messaggio: il corpo del messaggio è una raccolta di righe di caratteri di testo US-ASCII visualizzate dopo l'intestazione del messaggio. L'intestazione e il corpo del messaggio sono separati da una riga vuota che termina con la combinazione di caratteri CR/LF. Il corpo del messaggio è facoltativo. Ciascuna riga di testo nel corpo del messaggio deve essere inferiore a 998 caratteri. I caratteri di ritorno a capo e avanzamento riga possono essere inseriti solo insieme per indicare la fine di una riga.

Quando i messaggi SMTP contengono elementi che non sono testo US-ASCII normale, il messaggio deve essere codificato per preservare tali elementi. Lo standard MIME definisce un metodo di codifica del contenuto diverso dal testo presente nei messaggi. MIME consente di utilizzare testo appartenente ad altri set di caratteri, allegati privi di testo, corpi di messaggi costituiti da più parti e campi di intestazione che utilizzano altri set di caratteri. MIME è definito in RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 e RFC 2049. MIME definisce un insieme di campi di intestazione che specificano altri attributi dei messaggi. Le sezioni seguenti descrivono alcuni campi di intestazione MIME importanti.

MIME-Version campo intestazione

Valore predefinito: 1.0

Questo è il primo campo di intestazione MIME visualizzato in un messaggio in formato MIME. Viene visualizzato dopo gli altri campi di intestazione RFC 5322 standard e prima di qualsiasi altro campo di intestazione MIME. I client di posta elettronica basati su MIME utilizzano questo campo di intestazione per identificare un messaggio con codifica MIME. Se il campo di intestazione è assente, i client di posta elettronica basati su MIME identificano il messaggio come testo normale.

Campo di intestazione Content-Type

Valore predefinito: text/plain

Questo campo di intestazione identifica il tipo di supporto del contenuto del messaggio secondo quanto descritto in RFC 2046. Un tipo di supporto è costituito da:

• Tipo:

  • I tipi che iniziano con x- non sono standard. IANA (Internet Assigned Numbers Authority) gestisce un elenco di tipi di supporti registrati. Per ulteriori informazioni, MIME Media Types (Tipi di supporto MIME).

  • Il tipo di supporto multiparte consente di inserire più parti del messaggio nello stesso messaggio utilizzando sezioni definite da tipi di supporti diversi. Alcuni valori di campo Content-Type includono text/plain, text/html, multipart/mixede multipart/alternative.

• Sottotipo: i sottotipi che iniziano con vnd. sono specifici del fornitore.

• Uno o più parametri facoltativi: ad esempio, un charset= parametro che definisce la codifica dei caratteri MIME.

Campo intestazione Content-Transfer-Encoding

Valore predefinito: 7bit

Questo campo di intestazione consente di descrivere le seguenti informazioni sul messaggio:

• L'algoritmo di codifica utilizzato per trasformare tutti i dati binari o di testo diversi da US-ASCII presenti nel corpo del messaggio.
• Un indicatore della condizione corrente del corpo del messaggio.

Possono essere presenti più valori per il campo di intestazione Content-Transfer-Encoding in un messaggio MIME. Se il campo di intestazione Content-Transfer-Encoding è presente nell'intestazione del messaggio, viene applicato all'intero corpo del messaggio. Se il campo di intestazione Content-Transfer-Encoding è presente solo in una parte di un messaggio costituito da più parti, viene applicato solo a quella determinata parte del messaggio.

Quando un algoritmo di codifica viene applicato ai dati del corpo del messaggio, i dati del corpo del messaggio vengono trasformati in testo US-ASCII normale. Questa trasformazione consente al messaggio di passare attraverso i server di messaggistica precedenti che supportano solo messaggi in formato di testo US-ASCII. I valori del campo di intestazione Content-Transfer-Encoding che indicano l'utilizzo di un algoritmo di codifica sul corpo del messaggio sono:

• Quoted-printable: usa caratteri US-ASCII stampabili per codificare i dati del corpo del messaggio. Se il testo del messaggio originale è principalmente in formato US-ASCII, la codifica Quoted-Printable restituisce risultati alquanto compatti e leggibili. Tutti i caratteri di testo US-ASCII stampabili, ad eccezione del segno di uguale (=), possono essere rappresentati senza codifica.

• Base64: basato principalmente sullo standard PEM (Privacy Enhanced Mail) definito in RFC 4648. La codifica Base64 utilizza l'algoritmo di codifica con alfabeto a 64 caratteri e i caratteri di spaziatura interna di output definiti da PEM per codificare i dati del corpo del messaggio. Un messaggio con codifica Base64 è generalmente più grande del 33% rispetto all'originale. La codifica Base64 crea un aumento prevedibile nelle dimensioni dei messaggi ed è ottimale per i dati binari e il testo diverso da US-ASCII.

Generalmente nello stesso messaggio non vengono utilizzati più algoritmi di codifica.

Se per il corpo del messaggio non è stato utilizzato alcun algoritmo di codifica, il campo di intestazione Content-Transfer-Encoding identifica solamente lo stato attuale dei dati del corpo del messaggio. I valori del campo di intestazione Content-Transfer-Encoding che indicano che non è stato utilizzato alcun algoritmo di codifica sul corpo del messaggio sono:

• 7bit: indica che i dati del corpo del messaggio sono già nel formato RFC 5322. In particolare devono verificarsi le seguenti condizioni:

  • Nessuna riga di testo deve superare 998 caratteri.

  • Tutti i caratteri devono essere nel formato di testo US-ASCII, con valori compresi tra 1 e 127.

  • I caratteri di ritorno a capo e avanzamento riga possono essere utilizzati solamente insieme per indicare la fine di una riga di testo.

    L'intero corpo del messaggio oppure solo parte del corpo di un messaggio costituito da più parti può utilizzare 7 bit. Se il messaggio costituito da più parti contiene altre parti con dati binari o testo diverso da US-ASCII, tali parti del messaggio devono essere codificate utilizzando gli algoritmi di codifica Quoted-Printable o Base64.

    I messaggi con corpo 7 bit possono essere trasmessi da un server di messaggistica all'altro utilizzando il comando DATA standard.

• 8bit: indica che i dati del corpo del messaggio contengono caratteri non US-ASCII. In particolare devono verificarsi le seguenti condizioni:

  • Nessuna riga di testo deve superare 998 caratteri.

  • Uno o più caratteri presenti nel corpo del messaggio hanno valori superiori a 127.

  • I caratteri di ritorno a capo e avanzamento riga possono essere utilizzati solamente insieme per indicare la fine di una riga di testo.

    L'intero corpo del messaggio oppure solo parte del corpo di un messaggio costituito da più parti può utilizzare 8 bit. Se il messaggio costituito da più parti contiene altre parti con dati binari, tali parti devono essere codificate utilizzando gli algoritmi di codifica Quoted-Printable o Base64.

    I messaggi con corpo 8 bit possono essere trasmessi solo tra server di messaggistica che supportano l'estensione SMTP 8BITMIME definita in RFC 6152, ad esempio Exchange 2000 Server o versioni successive. In particolare devono verificarsi le seguenti condizioni:

  • La parola chiave 8BITMIME deve essere annunciata nella risposta EHLO del server.

  • Il trasferimento dei messaggi avviene ancora con il comando DATA standard di SMTP. Tuttavia, il BODY=8BITMIME parametro deve essere aggiunto alla fine del comando MAIL FROM .

• Binary: indica che il corpo del messaggio contiene dati binari o di testo non US-ASCII. In particolare si verificano le seguenti condizioni:

  • Qualsiasi sequenza di caratteri è consentita.

  • Nessuna limitazione di lunghezza delle righe.

  • Gli elementi del messaggio binario non richiedono alcuna codifica.

    I messaggi con corpo binario possono essere trasmessi solo tra server di messaggistica che supportano l'estensione SMTP BINARYMIME definita in RFC 3030, ad esempio Exchange 2000 Server o versioni successive. In particolare devono verificarsi le seguenti condizioni:

  • La parola chiave BINARYMIME deve essere annunciata nella risposta EHLO del server.

  • L'estensione SMTP BINARYMIME può essere utilizzata solo con l'estensione SMTP CHUNKING. L'estensione Chunking consente di inviare messaggi con corpo di grandi dimensioni in suddivisioni più piccole. L'estensione Chunking è definita anche in RFC 3030. La parola chiave CHUNKING, inoltre, deve essere annunciata nella risposta EHLO del server.

  • I messaggi vengono trasferiti utilizzando il comando BDAT al posto del comando DATA standard.

  • Il BODY=BINARYMIME parametro deve essere aggiunto alla fine del comando MAIL FROM quando il messaggio ha un corpo del messaggio.

I valori 7bit, 8bite Binary non esistono mai insieme nello stesso messaggio multiparte (i valori si escludono a vicenda). I Quoted-printable valori o Base64 possono essere visualizzati in un corpo del messaggio multipart a 7 o 8 bit, ma mai in un corpo di messaggio binario. Se il corpo di un messaggio costituito da più parti contiene diverse parti con contenuto 7 bit e 8 bit, l'intero messaggio viene classificato come 8 bit. Se il corpo di un messaggio costituito da più parti contiene diverse parti con contenuto 7 bit, 8 bit e Binary, l'intero messaggio viene classificato come Binary.

Campo dell'intestazione Content-Disposition

Valore predefinito: Attachment

Questo campo di intestazione indica a un client di posta elettronica abilitato a MIME come visualizzare un file allegato ed è descritto in RFC 2183. I valori validi sono:

• Inline: l'allegato viene visualizzato nel corpo del messaggio.

• Attachment: il file allegato viene visualizzato come allegato normale separato dal corpo del messaggio. Anche altri parametri sono con questi valori ( ad esempio, Filename, Creation-datee Size).