Gestione della directory di riproduzione

Articolo
08/10/2014

Si applica a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Ultima modifica dell'argomento: 2007-02-22

Per impostazione predefinita, la directory di riesecuzione esiste su ogni computer Microsoft Exchange Server 2007 in cui è installato il ruolo del server Trasporto Hub o il ruolo del server Trasporto Edge. I file dei messaggi di posta elettronica formattati correttamente copiati nella directory di riesecuzione vengono inviati per il recapito. La directory di riesecuzione riceve i messaggi da server gateway esterni e inviare nuovamente i messaggi esportati dagli amministratori dalle code dei server Exchange 2007.

Utilizzare il cmdlet Set-TransportServer per tutte le attività di configurazione della directory di riesecuzione. Utilizzare questo cmdlet per apportare le seguenti modifiche alla configurazione della directory di riesecuzione:

Abilitare o disabilitare la directory di riesecuzione.
Specificare il percorso della directory di riesecuzione.
Specificare la velocità massima di elaborazione dei file dei messaggi in messaggi al minuto.

Elaborazione dei messaggi da parte della directory di riesecuzione

Un file di messaggi di posta elettronica con estensione eml formattato correttamente copiato nella directory di riesecuzione viene elaborato per l'invio come descritto di seguito:

Ogni 5 secondi viene verificata l'eventuale presenza di nuovi file di messaggi nella directory di riesecuzione. Non è possibile modificare questo intervallo di polling. È possibile impostare la velocità di elaborazione dei file dei messaggi utilizzando il parametro PickupDirectoryMaxMessagesPerMinute sul cmdlet Set-TransportServer. Il valore predefinito è 100 messaggi al minuto. I file che non è possibile aprire rimangono nella directory di riesecuzione e vengono verificati al polling successivo.
Il file viene ridenominato da *<nomefile>*eml a <nomefile>.tmp. Se il file *<nomefile>.*tmp esiste già, il file viene ridenominato <nomefile><dataora>.tmp. Se la ridenominazione del file non riesce, viene generato un errore nel registro eventi e il processo di riesecuzione viene eseguito sul file successivo.
Una volta convertito correttamente il file con estensione tmp in un messaggio di posta elettronica, viene inviato un comando "elimina alla chiusura" al file con estensione tmp. Il file .tmp rimane visualizzato nella directory di riesecuzione, ma il file non può essere aperto da nessun altro.
Dopo che il messaggio è accodato in attesa di essere recapitato, viene inviato un comando "chiudi" e il file con estensione tmp viene eliminato dalla directory di riesecuzione. Se l'eliminazione non riesce, viene generato un errore nel registro eventi. Se il servizio di trasporto di Microsoft Exchange viene riavviato quando i file con estensione tmp si trovano nella directory di riesecuzione, tutti i file con estensione tmp vengono ridenominati come file con estensione eml e quindi vengono rielaborati. Ciò potrebbe causare una trasmissione di messaggi duplicata.

Analisi di un file di messaggi di posta elettronica

Un messaggio di posta elettronica SMTP standard è costituito da una busta del messaggio e dal contenuto del messaggio. La busta del messaggio contiene le informazioni necessarie per la trasmissione e il recapito del messaggio. Il contenuto del messaggio contiene i campi di intestazione del messaggio denominati collettivamente intestazione del messaggio e il corpo del messaggio. La busta del messaggio è descritta in RFC 2821, mentre l'intestazione del messaggio è descritta in RFC 2822.

