Diretório de retirada e diretório de repetição

Artigo
04/04/2023

Aplica-se a: Exchange Server 2013

Por padrão, os diretórios Pickup e Replay existem em todos os Microsoft Exchange Server servidor de caixa de correio de 2013 ou servidor do Edge Transport. Os arquivos de mensagens de email formatados corretamente que você copia para o Diretório de Retirada e Reprodução são enviados para entrega. O diretório de Retirada é usado por administradores para testes de fluxo de mensagens ou por aplicativos que devem criar e enviar suas próprias mensagens. O diretório Replay recebe mensagens de servidores de gateway estrangeiros e também pode ser usado para reenviar mensagens que os administradores exportam das filas de servidores do Exchange.

Anatomia de um arquivo de mensagem de email

Uma mensagem de email SMTP padrão consiste em um envelope de mensagem e conteúdo de mensagem. O envelope de mensagem contém informações necessárias para transmitir e entregar a mensagem. O conteúdo da mensagem contém campos de cabeçalho de mensagem (chamado coletivamente de cabeçalho de mensagem) e o corpo da mensagem. O envelope da mensagem está descrito no RFC 2821 e o cabeçalho da mensagem, no RFC 2822.

Quando um remetente redige uma mensagem de email e a envia para entrega, a mensagem contém as informações básicas necessárias para estar em conformidade com os padrões SMTP, como um remetente, um destinatário, a data e a hora em que a mensagem foi redigida, uma linha de assunto opcional e um corpo de mensagem opcional. Essas informações estão contidas na própria mensagem e, por definição, estão contidas no cabeçalho da mensagem.

O servidor de mensagens do remetente gera um envelope de mensagens para a mensagem usando as informações do remetente e do destinatário encontradas no cabeçalho da mensagem e transmite a mensagem para a Internet para entrega no servidor de mensagens do destinatário. Os destinatários nunca veem o envelope da mensagem, pois ele é gerado pelo processo de transmissão de mensagens e não faz parte da mensagem.

Cada servidor envolvido na transmissão da mensagem pode inserir campos de cabeçalho de mensagem relacionados à função do servidor na entrega da mensagem ou de outros campos de cabeçalho de mensagem específicos do aplicativo no cabeçalho da mensagem. Quando o destinatário abre a mensagem usando um cliente de email, o cliente de email exibe algumas das informações mais relevantes do cabeçalho da mensagem, como o remetente, os destinatários e o assunto junto com o corpo da mensagem.

Como os diretórios Pickup e Replay processam mensagens

No Exchange 2013, o local padrão do diretório pickup é %ExchangeInstallPath%TransportRoles\Pickup. O local padrão do diretório Replay é %ExchangeInstallPath%TransportRoles\Replay. Um arquivo de mensagem .eml formatado corretamente copiado para o diretório Pickup ou Replay é processado para envio nas seguintes etapas:

Os diretórios Pickup e Replay são verificados para novos arquivos de mensagens a cada cinco segundos. Você não pode modificar esse intervalo de votação. Você pode ajustar a taxa de processamento de arquivo de mensagem usando o parâmetro PickupDirectoryMaxMessagesPerMinute no cmdlet Set-TransportService . Esse parâmetro afeta o diretório Pickup e o diretório Replay. O valor padrão é 100 mensagens por minuto. Os arquivos que não podem ser abertos são deixados no diretório Pickup e são reavaliados na próxima votação.
Os limites colocados em arquivos de mensagem no diretório Pickup, como o tamanho máximo do cabeçalho e o número máximo de destinatários, são verificados. Por padrão, o tamanho máximo do cabeçalho é de 64 quilobytes (KB) e o número máximo de destinatários é 100. Você altera esses limites usando o cmdlet Set-TransportService . Essas configurações afetam apenas o diretório Pickup.
O arquivo é renomeado de <filename.eml> para <filename.tmp>. Se o <arquivo filename.tmp> já existir, o arquivo será renomeado como <filename><datetime.tmp>. Se a renomeação do arquivo falhar, um erro de log de eventos será gerado e o processo de coleta prosseguirá para o próximo arquivo.
Depois que o arquivo .tmp for convertido com êxito em uma mensagem de email, uma exclusão no comando close será emitida para o arquivo .tmp. O arquivo .tmp parece permanecer no diretório Pickup, mas o arquivo não pode ser aberto.
Depois que a mensagem é enfileirada com êxito para entrega, um comando close é emitido e o arquivo .tmp é excluído do diretório Pickup. Se a exclusão falhar, um erro de log de eventos será gerado. Se o serviço de Transporte do Microsoft Exchange for reiniciado quando houver arquivos .tmp no diretório Pickup, todos os arquivos .tmp serão renomeados como arquivos .eml e serão reprocessados. Isso pode levar à transmissão de mensagens duplicadas.

Requisitos de arquivo de mensagem do diretório de coleta

Um arquivo de mensagem copiado para o diretório pickup deve atender aos seguintes requisitos para entrega bem-sucedida:

O arquivo de mensagem deve ser um arquivo de texto que esteja em conformidade com o formato básico de mensagem SMTP. Há suporte para campos e conteúdo de cabeçalho de mensagem MIME.
O arquivo de mensagem deve ter uma extensão de nome do arquivo .eml.
Pelo menos um endereço de email deve existir nos campos de Sender cabeçalho ou From mensagem no cabeçalho da mensagem. Se existir um único endereço de email nos Sender campos e From , o endereço de email no From campo será usado como o criador da mensagem no envelope da mensagem.
Somente um endereço de email pode existir no Sender campo. Vários endereços de email não são permitidos. O Sender campo será opcional se houver apenas um endereço de email no From campo.
Vários endereços de email são permitidos no From campo, mas um único endereço de email também deve existir no Sender campo. O endereço no Sender campo é então usado como o criador da mensagem no envelope da mensagem.
Pelo menos um endereço de email deve existir nos Tocampos , Ccou Bcc .
Uma linha em branco deve existir entre o cabeçalho da mensagem e o corpo da mensagem.

Este exemplo mostra uma mensagem de texto simples que usa a formatação aceitável para o diretório Pickup.

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

This is the body of the message.

O conteúdo MIME também tem suporte em arquivos de mensagens do diretório pickup. O MIME define uma ampla gama de conteúdo de mensagens que inclui idiomas que não podem ser representados em texto ASCII de 7 bits, HTML e outros conteúdos multimídia. Uma descrição completa do MIME e seus requisitos está além do escopo deste tópico. Este exemplo mostra uma mensagem MIME simples que usa a formatação aceitável para o diretório Pickup.

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>

Modificações de cabeçalho de mensagem do diretório de pickup

O diretório Pickup remove qualquer um dos seguintes campos de cabeçalho de mensagem do cabeçalho da mensagem:

Received
Resent-*
Bcc

Observação

Todos os endereços de email encontrados nos campos de cabeçalho de mensagem opcional Bcc no cabeçalho da mensagem são processados corretamente. Depois que os Bcc destinatários são promovidos a destinatários invisíveis do envelope de mensagens, eles são removidos do cabeçalho da mensagem para proteger sua identidade. Se uma mensagem contiver apenas Bcc destinatários, o valor de Destinatários não revelados será adicionado ao To campo no cabeçalho da mensagem.

O diretório Pickup adiciona seu próprio Received campo de cabeçalho a uma mensagem como parte do processo de envio de mensagens. O Received campo de cabeçalho é aplicado no formato a seguir.

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

O diretório Pickup modificará os seguintes campos de cabeçalho de mensagem se eles estiverem ausentes ou malformados:

Id de mensagem: se o Message-Id campo estiver ausente ou vazio, o diretório Pickup adicionará um campo Message-Id usando o formato <GUID>@<defaultdomain>.
Data: se o Date campo estiver ausente ou malformado, o diretório Pickup adicionará a data e a hora do processamento de mensagens pelo diretório Pickup.

Requisitos de arquivo de mensagem de diretório de reprodução

O Diretório de repetição é usado para reenviar mensagens do Exchange exportadas e para receber mensagens de servidores de gateway externos. Essas mensagens já estão formatadas para o Diretório de repetição. Há pouca ou nenhuma necessidade de administradores ou aplicativos para compor e enviar novos arquivos de mensagem usando o diretório Replay. O diretório Pickup deve ser usado para criar e enviar novos arquivos de mensagem.

