Condividi tramite

Informazioni sulle directory di prelievo e di riesecuzione

  • Articolo

 

Si applica a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Ultima modifica dell'argomento: 2009-10-14

Per impostazione predefinita, le directory di prelievo e riesecuzione esistono su ogni computer MicrosoftExchange Server 2010 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 e copiati nella directory di prelievo o riesecuzione vengono inviati per il recapito. La directory di prelievo viene utilizzata dagli amministratori per la verifica del flusso di posta o dalle applicazioni che devono creare e inviare messaggi propri. La directory di riesecuzione riceve i messaggi dai server gateway esterni e può essere utilizzata per rinviare i messaggi che gli amministratori esportano dalle code di Exchange 2010.

Per informazioni sulle attività di gestione relative alle directory di prelievo e riesecuzione, vedere Gestione dei connettori.

Sommario

Analisi di un file di messaggi di posta elettronica

Elaborazione dei messaggi da parte della directory di prelievo

Elaborazione dei messaggi da parte della directory di riesecuzione

Considerazioni sulla protezione per le le directory di prelievo e riesecuzione

Autorizzazioni per le le directory di prelievo e riesecuzione

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 include 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 Messaggistica del mittente genera una busta per il messaggio utilizzando le informazioni su mittente e destinatario presenti nell'intestazione del messaggio, per poi trasmetterlo ad Internet per il recapito al server Messaggistica del destinatario. I destinatari non vedono mai la busta del messaggio, perché viene generata dal processo di trasmissione del messaggio e non è parte integrante di questo.

Ogni server coinvolto nella trasmissione del messaggio può inserire campi d'intestazione del messaggio relativi al ruolo del server nel recapito del messaggio, oppure altri campi d'intestazione del messaggio specifici per la sua applicazione. Quando il destinatario apre il messaggio utilizzando un client di posta elettronica, il client visualizza alcune delle informazioni più importanti dall'intestazione del messaggio, quali mittente, destinatari e oggetto insieme al corpo del messaggio.

Inizio pagina

Elaborazione dei messaggi da parte della directory di prelievo

Un file dei messaggi con estensione .eml, formattato correttamente e copiato nella directory di prelievo viene elaborato per l'invio come descritto di seguito:

  1. Ogni cinque secondi viene verificata l'eventuale presenza di nuovi file di messaggi nella directory di prelievo. 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 possono essere aperti rimangono nella directory di prelievo e vengono verificati al polling successivo.

  2. I limiti applicati ai file dei messaggi nella directory di prelievo, come la dimensione massima dell'intestazione e il numero massimo di destinatari, vengono controllati. Per impostazione predefinita, la dimensione massima dell'intestazione è di 64 KB e il numero massimo di destinatari è pari a 100. Questi limiti possono essere modificati utilizzando il cmdlet Set-TransportServer.

  3. Il file viene rinominato da <nomefile>.eml a <nomefile>.tmp. Se il file <nomefile>.tmp esiste già, il file viene rinominato <nomefile><dataora>.tmp. Se la ridenominazione del file non riesce, viene generato un errore nel registro eventi e il processo di prelievo viene eseguito sul file successivo.

  4. Una volta convertito correttamente il file .tmp in un messaggio di posta elettronica, viene inviato un comando elimina alla chiusura al file .tmp. Il file con estensione .tmp rimane visualizzato nella directory di prelievo, ma non può essere aperto.

  5. Dopo che il messaggio è accodato in attesa di essere recapitato, viene inviato un comando close e il file con estensione .tmp viene eliminato dalla directory di prelievo. Se l'eliminazione non riesce, viene generato un errore nel registro eventi. Se il servizio di trasporto di MicrosoftExchange viene riavviato quando i file con estensione tmp si trovano nella directory di prelievo, tutti i file con estensione tmp vengono ridenominati come file con estensione eml e vengono rielaborati. Ciò potrebbe causare una trasmissione di messaggi duplicata.

Requisiti per i file dei messaggi nella directory di prelievo

Un file dei messaggi copiato nella directory di prelievo 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 del messaggio MIME sono supportati.

  • Il file dei messaggi deve avere estensione del nome del file eml.

  • Almeno un indirizzo di posta elettronica deve essere presente nei campi di intestazione del messaggio Mittente o Da. Se un singolo indirizzo di posta elettronica esiste in entrambi i campi Mittente e Da, l'indirizzo di posta elettronica nel campo Da è quello utilizzato come mittente del messaggio nella relativa busta.

  • Nel campo Mittente può esistere soltanto un indirizzo di posta elettronica. Non sono consentiti più indirizzi di posta elettronica. Il campo Mittente è facoltativo se esiste un unico indirizzo di posta elettronica nel campo Da.

  • Il campo Da consente di immettere più indirizzi di posta elettronica, ma allo stesso tempo nel campo Mittente deve esistere un unico indirizzo di posta elettronica. L'indirizzo nel campo Mittente viene quindi utilizzato come mittente del messaggio nella relativa busta.

  • Almeno un indirizzo di posta elettronica deve essere presente nei campi di intestazione del messaggio A, Cc o Ccn.

  • Tra l'intestazione e il corpo del messaggio deve essere presente una riga vuota.

Con questo esempio viene mostrato un messaggio di testo normale che utilizza una formattazione accettabile per la directory di prelievo.

To: mary@contoso.com
From: bob@fabrikam.com
Subject: Message subject

This is the body of the message.

Il contenuto MIME è supportato anche nei file dei messaggi della directory di prelievo. 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. Con questo esempio viene mostrato un messaggio MIME semplice che utilizza una formattazione accettabile per la directory di prelievo.

To: mary@contoso.com
From: bob@fabrikam.com
Subject: 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 prelievo

La directory di prelievo rimuove uno dei seguenti campi di intestazione del messaggio dall'intestazione:

  • Received

  • Resent-*

  • Bcc

    Nota

    Tutti gli indirizzi di posta elettronica che si trovano nei campi di intestazione del messaggio Ccn opzionali sono elaborati correttamente. Una volta elaborati i destinatari Ccn come destinatari invisibili nella busta del messaggio, questi vengono rimossi dall'intestazione del messaggio per proteggerne l'identità. Se un messaggio contiene solamente destinatari Ccn, il valore Destinatari nascosti viene aggiunto al campo A nell'intestazione del messaggio.

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

Received: from localhost by Pickup with Microsoft SMTP Server id <ExchangeServerVersion><datetime>

La directory di prelievo modifica i seguenti campi di intestazione del messaggio se mancanti o non corretti:

  • Message-Id   Se il campo Message-Id non è presente oppure è vuoto, la directory di prelievo aggiunge un campo Message-Id utilizzando il formato <GUID>@<dominiopredefinito>.

  • Data   Se il campo Data non è presente oppure non è corretto, la directory di prelievo aggiunge la data e l'ora di elaborazione del messaggio da parte della directory.

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

Un file di messaggio copiato nella directory di prelievo potrebbe non essere accodato correttamente per il recapito. Possono verificarsi le seguenti categorie di errori nell'inoltro dei messaggi:

  • Recapiti non riusciti   Viene generato un rapporto di mancato recapito per un file di messaggio formattato correttamente e con un mittente valido che non può essere inviato correttamente per il recapito dalla directory di prelievo. La directory di prelievo può generare rapporti di mancato recapito anche a causa di contenuti scorretti o di violazioni delle limitazioni del messaggio nella directory di prelievo. Quando viene emesso un rapporto di mancato recapito durante l'elaborazione del messaggio da parte della directory di prelievo, il messaggio originale è allegato al rapporto di mancato recapito e il file di messaggio viene eliminato dalla directory di prelievo.

    Nota

    Un messaggio formattato correttamente inviato dalla directory di prelievo può incorrere in errori di recapito in un secondo momento ed essere restituito al mittente con un rapporto di mancato recapito. Questo genere di errori può essere causato da problemi di trasmissione che non sono collegati alla directory di prelievo, ad esempio problemi del server Messaggistica o errori di instradamento lungo il percorso di recapito del file.

  • Posta scartata   Un messaggio classificato come posta scartata presenta seri problemi che impediscono alla directory di prelievo di inviare il messaggio per il recapito. In alternativa il messaggio può essere classificato come posta scartata quando il messaggio è formattato correttamente, ma i destinatari non sono validi e non è possibile inviare un rapporto di mancato recapito perché il mittente non è valido.

    I file dei messaggi considerati come posta scartata rimangono nella directory di prelievo e vengono rinominati da <nomefile>.eml a <nomefile>.bad. Se il file <nomefile>.bad esiste già, il file viene rinominato <nomefile><dataora>.bad. Se è presente posta scartata nella directory di prelievo, viene generato un errore nel registro eventi, ma gli stessi messaggi scartati non generano errori ripetuti nel registro eventi.

    Nota

    Si consiglia sempre di comporre e salvare i file di messaggio su un percorso diverso prima di copiarli nella directory di prelievo per il recapito. La directory di prelievo esegue il polling alla ricerca di nuovi messaggi ogni cinque secondi. Pertanto, se si tenta di comporre e di salvare il messaggio direttamente sulla directory di prelievo, la directory di prelievo potrebbe cercare di elaborare i file di messaggio prima della fine della composizione.

Inizio pagina

Elaborazione dei messaggi da parte della directory di riesecuzione

Un file dei messaggi con estensione .eml, formattato correttamente e copiato nella directory di riesecuzione viene elaborato per l'invio come descritto di seguito:

  1. Ogni cinque 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 possono essere aperti rimangono nella directory di riesecuzione e vengono verificati al polling successivo.

  2. Il file viene rinominato 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.

  3. Una volta convertito correttamente il file .tmp in un messaggio di posta elettronica, viene inviato un comando elimina alla chiusura al file .tmp. Il file con estensione .tmp rimane visualizzato nella directory di riesecuzione, ma non può essere aperto.

  4. Dopo che il messaggio è accodato in attesa di essere recapitato, viene inviato un comando close 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 MicrosoftExchange 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.

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 2010 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.

Un 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 del messaggio MIME 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 Da 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 Da, se presente, anche se il client di posta elettronica del destinatario visualizza il valore del campo di intestazione Da 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, nel caso in cui non sia possibile inviare il messaggio. RET può assumere il 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 Messaggistica secondo quanto descritto in RFC 2554.

  • X-Receiver   Questo campo X-Header sostituisce il campo di intestazione A 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 A, se presenti, anche se il client di posta elettronica del destinatario visualizza i valori dei campi A come destinatari del messaggio. Di norma sono presenti altri parametri facoltativi nei campi 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ò assumere il valore 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   Utilizzato per la funzionalità firewall dell'intestazione. Se questo campo X-Header è presente, non deve essere vuoto. Se il campo X-CreatedBy non esiste, viene aggiunto con il valore Unspecified. In genere, il valore di questo campo è MSExchange14, ma esso può contenere anche il tipo di spazio indirizzi non SMTP impostato su un connettore di invio, ad esempio Notes.

  • X-EndOfInjectedXHeaders   Dimensione 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à di messaggio estese per il messaggio.

  • X-HeloDomain   La stringa del dominio HELO/EHLO presentata durante la conversazione del protocollo SMTP iniziale.

  • X-LegacyExch50   Consente di preservare le proprietà personalizzate generate da Exchange Server 2003 se sono presenti server Exchange 2003.

  • X-Source   Utilizzato da Visualizzatore code nella colonna MessageSourceName. Se il valore di questo campo X-Header non è specificato, viene utilizzato il valore Replay. 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.

Con questo esempio viene mostrato un messaggio di testo normale che utilizza una formattazione accettabile per la directory di riesecuzione.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.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. Con questo esempio viene mostrato un messaggio MIME semplice che utilizza una formattazione accettabile per la directory di riesecuzione.

X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
X-Sender: <bob@fabrikam.com> BODY=7bit ENVID=12345ABCD auth=<someAuth>
To: mary@contoso.com
From: bob@fabrikam.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 Ccn dal file di messaggio.

La directory di riesecuzione aggiunge il proprio campo di intestazione Ricevuto a un messaggio come parte del processo di invio del messaggio. Il campo di intestazione del messaggio Ricevuto viene applicato nel seguente formato.

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>.

  • Data   Se questo campo di intestazione del messaggio non è presente oppure non è valido, la directory di riesecuzione aggiunge il campo di intestazione Data 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 come posta scartata rimangono nella directory di riesecuzione e vengono rinominati da <nomefile>.eml a <nomefile>.bad. Se il file <nomefile>.bad esiste già, il file viene rinominato <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.

Inizio pagina

Considerazioni sulla protezione per le le directory di prelievo e riesecuzione

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 posta indesiderata, antivirus, azioni di filtro mittente o di filtro destinatario, non viene eseguita sui messaggi inviati tramite la directory di prelievo o di riesecuzione.

  • Una directory di prelievo o una directory di riesecuzione danneggiata può fungere da inoltro aperto. Questo consente il rinvio o l'inoltro del messaggio utilizzando un server diverso per mascherare la vera 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 A o Da visualizzati dai client di posta elettronica. Tale rappresentazione di un mittente e di un dominio frequentemente è denominata spoofing. Il messaggio falsificato è 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 è MSExchange14, 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 nei messaggi trasmessi tra server di Exchange 2010 attendibili o di rimuovere i 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 2010, quali livello di probabilità di posta indesiderata (SCL, Spam Confidence Level), firma o crittografia dei messaggi tra server Exchange 2010. Rendere queste informazioni note a fonti non autorizzate potrebbe rappresentare una minaccia per la protezione.

È necessario rafforzare la protezione della directory di riesecuzione a causa di ulteriori minacce per la protezione associate alla directory di riesecuzione. L'accesso alla directory di prelievo può essere concesso a utenti o applicazioni che devono generare e inoltrare nuovi messaggi, mentre non dovrebbe essere necessario l'accesso alla directory di riesecuzione.

Sia la directory di prelievo che la directory di riesecuzione sono abilitate per impostazione predefinita su tutti i server Trasporto Hub e Trasporto Edge. È possibile disabilitare una directory di prelievo o una directory di riesecuzione che non è richiesta in uno specifico server Trasporto Hub o Trasporto Edge dell'organizzazione. Per ulteriori informazioni, vedere gli argomenti seguenti:

Inizio pagina

Autorizzazioni per le le directory di prelievo e riesecuzione

Per accedere alle directory di prelievo e riesecuzione sono necessarie le seguenti autorizzazioni:

  • Amministratore: Controllo completo

  • Sistema: Controllo completo

  • Servizio di rete: Lettura, Scrittura ed Eliminazione sottocartelle e file

Per impostazione predefinita, il servizio di trasporto di MicrosoftExchange utilizza le credenziali di sicurezza dell'account utente servizio di rete per gestire il percorso e le autorizzazioni delle directory di prelievo e riesecuzione. L'account servizio di rete richiede tali autorizzazioni sulla directory di prelievo 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 di queste directory utilizzando i parametri PickupDirectoryPath e ReplayDirectoryPath sul cmdlet Set-TransportServer. La modifica corretta del percorso della directory di prelievo dipende dai diritti concessi all'account servizio di rete nei nuovi percorsi delle directory e dall'eventualità che le nuove directory siano già presenti. Se la directory non esiste e se l'account del servizio di rete dispone dei diritti necessari per creare cartelle e applicare le autorizzazioni al nuovo percorso, la directory viene creata e le autorizzazioni corrette sono applicate alla nuova directory. Se la nuova directory esiste già, le autorizzazioni della cartella esistente non vengono controllate. Ogni volta che si spostano le directory utilizzando i parametri PickupDirectoryPath o ReplayDirectoryPath con il cmdlet Set-TransportServer, si consiglia di verificare l'esistenza della nuova directory e le relative autorizzazioni.

Inizio pagina

 ©2010 Microsoft Corporation. Tutti i diritti riservati.