Quando il mittente crea un messaggio di posta elettronica e lo invia per il recapito, il messaggio contiene le informazioni di base necessarie per la conformità agli standard SMTP, quali mittente, destinatario, data e ora di creazione del messaggio, campo oggetto facoltativo e corpo del messaggio facoltativo. Queste informazioni sono contenute nel messaggio stesso e, per definizione, sono contenute nell'intestazione del messaggio. Il server di messaggistica del mittente genera una busta per il messaggio utilizzando le informazioni relative a mittente e destinatario presenti nell'intestazione del messaggio e trasmette il messaggio a Internet per il recapito. I destinatari non vedono mai la busta del messaggio, perché viene generata dal processo di trasmissione del messaggio e non è parte integrante del messaggio stesso. Ogni server coinvolto nella trasmissione del messaggio può inserire campi d'intestazione relativi al ruolo del server nel recapito oppure altri campi d'intestazione specifici dell'applicazione nell'intestazione del messaggio. Quando il destinatario apre il messaggio utilizzando un client di posta elettronica, nel client sono visualizzate alcune delle informazioni più importanti dall'intestazione del messaggio, quali mittente, destinatari e oggetto.

Per meglio comprendere il rapporto tra la busta del messaggio e l'intestazione del messaggio è possibile fare un'analogia con l'invio della posta tradizionale in una grande società. Una lettera commerciale formale riporta l'indirizzo della società e l'indirizzo del destinatario nella formula introduttiva sulla parte superiore della lettera. La lettera viene portata all'ufficio smistamento posta della società per essere elaborata. Il personale dell'ufficio smistamento posta crea una busta utilizzando le informazioni sul destinatario indicate nella lettera, inserisce la lettera nella busta e imbuca la busta nella cassetta postale. Il servizio postale recapita la busta alla società del destinatario in base all'indirizzo indicato sulla busta. Il personale dell'ufficio smistamento posta della società del destinatario riceve la busta, individua il destinatario in base a quanto indicato sulla busta e inserisce la lettera nella cassetta postale personale del destinatario. Quando il destinatario recupera la lettera dalla cassetta postale personale, riconosce, dalle informazioni della formula introduttiva, chi ha scritto la lettera che gli è stata inviata.

Requisiti per i file dei messaggi nella directory di riesecuzione

La directory di riesecuzione viene utilizzata per inviare nuovamente i messaggi di Exchange esportati e per ricevere i messaggi da server gateway esterni. Questi messaggi sono già formattati per la directory di riesecuzione. Non è necessario che l'amministratore o un'altra applicazione compongano e inoltrino nuovi file dei messaggi utilizzando la directory di riesecuzione. È necessario utilizzare la directory di prelievo per creare e inoltrare nuovi file dei messaggi.

I messaggi della directory di riesecuzione fanno largo uso dei campi X-Header. I campi X-Header sono campi di intestazione del messaggio definiti dall'utente, non standard, esistenti nell'intestazione del messaggio. I campi X-Header non sono citati specificatamente nella specifica RFC 2822, ma l'utilizzo di un campo di intestazione del messaggio non definito che inizia con "X-" è diventato un modo comunemente accettato per aggiungere campi di intestazione non standard a un messaggio. I campi X-Header specifici di Exchange 2007 utilizzati nei file di messaggio nella directory di riesecuzione possono in effetti impostare le informazioni di recapito normalmente incluse nella busta del messaggio. Questa funzionalità è necessaria per mantenere le informazioni del messaggio originale quando si utilizza la directory di riesecuzione per elaborare i messaggi esportati da un altro server Exchange.

Il file dei messaggi copiato nella directory di riesecuzione deve soddisfare i seguenti requisiti per il recapito corretto:

Il file dei messaggi deve essere un file di testo conforme al formato di base dei messaggi SMTP. Il contenuto e i campi di intestazione MIME (Multipurpose Internet Mail Extensions) del messaggio sono supportati.
Il file dei messaggi deve avere estensione del nome del file eml.
I campi X-Header devono precedere tutti i campi d'intestazione normali.
Tra i campi di intestazione e il corpo del messaggio deve essere presente una riga vuota.

I campi X-Header descritti nell'elenco seguente sono necessari per i messaggi nella directory di riesecuzione:

X-Sender: Questo campo X-Header sostituisce il campo di intestazione From: in un messaggio SMTP standard. Deve essere presente un campo X-Sender: contenente un indirizzo di posta elettronica. La directory di riesecuzione ignora il campo di intestazione From:, se presente, anche se il client di posta elettronica del destinatario visualizza il valore del campo di intestazione From: come mittente del messaggio. Di norma sono presenti altri parametri nel campo X-Sender: come illustrato nell'esempio seguente:
```
X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
```
Nota

Questi parametri sono i valori della busta del messaggio generati normalmente dal server di invio. È possibile visualizzare parametri simili nei file dei messaggi esportati.
RET= specifica se è necessario restituire al mittente l'intero messaggio oppure solo le intestazioni se non è possibile inviare il messaggio. RET= può avere un valore HDRS o FULL.
ENVID= è l'identificatore della busta del messaggio. BODY= specifica la codifica del testo del messaggio. AUTH= specifica il meccanismo di autenticazione per il server di messaggistica secondo quanto descritto in RFC 2554.
X-Receiver: Questo campo X-Header sostituisce il campo di intestazione To: in un messaggio SMTP standard. Deve essere presente almeno un campo X-Receiver: contenente un indirizzo di posta elettronica. Sono consentiti più campi X-Receiver: per più destinatari. La directory di riesecuzione ignora i campi di intestazione del messaggio To:, se presenti, anche se il client di posta elettronica del destinatario visualizza i valori dei campi To: come destinatari del messaggio. Di norma sono presenti altri parametri facoltativi nel campo X-Receiver: come illustrato nell'esempio seguente:
```
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
```
Nota

Questi parametri sono i valori della busta del messaggio generati normalmente dal server di invio. È possibile visualizzare parametri simili nei file dei messaggi esportati. Questi parametri sono correlati ai messaggi di notifica dello stato del recapito (DSN, Delivery Status Notification) secondo quanto descritto in RFC 1891. NOTIFY= può avere un valore di NEVER, DELAY o FAILURE. ORcpt= viene utilizzato per mantenere il destinatario originale del messaggio.

I campi X-Header descritti nell'elenco seguente sono facoltativi per i file di messaggio nella directory di riesecuzione:

X-CreatedBy: Se questo campo X-Header è presente, non deve essere vuoto. Se il campo X-CreatedBy: non è presente, viene aggiunto con il valore Unspecified. In genere, il valore di questo campo è MSExchange12, ma esso può contenere anche il tipo di spazio indirizzo non SMTP impostato su un connettore di invio, ad esempio Notes. Questo campo di intestazione viene utilizzato per la caratteristica firewall dell'intestazione.
X-EndOfInjectedXHeaders: Le dimensioni in byte di tutti i campi "X-Header" presenti. Questo campo X-Header può essere utilizzato come indicatore dell'ultimo campo X-Header prima dell'inizio dei campi di intestazione standard.
X-ExtendedMessageProps: Proprietà estese del messaggio.
X-HeloDomain: La stringa del dominio HELO/EHLO presentata durante la conversazione del protocollo SMTP iniziale.
X-LegacyExch50: Utilizzato per mantenere le proprietà personalizzate generate da Exchange Server 2003 se sono presenti server Exchange 2003.
X-Source: Se il valore di questo campo X-Header non è specificato, viene utilizzato il valore Replay. Questo campo X-Header viene utilizzato da Visualizzatore code nella colonna MessageSourceName. Altri valori possibili per questo campo sono Smtp Receive Connector e Smtp Send Connector.
X-SourceIPAddress: Indirizzo IP del server di invio. Questo campo è 0.0.0.0 se non è specificato alcun indirizzo IP.

Di seguito è riportato l'esempio di un messaggio di testo normale che utilizza formattazione accettabile per la directory di riesecuzione:

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345AB auth=<someAuth>
Subject: Optional message subject

This is the body of the message.