As mensagens de diretório replay fazem uso extensivo de Cabeçalhos X. Cabeçalhos X são campos de cabeçalho de mensagem não oficiais definidos pelo usuário que existem no cabeçalho da mensagem. Os cabeçalhos X não são mencionados especificamente no RFC 2822, mas o uso de um campo de cabeçalho de mensagem indefinido começando com "X-" tornou-se uma maneira aceita de adicionar campos de cabeçalho de mensagem não oficiais a uma mensagem. Os Cabeçalhos X específicos do Exchange usados nos arquivos de mensagem no diretório Replay podem realmente definir informações de entrega que normalmente existem no envelope da mensagem. Esse recurso é necessário para preservar informações de mensagem originais quando você usa o diretório Replay para processar mensagens exportadas de outro servidor do Exchange.

Um arquivo de mensagem copiado para o diretório Replay deve atender aos seguintes requisitos para entrega bem-sucedida:

O arquivo de mensagem deve ser um arquivo de texto que esteja em conformidade com o formato básico de mensagem SMTP. Há suporte para campos e conteúdo de cabeçalho de mensagem MIME.
O arquivo de mensagem deve ter uma extensão de nome do arquivo .eml.
Os cabeçalhos X devem ocorrer antes de todos os campos de cabeçalho regulares.
Uma linha em branco deve existir entre os campos de cabeçalho e o corpo da mensagem.

Os Cabeçalhos X descritos na lista a seguir são exigidos por mensagens no diretório Replay:

X-Sender: este cabeçalho X substitui o requisito de campo de cabeçalho de From mensagem em uma mensagem SMTP típica. Um X-Sender campo que contém um endereço de email deve existir. O diretório Replay ignora o From campo cabeçalho da mensagem se ele estiver presente, embora o cliente de email do destinatário exiba o valor do campo de cabeçalho da From mensagem como o remetente da mensagem. Outros parâmetros geralmente existem no X-Sender campo, conforme mostrado no exemplo a seguir.
```
X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
```
Observação

Esses parâmetros são valores de envelope de mensagem que normalmente são gerados pelo servidor de envio. Você pode ver parâmetros semelhantes a este em arquivos de mensagens exportados.

RET especifica se a mensagem inteira ou apenas os cabeçalhos devem ser retornados ao remetente se a mensagem não puder ser entregue. RET pode ter um valor de HDRS ou FULL. ENVID é um identificador de envelope de mensagem. BODY especifica a codificação de texto da mensagem. auth especifica um mecanismo de autenticação para o servidor de mensagens, conforme descrito no RFC 2554.
X-Receiver: este cabeçalho X substitui o requisito do campo de cabeçalho de To mensagem em uma mensagem SMTP típica. Pelo menos um X-Receiver campo que contém um endereço de email deve existir. Vários X-Receiver campos são permitidos para vários destinatários. O diretório Replay ignora os campos de To cabeçalho de mensagem se eles estiverem presentes, embora o cliente de email do destinatário exiba os valores dos campos de cabeçalho da To mensagem como destinatários da mensagem. Outros parâmetros opcionais podem existir nos X-Receiver campos, conforme mostrado no exemplo a seguir.
```
X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
```
Observação

Esses parâmetros são valores de envelope de mensagem que normalmente são gerados pelo servidor de envio. Você pode ver parâmetros semelhantes a este em arquivos de mensagens exportados. Esses parâmetros estão relacionados a mensagens DSN (notificação de status de entrega), conforme descrito no RFC 1891.

NOTIFY pode ter um valor de NEVER, DELAYou FAILURE. ORcpt preserva o destinatário original da mensagem.

Os Cabeçalhos X descritos na lista a seguir são opcionais para arquivos de mensagem no diretório Replay:

X-CreatedBy: usado para funcionalidade de firewall de cabeçalho. Se esse Cabeçalho X existir, ele não deverá estar em branco. Se o X-CreatedBy campo não existir, ele será adicionado com um valor de Não especificado. Normalmente, o valor desse campo é MSExchange15, mas também pode conter o tipo de espaço de endereço não SMTP definido em um conector Send, como Anotações.
X-EndOfInjectedXHeaders: tamanho em bytes de todos os Cabeçalhos X presentes. Esse Cabeçalho X pode ser usado como um marcador para indicar o último Cabeçalho X antes do início dos campos de cabeçalho de mensagem regulares.
X-ExtendedMessageProps: propriedades de mensagem estendidas para a mensagem.
X-HeloDomain: cadeia de caracteres de domínio HELO/EHLO apresentada durante a conversa inicial do protocolo SMTP.
Fonte X: usada pelo visualizador de filas na coluna MessageSourceName . Se o valor desse Cabeçalho X não for especificado, o valor de Replay será usado. Outros valores possíveis para este X-Header são Conector de Recebimento Smtp e Conector de Envio Smtp.
X-SourceIPAddress: endereço IP do servidor de envio. Esse campo será 0.0.0.0 se nenhum endereço IP for especificado.

Este exemplo mostra uma mensagem de texto simples que usa a formatação aceitável para o diretório Replay.

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.

Também há suporte para conteúdo MIME nos arquivos de mensagens do diretório Replay. O MIME define uma ampla gama de conteúdo de mensagens que inclui idiomas que não podem ser representados em texto ASCII de 7 bits, HTML e outros conteúdos multimídia. Uma descrição completa do MIME e seus requisitos está além do escopo deste tópico. Este exemplo mostra uma mensagem MIME simples que usa a formatação aceitável para o diretório Replay.

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>

Modificações de cabeçalho de mensagem de diretório de reprodução

O diretório Replay exclui o Bcc campo cabeçalho da mensagem do arquivo de mensagem.

O diretório Replay adiciona seu próprio Received campo de cabeçalho de mensagem a uma mensagem como parte do processo de envio de mensagens. O campo cabeçalho de mensagem recebida é aplicado no formato a seguir.

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

O diretório Replay modifica os seguintes campos de cabeçalho de mensagem no cabeçalho da mensagem:

ID da mensagem: se esse campo de cabeçalho de mensagem estiver ausente ou vazio, o diretório Replay adicionará um campo de cabeçalho de mensagem ID de mensagem usando o formato <GUID>@<defaultdomain>.
Data: se esse campo de cabeçalho de mensagem estiver ausente ou malformado, o diretório Replay adicionará o campo cabeçalho de mensagem Date usando a data e a hora do processamento de mensagens pelo diretório Replay.

Falhas no processamento de mensagens de diretório de coleta e reprodução

Um arquivo de mensagem copiado para os diretórios Pickup ou Replay pode não ser enfileirado com êxito para entrega. As seguintes categorias de falha de envio de mensagem podem ocorrer:

Falhas de entrega: um arquivo de mensagem formatado corretamente junto com um remetente válido que não pode ser enviado com êxito para entrega gera um NDR (relatório de não entrega). O conteúdo malformado ou as violações de restrição de mensagem do diretório pickup também podem causar uma NDR. Quando uma NDR é gerada durante o processamento de mensagens, o arquivo de mensagem original é anexado à mensagem NDR e o arquivo de mensagem é excluído do diretório Pickup ou do diretório Replay.

Observação

Uma mensagem formatada corretamente enviada no pipeline de transporte pode mais tarde sofrer uma falha de entrega e ser retornada ao remetente com uma NDR. Esse tipo de falha pode ser causada por problemas de transmissão não relacionados aos diretórios Pickup ou Replay, como falhas no servidor de mensagens ou falhas de roteamento ao longo do caminho de entrega da mensagem.
Badmail: uma mensagem classificada como badmail tem sérios problemas que impedem que os diretórios Pickup ou Replay enviem a mensagem para entrega. A outra condição que causa o erro é quando a mensagem é formatada corretamente, mas os destinatários não são válidos, e uma mensagem NDR não pode ser enviada ao remetente porque o remetente não é válido.

Os arquivos de mensagem determinados como badmail são deixados nos diretórios Pickup ou Replay e são renomeados de <filename.eml> para <filename.bad>. Se o <arquivo filename.bad> já existir, o arquivo será renomeado para <filename><datetime.bad>. Se houver uma mensagem incorreta nos diretórios Pickup ou Replay, um erro de log de eventos será gerado, mas as mesmas mensagens de mensagem incorreta não gerarão erros repetidos de log de eventos.

Observação

Sempre componha e salve arquivos de mensagem em um local diferente antes de copiá-los no diretório Pickup para entrega. O diretório pickup pesquisa novas mensagens a cada cinco segundos. Portanto, se você tentar compor e salvar os arquivos de mensagem no próprio diretório Pickup, o diretório Pickup poderá tentar processar os arquivos de mensagem antes de concluir a composição deles.

Considerações de segurança para os diretórios Pickup e Replay

A lista a seguir descreve as preocupações de segurança comuns ao diretório Pickup e ao diretório Replay:

Todas as verificações de segurança configuradas em um conector de Recebimento, como anti-spam, anti-malware, filtragem de remetente ou ações de filtragem de destinatário, não são executadas em mensagens enviadas por meio do diretório Pickup ou do diretório Replay.
Um diretório pickup comprometido ou diretório Replay pode atuar como um retransmissão aberta. Isso permite que as mensagens sejam reenviadas ou retransmitidas usando um servidor diferente para mascarar a verdadeira fonte das mensagens.

A lista a seguir descreve preocupações adicionais de segurança que se aplicam ao diretório Replay:

Os Cabeçalhos X usados pelo diretório Replay permitem a criação manual do envelope da mensagem. As informações nos X-Sender campos e X-Receiver podem ser completamente diferentes dos To campos de cabeçalho de mensagem ou From exibidos por clientes de email. Essa representação de um remetente e um domínio é frequentemente chamada de falsificação. Um email falsificado é email que possui um endereço de envio que foi modificado para parecer ter sido enviado por outro remetente que não o remetente real do email.
Se o X-CreatedBy campo tiver o valor de MSExchange15, o destino será considerado confiável e o firewall de cabeçalho não será aplicado. O firewall de cabeçalho é uma maneira do Exchange preservar X-Headers em mensagens transmitidas entre servidores confiáveis do Exchange ou remover potencialmente os X-Headers de mensagens transmitidas para destinos não confiáveis fora da organização do Exchange. Esses Cabeçalhos X podem ser usados para compartilhar informações do Exchange, como nível de confiança de spam (SCL), assinatura de mensagens ou criptografia entre servidores autorizados do Exchange. Revelar essas informações a fontes não autorizadas pode representar um risco potencial para a segurança. Para obter mais informações sobre o firewall de cabeçalho, consulte Noções básicas sobre firewall de cabeçalho.

Uma segurança mais rigorosa deve ser aplicada ao diretório Replay devido aos riscos adicionais de segurança associados ao diretório Replay. Usuários ou aplicativos que devem gerar e enviar mensagens podem ter acesso ao diretório Pickup, mas não devem exigir acesso ao diretório Replay.

O diretório Pickup e o diretório Replay estão habilitados por padrão em todos os servidores de caixa de correio e servidores de Transporte de Borda. Se o diretório Pickup ou o diretório Replay não for necessário em um servidor de caixa de correio específico ou servidor do Edge Transport em sua organização, você poderá desabilitar o diretório Pickup ou o diretório Replay nesse servidor definindo o caminho do diretório Pickup ou o caminho do diretório Replay para o valor $null. Para obter mais informações, consulte Configurar o diretório Pickup e o diretório Replay.

Permissões para os diretórios Pickup e Replay

As seguintes permissões são necessárias nos diretórios Pickup e Replay:

Administrador: controle completo
Sistema: Controle Total
Serviço de Rede: Ler, Gravar e Excluir Subpastas e Arquivos

Por padrão, o serviço de Transporte do Microsoft Exchange usa as credenciais de segurança da conta de usuário do Serviço de Rede para gerenciar o local e as permissões dos diretórios Pickup e Replay. A conta do Serviço de Rede requer essas permissões no diretório Pickup para que os arquivos .eml possam ser abertos, renomeados como .tmp e excluídos ou renomeados como .bad se a mensagem for classificada como badmail.

Você pode mover o local desses diretórios usando os parâmetros PickupDirectoryPath e ReplayDirectoryPath no cmdlet Set-TransportService . A alteração com êxito do local do diretório pickup depende dos direitos concedidos à conta do Serviço de Rede nos novos locais de diretório e se os novos diretórios já existem. Se o diretório não existir e a conta do Serviço de Rede tiver os direitos necessários para criar pastas e aplicar permissões no novo local, o diretório será criado e as permissões corretas serão aplicadas a ele. Se o novo diretório já existir, as permissões de pasta existentes não serão verificadas. Sempre que você mover os locais do diretório usando o parâmetro PickupDirectoryPath ou ReplayDirectoryPath com o cmdlet Set-TransportService , verifique sempre se o novo diretório existe e se o novo diretório tem as permissões corretas aplicadas a ele.

Partilhar via