Share via


Entendendo os Diretórios de Retirada e de Repetição

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2009-10-14

Por padrão, os diretórios de recebimento e reprodução existem em cada computador executando o Microsoft Exchange Server 2010 que tem a função de servidor de Transporte de Hub ou a função de servidor de Transporte de Borda instalada. Os arquivos de mensagens de email formatados corretamente que você copia para o Diretório de recebimento e reprodução são enviados para entrega. O diretório de recebimento é usado para administradores para teste de fluxo de email ou por aplicativos que devem criar e enviar suas próprias mensagens. O diretório de reprodução recebe mensagens de servidores de gateway externos e também pode ser usado para enviar mensagens que os administradores exportarem de filas de servidores Exchange 2010.

Procurando tarefas de gerenciamento relacionadas aos diretórios de recebimento e reprodução? Consulte Gerenciando Conectores.

Sumário

Anatomia de um arquivo de mensagens de email

Como o Diretório de recebimento processa mensagens

Como o Diretório de repetição processa mensagens

Considerações de segurança para os diretório de recebimento e repetição

Permissões para diretórios de recebimento e repetição

Anatomia de um arquivo de mensagens de email

Uma mensagem de email SMTP padrão consiste em um envelope de mensagem e no conteúdo da mensagem. O envelope da mensagem contém informações necessárias para a transmissão e a entrega da mensagem. O conteúdo da mensagem contém campos de cabeçalho de mensagem que são coletivamente denominados 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 para a mensagem, usando as informações do remetente e do destinatário encontradas no cabeçalho da mensagem, e transmite a mensagem à Internet para ser entregue ao servidor de mensagens do destinatário. Os destinatários nunca veem o envelope de mensagem, pois ele é gerado pelo processo de transmissão da mensagem e não faz parte realmente da mensagem.

Cada servidor envolvido na transmissão da mensagem pode inserir campos de cabeçalho de mensagem relacionados à função do servidor, ao entregar a mensagem, ou 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, juntamente com o corpo da mensagem.

Voltar ao início

Como o Diretório de recebimento processa mensagens

Um arquivo de mensagem .eml corretamente formatado, que é copiado para o Diretório de recebimento, é processado para envio nas seguintes etapas:

  1. Uma verificação de novos arquivos de mensagens é feita no Diretório de recebimento a cada 5 segundos. Você não pode modificar esse intervalo de pesquisa. Você pode ajustar a taxa de processamento do arquivo de mensagens usando o parâmetro PickupDirectoryMaxMessagesPerMinute no cmdlet Set-TransportServer. O valor padrão é de 100 mensagens por minuto. Os arquivos que não podem ser abertos são mantidos no Diretório de recebimento e são reavaliados na próxima sondagem.

  2. São verificados os limites colocados nos arquivos de mensagens no Diretório de recebimento, como o tamanho máximo do cabeçalho e o número máximo de destinatários. Por padrão, o tamanho máximo do cabeçalho é 64 kilobytes (KB) e o número máximo de destinatários é 100. Mude esses limites usando o cmdlet Set-TransportServer.

  3. O arquivo é renomeado de <nome_do_arquivo>.eml para <nome_do_arquivo>.tmp. Se o arquivo <nome_do_arquivo>.tmp já existir, o arquivo será renomeado como <nome_do_arquivo><data_e_hora>.tmp. Se ocorrer falha na renomeação do arquivo, um erro de log de eventos será gerado e o processo de recebimento continuará no próximo arquivo.

  4. Depois que o arquivo .tmp é convertido com êxito em uma mensagem de email, um comando excluir ao fechar é emitido para o arquivo .tmp. O arquivo .tmp parece continuar no Diretório de recebimento, mas o arquivo não pode ser aberto por nenhum outro usuário.

  5. Depois que a mensagem é enfileirada para entrega um comando fechar é emitido, e o arquivo .tmp é excluído do diretório de recebimento. Se a exclusão falhar, será gerado um erro de log de eventos. Se o serviço de Transporte do Microsoft Exchange for reiniciado quando houver arquivos .tmp no Diretório de recebimento, todos os arquivos .tmp serão renomeados como arquivos .eml e serão reprocessados. Isso poderia resultar em transmissão de mensagens duplicadas.

Requisitos para arquivos de mensagens no Diretório de recebimento

Um arquivo de mensagens que é copiado para o Diretório de recebimento deve atender os seguintes requisitos para que a entrega seja bem-sucedida:

  • O arquivo de mensagem deve ser um arquivo de texto compatível com o formato de mensagem SMTP básico. Os campos e o conteúdo de cabeçalho de mensagem MIME têm suporte.

  • O arquivo de mensagem deve ter uma extensão de nome de arquivo .eml.

  • Pelo menos um endereço de email deve constar nos campos de cabeçalho da mensagem, Remetente ou De Se existir apenas um endereço de email nos campos Remetente e De, o endereço de email no campo De será usado como remetente da mensagem no envelope da mensagem.

  • Só pode existir um endereço de email no campo Remetente. Não são permitidos vários endereços de email. O campo Remetente será opcional se houver apenas um endereço de email no campo De.

  • Vários endereços de email são permitidos no campo De, mas um endereço de email único também deve existir no campo Remetente. O endereço no campo Remetente é, então, usado como remetente da mensagem no envelope da mensagem.

  • Pelo menos um endereço de email deve existir nos campos Para, Cc ou Bcc.

  • Deve existir uma linha em branco entre o cabeçalho e o corpo da mensagem.

Este exemplo mostra uma mensagem de texto comum que usa formatação aceitável para o Diretório de recebimento

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 nos arquivos de mensagens do Diretório de recebimento. O MIME define uma ampla variedade de conteúdo de mensagens que inclui idiomas que podem ser representados em texto ASCII de 7 bits, HTML e outro conteúdo multimídia. Uma descrição completa de MIME e seus requisitos está além do escopo deste tópico. Este exemplo mostra uma mensagem de MIME que usa formatação aceitável para o Diretório de recebimento.

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 no cabeçalho da mensagem feitas em arquivos de mensagens do Diretório de recebimento

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

  • Received

  • Resent-*

  • Bcc

    Dica

    Todos os endereços de email encontrados nos campos opcionais do cabeçalho da mensagem Bcc são processados corretamente. Depois de serem transformados em destinatários invisíveis de envelope de mensagem, eles são removidos do cabeçalho da mensagem para proteger suas identidades. Se uma mensagem contiver apenas destinatários Bcc, o valor de "Undisclosed Recipients" será adicionado ao campo Para no cabeçalho da mensagem.

O Diretório de recebimento adiciona seu próprio campo de cabeçalho Recebido a uma mensagem como parte do processo de envio da mensagem. O campo de cabeçalho Recebido é aplicado no seguinte formato:

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

O Diretório de recebimento modificará os seguintes campos do cabeçalho da mensagem, se estiverem ausentes ou malformados:

  • Message-Id   Se esse campo de Identificação de Mensagem estiver ausente ou vazio, o Diretório de recebimento adicionará um campo de Identificação de mensagem usando o formato <GUID>@<defaultdomain>.

  • Data   Se o campo Data estiver ausente ou malformado, o Diretório de recebimento adicionará a data e hora do processamento da mensagem pelo Diretório de recebimento.

Falhas no processamento da mensagem do Diretório de recebimento

Um arquivo de mensagem copiado no Diretório de recebimento pode não ser colocado em fila para entrega com êxito. Podem ocorrer as seguintes categorias de falhas de envio de mensagens:

  • Falhas na entrega   Um arquivo de mensagem com formatação correta junto com um remetente válido que não pode ser enviado com êxito para entrega pelo Diretório de recebimento gera uma notificação de falha na entrega (NDR). Conteúdo malformado ou violações de restrições de mensagem do Diretório de recebimento também poderão fazer com que o Diretório de recebimento gere uma notificação de falha na entrega. Quando uma notificação de falha na entrega é gerada durante o processamento de mensagens do Diretório de recebimento, o arquivo de mensagem original é anexado à mensagem de notificação de falha na entrega e o arquivo de mensagem é excluído do Diretório de recebimento.

    Dica

    Uma mensagem formatada corretamente enviada pelo Diretório de recebimento pode sofrer falha na entrega e ser devolvida ao remetente com uma notificação de falha na entrega. Esse tipo de falha pode ser causado por problemas de transmissão não relacionados ao Diretório de recebimento, como falhas no servidor de mensagens ou falhas de roteamento no caminho de entrega da mensagem.

  • Inválida   Uma mensagem classificada como inválida tem problemas sérios que impedem que o Diretório de recebimento envie a mensagem para entrega. A outra condição que causa mensagens inválidas é quando a mensagem está corretamente formatada, mas os destinatários não são válidos, e uma mensagem de notificação de falha na entrega não pode ser enviada ao remetente, pois ele não é válido.

    Arquivos de mensagem determinados como sendo inválidos são deixados no diretório de recebimento e são renomeados de <nome_do_arquivo>.eml para <nome_do_arquivo>.bad. Se o arquivo <nome_do_arquivo>.bad já existir, o arquivo será renomeado para <nome_do_arquivo><data_e_hora>.bad. Se existirem mensagens inválidas no Diretório de recebimento, será gerado um erro do log de eventos, mas as mesmas mensagens inválidas não gerarão erros repetidos do log de eventos.

    Dica

    Sempre escreva e salve os arquivos de mensagens em um local diferente antes de copiá-los no Diretório de recebimento para entrega. O Diretório de recebimento sonda novas mensagens a cada 5 segundos. Portanto, se você tentar redigir e salvar os arquivos de mensagens dentro do próprio Diretório de recebimento, ele pode tentar processar os arquivos de mensagens antes que você termine de redigi-los.

Voltar ao início

Como o Diretório de repetição processa mensagens

Um arquivo de mensagem .eml corretamente formatado, que é copiado para o Diretório de de Reprodução, é processado para envio nas seguintes etapas:

  1. Uma verificação de novos arquivos de mensagens é feita no Diretório de reprodução a cada 5 segundos. Você não pode modificar esse intervalo de pesquisa. Você pode ajustar a taxa de processamento do arquivo de mensagens usando o parâmetro PickupDirectoryMaxMessagesPerMinute no cmdlet Set-TransportServer. O valor padrão é de 100 mensagens por minuto. Os arquivos que não podem ser abertos são mantidos no Diretório de reprodução e são reavaliados na próxima sondagem.

  2. O arquivo é renomeado de <nome_do_arquivo>.eml para <nome_do_arquivo>.tmp. Se o arquivo *<nome_do_arquivo>.*tmp já existir, o arquivo será renomeado como <nome_do_arquivo><data_e_hora>.tmp. Se a renomeação do arquivo falhar, um erro de log de eventos será gerado e o processo de Repetição continuará no próximo arquivo.

  3. Depois que o arquivo .tmp é convertido com êxito em uma mensagem de email, um comando excluir ao fechar é emitido para o arquivo .tmp. O arquivo .tmp parece continuar no Diretório de reprodução, mas o arquivo não pode ser aberto.

  4. Depois que a mensagem é enfileirada para entrega com êxito, um comando fechar é emitido, e o arquivo .tmp é excluído do diretório de reprodução. Se a exclusão falhar, será gerado um erro de log de eventos. Se o serviço de Transporte do Microsoft Exchange for reiniciado quando houver arquivos .tmp no Diretório de repetição, todos os arquivos .tmp serão renomeados como arquivos .eml e serão reprocessados. Isso poderia resultar em transmissão de mensagens duplicadas.

Requisitos para arquivos de mensagens do Diretório de repetição

O Diretório de repetição é usado para reenviar mensagens exportadas do Exchange e para receber mensagens de servidores gateway externos. Essas mensagens já estão formatadas para o Diretório de repetição. Há pouca ou nenhuma necessidade de um administrador ou outro aplicativo criar e enviar novos arquivos de mensagens usando o Diretório de repetição. O Diretório de recebimento deve ser usado para criar e enviar novos arquivos de mensagens.

As mensagens do Diretório de repetição fazem muito uso de Cabeçalhos X. Os 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 especificamente mencionados no RFC 2822, mas o uso de um campo de cabeçalho de mensagem não definido 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 2010 usados nos arquivos de mensagem do Diretório de reprodução podem definir informações de entrega normalmente existentes no envelope de mensagem. Esse recurso é necessário para preservar informações da mensagem original quando você usa o Diretório de repetição para processar mensagens exportadas de outro servidor Exchange.

Um arquivo de mensagens que é copiado para o Diretório de repetição deve atender os seguintes requisitos para que a entrega seja bem-sucedida:

  • O arquivo de mensagem deve ser um arquivo de texto compatível com o formato de mensagem SMTP básico. Os campos e o conteúdo de cabeçalho de mensagem MIME têm suporte.

  • O arquivo de mensagem deve ter uma extensão de nome de arquivo .eml.

  • Os Cabeçalhos X devem ocorrer antes de todos os campos de cabeçalho normais.

  • Deve existir uma linha em branco 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 do Diretório de repetição:

  • X-Sender     Esse Cabeçalho X substitui o requisito de campo de cabeçalho de mensagem De X em uma mensagem SMTP típica. Deve existir um campo Remetente X que contenha um endereço de email. O Diretório de repetição ignora o campo de cabeçalho de mensagem De, caso ele exista, mas o cliente de email do destinatário exibe o valor do campo de cabeçalho de mensagem De como o remetente da mensagem. Outros parâmetros geralmente existem no campo Remetente X, conforme mostrado no exemplo a seguir:

    X-Sender: <bob@fabrikam.com> BODY=7bit RET=HDRS ENVID=12345ABCD auth=<someAuth>
    

    Dica

    Esses parâmetros são valores do envelope de mensagem que são normalmente gerados pelo servidor de envio. Você pode ver parâmetros semelhantes a este em arquivos de mensagens exportadas.
    RET especifica se toda a mensagem ou somente cabeçalhos devem ser retornados para o remetente se a mensagem não puder ser entregue. O RET poderá 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 mensagem conforme descrito no RFC 2554.

  • Destinatário X     Esse Cabeçalho X substitui o requisito de campo de cabeçalho de mensagem Para em uma mensagem SMTP típica. Deve existir pelo menos um campo do Destinatário X que contenha um endereço de email. São permitidos vários campos de Destinatário X para vários destinatários. O Diretório de repetição ignora os campos de cabeçalho de mensagem Para, caso eles existam, mas o cliente de email do destinatário exibe os valores dos campos de cabeçalho de mensagem como os destinatários da mensagem. Outros parâmetros opcionais podem existir nos campos de Destinatário X, conforme mostrado no exemplo a seguir:

    X-Receiver: <mary@contoso.com> NOTIFY=NEVER ORcpt=mary@contoso.com
    

    Dica

    Esses parâmetros são valores do envelope de mensagem que são normalmente gerados pelo servidor de envio. Você pode ver parâmetros semelhantes a este em arquivos de mensagens exportadas. Esses parâmetros estão relacionados com as mensagens de notificação de status de entrega (DSN), conforme descrito no RFC 1891.
    NOTIFY pode ter um valor de NEVER, DELAY ou FAILURE. ORcpt preserva o destinatário original da mensagem.

Os Cabeçalhos X descritos na lista a seguir são opcionais para arquivos de mensagens no Diretório de repetição.

  • X CreatedBy   Usada para funcionalidade de firewall de cabeçalho. Se esse Cabeçalho X existir, ele não deverá ficar em branco. Se o campo X CreatedBy não existir, ele é adicionado com um valor de Unspecified. Normalmente, o valor desse campo é MSExchange14, mas ele também pode conter o tipo de espaço de endereçamento não-SMTP definido em um conector de envio, como Notes.

  • 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    A cadeia de caracteres do domínio HELO/EHLO apresentada durante a conversação inicial de protocolos SMTP.

  • X LegacyExch50   Usado para preservar a propriedades personalizadas geradas pelo Exchange Server 2003 se Exchange 2003 servidores estão presentes.

  • X-Source   Usados pelo Visualizador de fila sob a coluna de MessageSourceName. Se o valor desse Cabeçalho X não for especificado, será usado o valor Replay. Outros valores possíveis para esse Cabeçalho X são Smtp Receive Connector e Smtp Send Connector.

  • X-SourceIPAddress   O endereço 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 comum que usa formatação aceitável para o Diretório de repetição

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.

Conteúdo de MIME também têm suporte em arquivos de mensagem do Diretório de repetição. O MIME define uma ampla variedade de conteúdo de mensagens que inclui idiomas que podem ser representados em texto ASCII de 7 bits, HTML e outro conteúdo multimídia. Uma descrição completa de MIME e seus requisitos está além do escopo deste tópico. Este exemplo mostra uma mensagem de MIME que usa formatação aceitável para o Diretório de repetição.

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 no cabeçalho de mensagem feitas em arquivos de mensagens do Diretório de repetição

O Diretório de repetição exclui o campo de cabeçalho de mensagem Cco do arquivo de mensagem.

O Diretório de repetição adiciona seu próprio campo de cabeçalho Recebido a uma mensagem, como parte do processo de envio da mensagem. O campo de cabeçalho Recebido é aplicado no seguinte formato:

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

O Diretório de repetição modifica os seguintes campos de cabeçalho de mensagem no cabeçalho da mensagem:

  • Message-Id   Se esse campo de cabeçalho de mensagem estiver ausente ou vazio, o Diretório de repetição adicionará um campo de de Identificação de mensagem usando o formato <GUID>@<defaultdomain>.

  • Data    Se esse campo de cabeçalho de mensagem estiver ausente ou malformado, o Diretório de repetição adicionará o campo de cabeçalho de mensagem Data usando a data e horário do processamento da mensagem pelo diretório de repetição.

Falhas no processamento da mensagem do Diretório de repetição

Quaisquer problemas que convertem um arquivo de mensagens em uma mensagem de email fazem com que o Diretório de repetição considere a mensagem não entregável (mensagens inválidas). Um arquivo de mensagens inválidas tem sérios problemas, como remetente ausente, destinatários ausentes ou problemas de formatação. Arquivos de mensagem determinados como sendo inválidos no diretório de repetição e renomeados de <nome_do_arquivo>.eml para <nome_do_arquivo>.bad. Se o arquivo <nome_do_arquivo>.bad já existir, o arquivo será renomeado para <nome_do_arquivo><data_e_hora>.bad. Se existirem mensagens inválidas no Diretório de repetição, será gerado um erro do log de eventos, mas as mesmas mensagens inválidas não gerarão erros repetidos do log de eventos.

Voltar ao início

Considerações de segurança para os diretório de recebimento e repetição

A lista a seguir descreve problemas de segurança comuns para os Diretórios de recebimento e de repetição:

  • Todas as verificações de segurança configuradas em um conector de recebimento, como anti-spam, filtragem de remetentes ou ações de filtragem de destinatários, não são executadas em mensagens enviadas através do Diretório de recebimento ou de repetição.

  • Um Diretório de recebimento ou um Diretório de repetição comprometido pode agir como uma retransmissão aberta. Isso permite que as mensagens sejam reenviadas ou retransmitidas usando um servidor diferente para mascarar a verdadeira origem das mensagens.

A lista a seguir descreve problemas de segurança adicionais que se aplicam ao Diretório de repetição.

  • Os Cabeçalhos X usados pelo Diretório de repetição permitem a criação manual do envelope de mensagem. Esta informação nos campos Remetente X e Destinatário X pode ser completamente diferente dos campos de cabeçalho de mensagem Para ou De exibida por clientes de email. Essa impersonalização de um remetente e um domínio e frequentemente chamado de spoofing. Um email falsificado é um 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 da mensagem.

  • Se o campo X-CreatedBy tiver o valor de MSExchange14, o destino é considerado confiável e um firewall de cabeçalho não é aplicado. Um firewall de cabeçalho é uma maneira de o Exchange preservar os Cabeçalhos X em mensagens transmitidas entre servidores Exchange 2010 confiáveis ou remover Cabeçalhos X possivelmente reveladores 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 2010, como SCL (nível de confiança de spam), assinatura de mensagens ou criptografia, entre servidores Exchange 2010 autorizados. A revelação dessas informações para origens não autorizadas poderá representar um possível risco de segurança.

Uma maior segurança deve ser aplicada ao Diretório de repetição, devido aos riscos de segurança adicionais associados ao diretório de repetição. Usuários ou aplicativos que precisam gerar e enviar mensagens podem ter acesso concedido ao Diretório de recebimento, mas não devem requerer acesso ao Diretório de repetição.

O Diretórios de recebimento e o Diretório de repetição são habilitados por padrão em todos os servidores de Transporte de Hub e Transporte de Borda. Se o diretório de recebimento ou o diretório de repetição não seja necessário em um servidor de Transporte Específico ou servidor de Transporte de Borda em sua organização, você pode desabilitar o diretório de recebimento ou o diretório de repetição nesse servidor. Para obter mais informações, consulte os seguintes tópicos:

Voltar ao início

Permissões para diretórios de recebimento e repetição

As seguintes permissões são necessárias nos Diretório de recebimento e repetição:

  • Administrador: Controle Total

  • 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 do usuário do Serviço de Rede para gerenciar o local e as permissões do Diretório de recebimento e repetição. A conta Serviço de Rede exige essas permissões no Diretório de recebimento, para que arquivos .eml possam ser abertos, renomeados como .tmp e excluídos, ou renomeados como .bad se as mensagens forem classificadas como mensagens inválidas.

Você pode mover o local nesses diretórios usando os parâmetros PickupDirectoryPath e ReplayDirectoryPath no cmdlet Set-TransportServer. A alteração bem-sucedida do local do Diretório de recebimento depende dos direitos concedidos à conta Serviço de Rede no novo local do Diretório de recebimento e se os novos Diretório de recebimento já existem. Se o novo diretório ainda não existir e a conta Serviço de Rede tiver os direitos necessários para criar pastas e aplicar permissões no novo local, o novo Diretório de repetição 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 as localizações de diretório usando o parâmetro PickupDirectoryPathSet-TransportServerReplayDirectoryPath com o cmdlet Set-TransportServer, o ideal será verificar se o novo diretório existe e se o novo diretório tem as permissões corretas aplicadas a ele.

Voltar ao início

 © 2010 Microsoft Corporation. Todos os direitos reservados.