Il contenuto MIME è supportato anche nei file dei messaggi della directory di riesecuzione. MIME definisce un'ampia gamma di contenuti di messaggi comprendenti lingue che non possono essere rappresentate in testo ASCII a 7 bit, HTML e altro contenuto multimediale. Una descrizione completa e i requisiti di MIME esulano dall'ambito di questo argomento. Di seguito è riportato l'esempio di un messaggio MIME semplice che utilizza formattazione accettabile per la directory di riesecuzione:

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@contoso.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@contoso.com
Subject: Optional message subject
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<HTML><BODY>
<TABLE>
<TR><TD>cell 1</TD><TD>cell 2</TD></TR>
<TR><TD>cell 3</TD><TD>cell 4</TD></TR>
</TABLE>

</BODY></HTML>

Modifiche all'intestazione del messaggio apportate ai file dei messaggi nella directory di riesecuzione

La directory di riesecuzione elimina il campo di intestazione Bcc: dal file di messaggio.

La directory di riesecuzione aggiunge il proprio campo di intestazione Received: al messaggio come parte del processo di invio del messaggio. Il campo di intestazione Received: viene applicato nel formato seguente:

Received: from <ReceivingServerName> by Replay with <ExchangeServerVersion><DateTime>

La directory di riesecuzione modifica i campi di intestazione seguenti nell'intestazione di messaggio:

Message-ID: Se il campo di intestazione non è presente oppure è vuoto, la directory di riesecuzione aggiunge un campo di intestazione Message-ID: utilizzando il formato <GUID>@<dominiopredefinito>.
Date: Se questo campo di intestazione non è presente oppure non è valido, la directory di riesecuzione aggiunge il campo di intestazione Date: utilizzando la data e l'ora di elaborazione del messaggio da parte della directory di riesecuzione.

Errori nell'elaborazione dei messaggi da parte della directory di riesecuzione

Se si verifica qualsiasi problema di conversione di un file dei messaggi in un messaggio di posta elettronica la directory di riesecuzione considera il messaggio non recapitabile (posta scartata). Un file dei messaggi scartati presenta gravi problemi, quali mittente mancante, destinatari mancanti o problemi di formattazione. I file dei messaggi considerati posta scartata rimangono nella directory di riesecuzione e vengono ridenominati da <nomefile>.eml a <nomefile>.bad. Se il file <nomefile>.bad esiste già, il file viene ridenominato <nomefile><dataora>.bad. Se è presente posta scartata nella directory di riesecuzione, viene generato un errore nel registro eventi, ma gli stessi messaggi scartati non generano errori ripetuti nel registro eventi.

Problemi relativi alla protezione della directory di riesecuzione

Exchange Server 2003 utilizza una directory di prelievo unica per la creazione e l'inoltro dei file dei messaggi di testo. Exchange 2007 suddivide, invece, questa funzionalità in directory di prelievo e di riesecuzione. La directory di prelievo è destinata a utenti o applicazioni per la creazione manuale di nuovi file dei messaggi. La directory di riesecuzione è destinata per il reinvio dei messaggi di posta elettronica di Exchange esportati e per la ricezione dei messaggi da connettori non SMTP. Questa divisione delle funzioni consente di garantire la protezione appropriata a una directory senza compromettere la funzionalità dell'altra directory.

Nell'elenco riportato di seguito sono illustrati problemi relativi alla protezione comuni alla directory di prelievo e alla directory di riesecuzione:

Qualsiasi verifica della protezione configurata su un connettore di ricezione, quali rilevamento della protezione da posta indesiderata, antivirus, azioni di filtro del mittente o di filtro dei destinatari, non vengono eseguite sui messaggi inoltrati tramite la directory di prelievo e la directory di riesecuzione al momento dell'invio del messaggio.
Una directory di prelievo o una directory di riesecuzione danneggiata può fungere da inoltro aperto. Questo consente di inviare o di inoltrare nuovamente il messaggio utilizzando un server diverso per mascherare l'origine dei messaggi.

Nell'elenco riportato di seguito sono illustrati altri problemi relativi alla protezione validi per la directory di riesecuzione:

I campi X-Header utilizzati dalla directory di riesecuzione consentono la creazione manuale della busta del messaggio. Le informazioni nei campi X-Sender: e X-Receiver: possono essere completamente diverse da quelle presenti nei campi di intestazione To: o From: visualizzati dai client di posta elettronica. Tale rappresentazione di un mittente e di un dominio frequentemente è denominata spoofing. Per messaggio contraffatto si intende un messaggio di posta elettronica in cui l'indirizzo del mittente è stato modificato in modo tale che sembra essere stato inviato da un mittente diverso dal mittente effettivo del messaggio.
Se il valore del campo X-CreatedBy: è MSExchange12, la destinazione è considerata affidabile e il firewall dell'intestazione non viene applicato. Il firewall dell'intestazione consente a Exchange di mantenere i campi "X-Header" in messaggi trasmessi tra server attendibili di Exchange 2007 o di rimuovere campi "X-Header" che potrebbero rivelare informazioni importanti da messaggi trasmessi a destinazioni non attendibili esterne all'organizzazione di Exchange. Questi campi "X-Header" possono essere utilizzati per condividere le informazioni di Exchange 2007, quali livello di probabilità di posta indesiderata (SCL, Spam Confidence Level), firma o crittografia dei messaggi tra server Exchange 2007. Rendere queste informazioni note a fonti non autorizzate potrebbe rappresentare una minaccia per la protezione.

La divisione della directory di prelievo e della directory di riesecuzione significa che è possibile applicare diversi livelli di protezione di ciascuna directory. È necessario rafforzare la protezione della directory di riesecuzione a causa di ulteriori minacce per la protezione associate alla directory di riesecuzione. L'accesso per la directory di prelievo può essere concesso a utenti o applicazioni che devono generare e inviare nuovi messaggi e che non hanno tuttavia bisogno di accedere alla directory di riesecuzione.

Autorizzazioni per la directory di riesecuzione

Per accedere alla directory di riesecuzione sono necessarie le seguenti autorizzazioni:

Amministratore: controllo completo
Sistema: controllo completo
Servizio di rete: lettura, scrittura ed eliminazione di sottocartelle e file

Per impostazione predefinita, il servizio di trasporto di Microsoft Exchange utilizza le credenziali di sicurezza dell'account utente Servizio di rete per gestire il percorso e le autorizzazioni della directory di riesecuzione. L'account Servizio di rete richiede tali autorizzazioni sulla directory di riesecuzione in modo che i file con estensione eml possano essere aperti, ridenominati con estensione tmp ed eliminati o ridenominati con estensione bad se il messaggio è classificato come posta scartata.

È possibile modificare il percorso della directory di riesecuzione utilizzando il parametro ReplayDirectoryPath sul cmdlet Set-TransportServer. La modifica corretta del percorso della directory di riesecuzione dipende dai diritti concessi all'account Servizio di rete nella nuova directory di riesecuzione e dall'eventualità che la nuova directory di riesecuzione sia già presente. Se la nuova directory di riesecuzione non esiste già e se l'account Servizio di rete dispone dei diritti necessari per creare cartelle e applicare le autorizzazioni al nuovo percorso, la directory di riesecuzione viene creata e le autorizzazioni corrette sono applicate alla nuova directory. Se la directory di riesecuzione esiste già, le autorizzazioni della cartella esistente non vengono controllate. Ogni volta che si sposta la directory di riesecuzione utilizzando il parametro ReplayDirectoryPath con il cmdlet Set-TransportServer, si consiglia di verificare la nuova directory di riesecuzione e le relative autorizzazioni. Se la modifica della directory di riesecuzione non va a buon fine, è possibile creare la nuova directory di riesecuzione e applicarvi le autorizzazioni appropriate prima di utilizzare il parametro ReplayDirectoryPath con il cmdlet Set-TransportServer.

Ulteriori informazioni

Per ulteriori informazioni, vedere i seguenti argomenti: