Directory di prelievo e Directory di riesecuzione

Articolo
04/04/2023

Si applica a: Exchange Server 2013

Per impostazione predefinita, le directory di prelievo e di riesecuzione sono presenti in tutti i server Cassette postali o Trasporto Edge di Microsoft Exchange Server 2013. 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 i propri messaggi. La directory di riesecuzione riceve i messaggi da server gateway esterni e può anche essere utilizzata per inviare nuovamente i messaggi esportati dagli amministratori dalle code dei server Exchange.

Struttura di un file dei 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.

Modalità di elaborazione dei messaggi delle directory di prelievo e riesecuzione

In Exchange 2013 il percorso predefinito della directory di ritiro è %ExchangeInstallPath%TransportRoles\Pickup. Il percorso predefinito della directory Replay è %ExchangeInstallPath%TransportRoles\Replay. Un file dei messaggi con estensione EML, formattato correttamente e copiato nella directory di prelievo o riesecuzione, viene elaborato per l'invio come descritto di seguito:

Ogni cinque secondi viene verificata l'eventuale presenza di nuovi file dei messaggi nelle directory di prelievo e riesecuzione. Non è possibile modificare questo intervallo di polling. È possibile modificare la frequenza di elaborazione dei file di messaggi usando il parametro PickupDirectoryMaxMessagesPerMinute nel cmdlet Set-TransportService . Questo parametro influisce sulle directory di prelievo e di riesecuzione. 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.
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 è 64 KB e il numero massimo di destinatari è pari a 100. Questi limiti possono essere modificati utilizzando il cmdlet Set-TransportService. Le impostazioni influiscono direttamente solo sulla directory di prelievo.
Il file viene rinominato da <filename.eml> a <filename.tmp>. Se il <file nomefile.tmp> esiste già, il file viene rinominato come <nome><file datetime.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.
Una volta convertito correttamente il file TMP in un messaggio di posta elettronica, viene inviato un comando di delete on close al file TMP. Il file con estensione .tmp rimane visualizzato nella directory di prelievo, ma non può essere aperto.
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 Microsoft Exchange viene riavviato quando i file con estensione TMP si trovano nella directory di prelievo, tutti i file con estensione TMP vengono rinominati come file con estensione EML e vengono rielaborati. Ciò potrebbe causare una trasmissione di messaggi duplicata.

Requisiti relativi ai file dei messaggi della 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 esistere nei campi dell'intestazione Sender del messaggio o From nell'intestazione del messaggio. Se esiste un singolo indirizzo di posta elettronica nei Sender campi e From , l'indirizzo di posta elettronica nel From campo viene usato come originatore del messaggio nella busta del messaggio.
Nel campo può essere presente Sender un solo indirizzo di posta elettronica. Non sono consentiti più indirizzi di posta elettronica. Il Sender campo è facoltativo se nel From campo è presente un solo indirizzo di posta elettronica.
Nel campo sono consentiti From più indirizzi di posta elettronica, ma nel campo deve essere presente Sender anche un singolo indirizzo di posta elettronica. L'indirizzo nel Sender campo viene quindi utilizzato come originatore del messaggio nella busta del messaggio.
Nei campi , Cco deve essere presente Toalmeno un indirizzo di Bcc posta elettronica.
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 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 trovati nei campi facoltativi Bcc dell'intestazione del messaggio vengono elaborati correttamente. Dopo che i Bcc destinatari sono stati promossi a destinatari busta messaggio invisibile, vengono rimossi dall'intestazione del messaggio per proteggere la loro identità. Se un messaggio contiene solo Bcc destinatari, il valore di Destinatari non divulgati viene aggiunto al To campo nell'intestazione del messaggio.

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

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 Message-Id campo è mancante o vuoto, la directory di ritiro aggiunge un campo Message-Id usando il formato <GUID>@<defaultdomain>.
Data: se il Date campo è mancante o non valido, la directory di ritiro aggiunge la data e l'ora di elaborazione dei messaggi dalla directory pickup.

Requisiti relativi ai file dei messaggi della directory di riesecuzione

La directory di riesecuzione viene utilizzata per inoltrare nuovamente i messaggi esportati di Exchange 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 utilizzati nei file dei messaggi 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: questa X-Header sostituisce il requisito del campo dell'intestazione del From messaggio in un tipico messaggio SMTP. Deve esistere un X-Sender campo contenente un indirizzo di posta elettronica. La directory Replay ignora il campo dell'intestazione From del messaggio, se presente, anche se il client di posta elettronica del destinatario visualizza il valore del campo dell'intestazione del From messaggio come mittente del messaggio. Nel campo sono in genere presenti X-Sender altri parametri, 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ò avere un valore pari HDRS a 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: questa X-Header sostituisce il requisito del campo dell'intestazione del To messaggio in un tipico messaggio SMTP. Deve esistere almeno un X-Receiver campo contenente un indirizzo di posta elettronica. Sono consentiti più X-Receiver campi per più destinatari. Se presenti, i campi dell'intestazione del To messaggio vengono ignorati dalla directory Replay, anche se il client di posta elettronica del destinatario visualizza i valori dei campi dell'intestazione del To messaggio come destinatari del messaggio. Nei campi possono essere presenti X-Receiver altri parametri facoltativi, 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, DELAYo 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: usato per la funzionalità del firewall dell'intestazione. Se questo campo X-Header è presente, non deve essere vuoto. Se il X-CreatedBy campo non esiste, viene aggiunto con il valore Non specificato. In genere, il valore di questo campo è MSExchange15 ma può contenere anche il tipo di spazio indirizzi non SMTP impostato su un connettore di invio, ad esempio Notes.
X-EndOfInjectedXHeaders: dimensioni in byte di tutte le intestazioni X 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à del messaggio estese per il messaggio.
X-HeloDomain: stringa di dominio HELO/EHLO presentata durante la conversazione iniziale del protocollo SMTP.
X-Source: usato dal Visualizzatore code nella colonna MessageSourceName . Se il valore di questo campo X-Header non è specificato, viene utilizzato il valore Replay. Altri valori possibili per il campo X-Header 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 nella directory di riesecuzione

La directory Replay elimina il campo dell'intestazione Bcc del messaggio dal file del messaggio.

La directory Replay aggiunge il proprio Received campo di intestazione del messaggio 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 questo campo di intestazione del messaggio è mancante o vuoto, la directory Replay aggiunge un campo di intestazione messaggio-ID messaggio usando il formato <GUID>@<defaultdomain>.
Data: se il campo dell'intestazione del messaggio è mancante o non valido, la directory Replay aggiunge il campo Data intestazione messaggio utilizzando la data e l'ora di elaborazione del messaggio dalla directory Replay.

Errori nell'elaborazione del messaggio delle directory di prelievo e riesecuzione

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

Errori di recapito: un file di messaggio formattato correttamente insieme a un mittente valido che non può essere inviato correttamente per il recapito genera un report di mancato recapito. Anche le violazioni delle restrizioni per i messaggi della directory di prelievo o con contenuto con formato non valido potrebbero causare un rapporto di mancato recapito. Quando viene emesso un rapporto di mancato recapito durante l'elaborazione del messaggio, il messaggio originale viene allegato al rapporto di mancato recapito e il file dei messaggi viene eliminato dalla directory di prelievo o dalla directory di riesecuzione.

Nota

Un messaggio formattato correttamente inviato alla pipeline di trasporto 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 o di riesecuzione, ad esempio problemi del server di messaggistica o errori di instradamento lungo il percorso di recapito del messaggio.
Posta non valida: un messaggio classificato come messaggio non valido presenta gravi problemi che impediscono alle directory di ritiro o riproduzione 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 di messaggio determinati come messaggi non validi vengono lasciati nelle directory pickup o replay e vengono rinominati da <filename.eml> a <filename.bad>. Se il <filename.bad> esiste già, il file viene rinominato in <nomefile><datetime.bad>. Se sono presenti messaggi di posta scartata nella directory di prelievo o di riesecuzione, 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.

Considerazioni sulla protezione per 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, antimalware, 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 X-Sender campi e X-Receiver possono essere completamente diverse dai campi di intestazione del To messaggio o From visualizzati dai client di posta elettronica. Tale rappresentazione di un mittente e di un dominio frequentemente è denominata spoofing. La posta falsificata è 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 X-CreatedBy valore del campo è MSExchange15, la destinazione viene considerata attendibile e il firewall di intestazione non viene applicato. Il firewall dell'intestazione consente a Exchange di mantenere i campi X-Header nei messaggi trasmessi tra server Exchange attendibili o di rimuovere i campi X-Header che potrebbero rivelare informazioni importanti presenti in messaggi trasmessi a destinazioni non attendibili esterne all'organizzazione Exchange. Questi campi X-Header possono essere utilizzati per condividere le informazioni di Exchange, quali livello di probabilità di posta indesiderata (SCL, Spam Confidence Level), firma o crittografia dei messaggi tra server Exchange autorizzati. Rendere queste informazioni note a fonti non autorizzate potrebbe rappresentare una minaccia per la protezione. Per ulteriori informazioni sul firewall dell'intestazione, vedere Concetti relativi al firewall dell'intestazione.

È 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 Cassette postali e Trasporto Edge. Se la directory di ritiro o la directory replay non è necessaria in un server Cassette postali specifico o in un server Trasporto Edge dell'organizzazione, è possibile disabilitare la directory pickup o la directory replay in tale server impostando il percorso della directory di ritiro o il percorso della directory di riproduzione sul valore $null. Per altre informazioni, vedere Configurare la directory pickup e la directory Replay.

Autorizzazioni per 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 Microsoft Exchange utilizza le credenziali di sicurezza dell'account utente del 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 spostare la posizione di queste directory usando i parametri PickupDirectoryPath e ReplayDirectoryPath nel cmdlet Set-TransportService . 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 i percorsi della directory usando il parametro PickupDirectoryPath o ReplayDirectoryPath con il cmdlet Set-TransportService , verificare sempre che la nuova directory esista e che alla nuova directory siano applicate le autorizzazioni corrette.