Noções Básicas Sobre Conectores de Envio

Artigo
05/13/2016

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

Tópico modificado em: 2015-03-09

Conectores de envio são configurados em computadores que estejam executando o Microsoft Exchange Server 2010 e que tenham a função de servidor Transporte de Hub ou Transporte de Borda instalada. O Conector de Envio representa um gateway lógico através do qual mensagens de saída são enviadas. Este tópico oferece uma visão geral dos conectores de Envio e explica como a sua configuração afeta o processamento de mensagens individuais.

Visão geral dos conectores de envio

Os servidores de transporte do Exchange 2010 exigem que os Conectores de envio entreguem as mensagens no próximo salto do caminho para seus respectivos destinos. Um conector de envio controla as conexões de saída do servidor de envio para o servidor de recebimento ou o sistema de email de destino. Por padrão, nenhum conector de envio explícito é criado quando a função de servidor Transporte de Hub ou Transporte de Borda é instalada. No entanto, conectores de envio invisíveis e implícitos que são calculados automaticamente com base na topologia do site do Active Directory são usados para rotear mensagens internamente entre servidores de Transporte de Hub. O fluxo de mensagens ponto a ponto só é possível depois que o servidor de Transporte de Borda é inscrito no site do Active Directory usando o processo de Inscrição de Borda. Outros cenários, como um servidor de Transporte de Hub voltado para a Internet ou um servidor de Transporte de Borda não inscrito, exigem configuração manual de conectores para estabelecer o fluxo de mensagens ponto a ponto. Para obter mais informações, consulte Tarefas pós-implementação do Servidor de Transporte.

Os conectores de envio criados nos servidores de Transporte de Hub são armazenados no Active Directory e estão disponíveis a todos os servidores de Transporte de Hub da organização. Se um conector de envio for configurado para enviar mensagens a um domínio externo, qualquer servidor de Transporte de Hub da organização irá rotear uma mensagem para esse domínio, ela será entregue em um servidor de origem desse conector para retransmissão ao domínio de destino.

O conector de envio usado para rotear mensagens a um destinatário é selecionado durante a fase de resolução de roteamento da categorização de mensagens. Para obter mais informações, consulte Noções Básicas Sobre Roteamento de Mensagens (página em inglês).

Selecionando o tipo de uso para um Conector de Envio

Quando você usa o Console de Gerenciamento do Exchange (EMC) para criar um conector de envio, o assistente de Novo Conector de Envio SMTP solicita a escolha de um tipo de uso para o conector. O tipo de uso determina os conjuntos-padrão de permissão atribuídos no conector e concede essas permissões às entidades de segurança confiáveis. Entidades de segurança incluem usuários, computadores e grupos de segurança. Uma entidade de segurança é identificada por um SID (identificador de segurança).

Você também pode especificar um tipo de uso ao criar um conector de envio usando o cmdlet New-SendConnector no Shell de Gerenciamento do Exchange. No entanto, o parâmetro Usage não é necessário. Se você não especificar um tipo de uso quando executar o cmdlet New-SendConnector, o tipo de uso padrão será definido como Personalizado. A tabela a seguir descreve os tipos de uso do conector de envio e suas respectivas configurações-padrão.

Tipos de uso dos conectores de envio

Tipo	Permissões padrão	SID concedido às permissões padrão	Mecanismo padrão inteligente de autenticação de host
Personalizado	Nenhum	Nenhum	Nenhum
Interno	ms-Exch-Send-Headers-Organization ms-Exch-SMTP-Send-Exch50 ms-Exch-Send-Headers-Routing ms-Exch-Send-Headers-Forest	Servidores de Transporte de Hub Servidores de Transporte de Borda Servidores do Exchange (somente em servidores de Transporte de Hub) Servidores protegidos externamente Grupo de segurança universal Interop Herdado do Exchange Servidores bridgehead Exchange Server 2003 e Exchange 2000 Server	Autenticação de servidor do Exchange
Internet	Ms-Exch-Send-Headers-Routing	Conta de Usuário Anônimo	Nenhum
Parceiro	Ms-Exch-Send-Headers-Routing	Servidores de Parceiros	Não aplicável. Esse tipo de uso é selecionado quando você estabelece autenticação de protocolo TLS mútuo com um domínio remoto.

Dica

Se a entrega da resolução do DNS (Sistema de Nome de Domínio) for selecionada para um conector de envio, em vez de um host inteligente, não será configurado nenhuma autenticação de host inteligente.

As permissões do conector de envio e os mecanismos de autenticação de host inteligente serão descritos posteriormente neste tópico.

Cenários de uso de conectores de envio

Cada tipo de uso é adequado a um cenário de conexão específico. Selecione o tipo de uso que tenha as configurações padrão mais aplicáveis à configuração que você deseja. Para modificar as permissões, use os cmdlets Add-ADPermission e Remove-ADPermission. Para obter mais informações, consulte os seguintes tópicos:

A tabela a seguir lista os cenários comuns de conexão e o tipo de uso de cada cenário.

Cenários de uso do conector

Cenário de conector	Tipo de uso	Comentário
Servidor de Transporte de Borda que envia email para a Internet	Internet	Um conector de envio que é configurado para enviar email a todos os domínios criados automaticamente quando o servidor de Transporte de Borda é registrado na organização do Exchange.
Servidor de Transporte de Hub que envia email para a Internet	Internet	Essa não é uma configuração recomendada.
Um servidor de Transporte de Borda assinado que envia email para um servidor de Transporte de Hub	Interno	Esse conector é criado automaticamente pelo processo de Inscrição de Borda.
Servidor de Transporte de Borda que envia email para um servidor bridgehead do Exchange 2003	Interno	O servidor bridgehead o Exchange 2003 é configurado como um host inteligente para o conector de envio.
Servidor de Transporte de Borda que envia email para um servidor de Transporte de Hub	Personalizada	Quando o processo de Inscrição de Borda não é usado, um conector manual deve ser criado. Use o cmdlet Add-ADPermission para definir os direitos estendidos. Defina o mecanismo de autenticação como Autenticação básica ou Protegido externamente.
Conector de envio entre florestas para um servidor de Transporte de Hub de uma floresta que envia email a um servidor de Transporte de Hub do Exchange 2010 ou Exchange 2007 em uma segunda floresta	Personalizada	Para etapas de configuração detalhadas, consulte Configurar conectores entre florestas.
Conector de envio entre florestas para um servidor de Transporte de Hub de uma floresta que envia email a um servidor bridgehead do Exchange 2003 de uma segunda floresta	Personalizada	Para obter etapas de configuração detalhadas, consulte Configurar conectores entre florestas.
Servidor de Transporte de Hub que envia email para um host inteligente de terceiros	Personalizada	Use o cmdlet Add-ADPermission para definir os direitos estendidos. Roteie todas as mensagens para um host inteligente e defina o mecanismo de autenticação como Autenticação básica ou Protegido Externamente.
Servidor de Transporte de Borda que envia email para um host inteligente de terceiros	Personalizada	Use o cmdlet Add-ADPermission para definir os direitos estendidos. Roteie todas as mensagens para um host inteligente e defina o mecanismo de autenticação como Autenticação básica ou Protegido Externamente.
Servidor de Transporte de Borda que envia email para um domínio de retransmissão externo	Personalizada	O servidor de Transporte de Borda pode aceitar email de um domínio de retransmissão externo e depois retransmitir as mensagens para o sistema de email autorizado desse domínio. Roteie todas as mensagens para um host inteligente, defina o mecanismo de autenticação apropriado e use o cmdlet Add-ADPermission para definir os direitos estendidos.
Servidor de Transporte de Borda que envia email para um domínio no qual você estabeleceu autenticação TLS mútua	Parceiro	A autenticação TLS mútua funcionará corretamente apenas se as seguintes condições forem verdadeiras: O valor do parâmetro DomainSecureEnabled deve ser definido como `$true`. O valor do parâmetro DNSRoutingEnabled deve ser definido como `$true`. O valor do parâmetro IgnoreStartTLS deve ser definido como `$false`. Para obter mais informações, consulte Set-SendConnector.

Permissões de Conector de Envio

Atribua permissões de conector de envio a uma entidade de segurança. Quando uma entidade de segurança estabelece sessão com um conector de envio, as permissões do conector determinam os tipos de informações de cabeçalho que podem ser enviadas com a mensagem de email. Se uma mensagem de email incluir informações de cabeçalho não autorizadas pelas permissões do conector de envio, esses cabeçalhos serão removidos quando a mensagem for enviada. A tabela a seguir descreve as permissões de um conector de envio que podem ser atribuídas a entidades de segurança. Você não pode definir as permissões do conector de envio no Console de Gerenciamento do Exchange. Para modificar as permissões-padrão de um conector de envio, use o cmdlet Add-ADPermission no Shell.

Permissões do conector de envio

Permissão do conector de envio	Descrição
ms-Exch-Send-Exch50	Essa permissão autoriza a sessão a enviar uma mensagem que contém o comando EXCH50. Se essa permissão não for concedida e uma mensagem contendo o comando EXCH50 for enviada, o servidor enviará a mensagem, mas não incluirá o comando EXCH50.
Ms-Exch-Send-Headers-Routing	Essa permissão autoriza a sessão a enviar uma mensagem que tenha todos os cabeçalhos recebidos intactos. Se essa permissão não for concedida, o servidor removerá todos os cabeçalhos recebidos.
Ms-Exch-Send-Headers-Organization	Essa permissão autoriza a sessão a enviar uma mensagem que tenha todos os cabeçalhos da organização intactos. Todos os cabeçalhos da organização começam com X-MS-Exchange-Organization-. Se essa permissão não for concedida, o servidor de envio removerá todos os cabeçalhos da organização.
Ms-Exch-Send-Headers-Forest	Essa permissão autoriza a sessão a enviar uma mensagem que tenha todos os cabeçalhos da floresta intactos. Todos os cabeçalhos de floresta começam com X-MS-Exchange-Forest-. Se essa permissão não for concedida, o servidor de envio removerá todos os cabeçalhos de floresta.

Espaços de endereçamento e escopo do conector

O espaço de endereçamento de um conector de envio especifica os domínios de destinatário para os quais o conector de envio roteará emails. É possível especificar espaços de endereçamento SMTP ou não-SMTP nos conectores de envio configurados em servidores de Transporte de Hub. Somente espaços de endereçamento SMTP podem ser especificados em conectores de envio configurados em servidores de Transporte de Borda. Se você usar um tipo de espaço de endereçamento diferente de SMTP, use um host inteligente para rotear o email.

Dica

Embora seja possível configurar espaços de endereçamento que não sejam SMTP em um conector de envio de um servidor de Transporte de Hub, o conector de envio usa SMTP como o mecanismo de transporte para enviar mensagens a outros servidores de mensagens. Os conectores do Agente de Entrega e os externos nos servidores de Transporte de Hub são usados para enviar mensagens para servidores de mensagens locais não-SMTP, como servidores de gateway de fax de terceiros. Para mais informações, consulte Noções Básicas Sobre Agentes de Entrega e Noções Básicas Sobre Conectores Estrangeiros.

A tabela a seguir lista as entradas válidas para o espaço de endereçamento SMTP de um conector de envio.

Entradas válidas para o espaço de endereçamento SMTP de um Conector de envio

Entrada de espaço de endereçamento	O conector de envio roteia email para:
*	Todos os domínios que não têm uma entrada de espaço de endereçamento explícita na entrada de outro conector de envio ou que não são um subdomínio incluído de um espaço de endereçamento em outro conector de envio.
Contoso.com	Todos os destinatários com endereços de email no domínio Contoso.com.
*.Contoso.com	Todos os destinatários com endereços de email no domínio Contoso.com ou em qualquer subdomínio de Contoso.com. No Console de Gerenciamento do Exchange, selecione Incluir todos os subdomínios para definir essa configuração.
--	Esse espaço de endereçamento é usado somente nos conectores de envio configurados nos servidores de Transporte de Borda para enviar mensagens para os servidores de Transporte de Hub. Quando você usa esse espaço de endereçamento, todas as mensagens endereçadas ao seus domínios aceitos são roteadas através desse conector.

Durante a resolução de roteamento, é selecionado um conector de envio para o qual o email é roteado para entrega no espaço de endereçamento de destino. O conector de envio cujo espaço de endereçamento mais combinar com o endereço de email do destinatário será selecionado. Por exemplo, uma mensagem de email endereçada a Destinatário@marketing.contoso.com seria roteada pelo conector configurado para usar o espaço de endereçamento *.Contoso.com. Quando você configura um conector de envio para um determinado espaço de endereçamento, o email enviado a esse espaço de endereçamento é roteado sempre por esse conector. Além disso, as definições de configuração desse conector são sempre aplicadas ao email enviado a esse espaço de endereçamento.

Você pode usar o escopo de um conector de envio para controlar a visibilidade do conector de envio dentro da organização do Exchange. Por padrão, todos os conectores de envio que você cria podem ser usados por todos os servidores de Transporte de Hub da organização do Exchange. No entanto, você pode limitar o escopo de qualquer conector de envio, de modo que ele seja utilizável somente por outros servidores de Transporte de Hub existentes no mesmo site do Active Directory.

No Exchange 2010, a sintaxe completa para especificar um espaço de endereçamento é a seguinte:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>

Você pode usar os seguintes métodos para especificar o escopo do conector de envio:

No Console de Gerenciamento do Exchange, use a propriedade Conector de envio com escopo na página Espaço de Endereçamento do assistente de Novo Conector de Envio SMTP, ou na guia Espaço de Endereçamento das propriedades de um conector de envio existente.

Quando Conector de envio com escopo for selecionado, o conector só poderá ser usado pelos servidores de Transporte de Hub no mesmo site do Active Directory. Quando Conector de envio com escopo não for selecionado, o conector poderá ser usado por todos os servidores de Transporte de Hub da organização do Exchange.
No Shell, use o parâmetro IsScopedConnector nos cmdlets New-SendConnector ou Set-SendConnector.

Quando o valor desse parâmetro for $true, o conector poderá ser usado apenas pelos servidores de Transporte de Hub no mesmo site do Active Directory. Quando o valor desse parâmetro for $false, o conector poderá ser usado por todos os servidores Transporte de Hub da organização do Exchange.

Configurações de rede

Você pode definir os conectores de envio de modo que entreguem o email usando a resolução de endereço DNS ou roteando o email para um host inteligente.

Usando DNS para rotear email

Quando o conector de envio é definido para usar os recursos de registros MX de DNS para rotear email automaticamente, o cliente DNS do servidor de origem deve estar apto a resolver registros DNS públicos. Por padrão, o servidor DNS configurado no adaptador de rede interno do servidor de origem é usado na resolução de nome. Você pode configurar um servidor DNS específico para uso nas pesquisas internas e externas de DNS, usando o EMC para modificar as configurações de DNS nas propriedades do servidor do Exchange. O Shell também pode ser usado para configurar os parâmetros no cmdlet Set-TransportServer.

Se você configurar um servidor DNS específico no servidor de transporte para uso em consultas externas de DNS, selecione Usar as configurações de pesquisa externa de DNS no servidor de transporte na página Configurações de Rede do assistente de Novo Conector de Envio SMTP ou, no Shell, no cmdlet Set-TransportServer, defina o parâmetro UseExternalDNSServersEnabled como $true. O parâmetro DnsRoutingEnabled do conector de envio também deve ser definido como $true.

Para obter mais informações, consulte os seguintes tópicos:

Usando um host inteligente para rotear email

Se você selecionar o tipo de uso Interno para o conector de envio, especifique um host inteligente. Ao rotear email por um host inteligente, o host inteligente conduz a entrega ao próximo salto no destino de entrega. Você pode usar um endereço IP ou o FQDN (nome de domínio totalmente qualificado) do host inteligente para especificar a identidade do host inteligente. A identidade do host inteligente pode ser o FQDN de um servidor de host inteligente, um registro MX ou um registro A (endereço). Se você configurar um FQDN como a identidade do host inteligente, o servidor de origem do conector de envio deverá estar apto a usar a resolução de nomes DNS para localizar o servidor host inteligente.

O host inteligente de um conector de envio com o tipo de uso Internet pode ser um servidor hospedado por seu provedor de serviços de Internet. O host inteligente de um conector de envio com o tipo de uso personalizado ou interno pode ser outro servidor de email em sua organização ou um servidor de email em um domínio remoto.

Configurações de segurança de host inteligente

Ao rotear email por um host inteligente, especifique como o servidor de origem será autenticado no computador do host inteligente. Você não poderá exigir configurações de segurança em um conector de envio, a menos que um destino de host inteligente seja especificado. Por exemplo, um conector voltado para a Internet não pode ser definido para exigir TLS.

A tabela a seguir lista o mecanismo de autenticação de host inteligente que você pode configurar para um conector de envio.

Mecanismos de autenticação de host inteligente

Configuração de segurança	Descrição
Nenhum	É permitido acesso anônimo.
Autenticação básica	A autenticação básica exige que você forneça um nome de usuário e uma senha. Autenticação básica envia credenciais em texto não criptografado. Todos os hosts inteligentes nos quais esse conector de envio está sendo autenticado devem aceitar o mesmo nome de usuário e senha.
Autenticação básica por TLS	Selecione TLS para criptografar a transmissão das credenciais. O servidor de recebimento deve ter um certificado de servidor. O FQDN exato do host inteligente, do registro MX ou do registro A que está definido no conector de envio como a identidade do host inteligente também deve existir no certificado do servidor. O conector de envio irá tentar estabelecer a sessão TLS enviando o verbo STARTTLS para o servidor de destino e irá executar a autenticação básica somente após a sessão TLS ter sido estabelecida. Um certificado de cliente também é necessário para suporte à autenticação TLS mútua.
Autenticação do servidor Exchange	Autenticação do servidor Exchange (interface de programação do aplicativo Generic Security Services (GSSAPI) e GSSAPI mútuo)
Protegido Externamente (por exemplo, com IPsec)	A conexão de rede é protegida com o uso de um método externo ao servidor Exchange.

Servidor de Origem

Selecione pelo menos um servidor de origem para um conector de envio. O servidor de origem é o servidor de transporte para o qual as mensagens são roteadas para entrega através do conector de envio selecionado. Você pode definir mais de um servidor de origem em um conector de envio configurado para a organização do Exchange. Quando você especifica mais de um servidor de origem, oferece equilíbrio de carga e redundância, se um servidor falhar. Os servidores de origem associados aos conectores de envio configurados para a organização do Exchange podem ser servidores de Transporte de Hub ou servidores de Transporte de Borda assinados.

FQDN

A guia Geral das propriedades do conector de envio no Console de Gerenciamento do Exchange inclui uma opção para Especificar o FQDN que esse conector fornecerá em resposta a HELO ou EHLO. No Shell, essa propriedade é definida usando o parâmetro Fqdn com o cmdlet Set-SendConnector. Após uma sessão SMTP ter sido estabelecida, uma conversa do protocolo SMTP é iniciada entre um servidor de envio de email e um servidor de recebimento de email. O servidor de envio de email ou o cliente enviam o comando SMTP EHLO ou HELO e o seu FQDN para o servidor de recebimento. Em resposta, o servidor de destino envia um código de sucesso e fornece seu próprio FQDN. No Exchange 2010, é possível personalizar o FQDN fornecido pelo servidor de envio se você configurar essa propriedade em um conector de envio. O valor do parâmetro Fqdn é exibido para servidores de mensagens conectados sempre que um nome de servidor de origem é exigido, como nos exemplos a seguir:

No campo de cabeçalho Recebidos: mais recente da mensagem que é adicionado pelo servidor de mensagens do próximo salto depois que a mensagem sai do servidor de Transporte de Hub ou de Transporte de Borda
Durante a autenticação TLS

Se o conector de envio estiver configurado em um servidor de Transporte de Hub que também tenha a função de servidor de Caixa de Correio instalada, nenhum valor especificado para o parâmetro Fqdn será usado. Em vez disso, será usado sempre o FQDN do servidor que é exibido com o cmdlet Get-ExchangeServer.

Para servidores que tenham tanto a função de servidor Transporte de Hub quanto a função Caixa de Correio instaladas, o único jeito de remover o nome do servidor dos cabeçalhos Recebido: da mensagem de saída é usar o cmdlet Remove-ADPermission para remover a permissão Ms-Exch-Send-Headers-Routing das entidades de segurança configuradas no conector. Essa ação removerá todos os cabeçalhos Recebido: da mensagem conforme a mensagem deixa o servidor de Transporte de Hub. Recomendamos que você não remova os cabeçalhos Recebido: das mensagens internas, porque eles são usados para cálculos de contagem máxima de saltos. Para obter mais informações sobre os cmdlets Remove-ADPermission e Get-ExchangeServer, consulte os seguintes tópicos:

Novos recursos no Exchange 2010 Service Pack 1

No Service Pack 1 (SP1) do Exchange Server 2010, os conectores de Envio ganharam novas funcionalidades. Esta seção fornece uma visão geral de cada um desses novos recursos.

Suporte para downgrade de falhas de conexão

Você pode ter conectores de Envio dedicados responsáveis por transmitir mensagens em canais de comunicação bem definidos que se espera que estejam sempre disponíveis, como o conector de Envio dedicado a enviar mensagens para o Microsoft Office 365 ou para um de seus parceiros por um canal privado. Nessas conexões, muitos erros típicos que são possíveis em destinos comuns na Internet não são esperados. Nessa situação, você pode tratar quaisquer erros de comunicação como transitórios, em vez de emitir NDRs (notificações de falha na entrega). Com o Exchange 2010 SP1, você pode configurar um conector de Envio para que faça downgrade de erros de resolução de nome e autenticação, o que normalmente resultaria em uma NDR para erros transitórios. Nesses casos, o Exchange tentará fazer a entrega novamente em vez de emitir uma NDR.

O downgrade de falhas de conexão em conexões confiáveis dá a você a oportunidade de solucionar problemas sem afetar seus usuários.

Importante

Esse recurso só deve ser habilitado para conectores de Envio que transmitam mensagens por redes bem definidas e confiáveis. O recurso não deve ser habilitado para seus conectores de Envio para a Internet.

Para configurar esse recurso, use o parâmetro ErrorPolicies no cmdlet Set-SendConnector. Você pode optar por fazer o downgrade de falhas de autenticação, de falhas de DNS ou de ambas para qualquer conector de Envio. Para obter mais informações sobre a configuração dessa propriedade, consulte Set-SendConnector.

Suporte à validação de domínio TLS

O Exchange 2010 SP1 fornece suporte à validação de domínio para conexões TLS de saída. A validação de domínio é um recurso de segurança adicional que reduz o risco de usuários mal-intencionados se fazerem passar por um servidor de recebimento. Ao habilitar a validação de domínio em um conector de Envio, o servidor de Transporte realiza as seguintes verificações de segurança na conexão de saída:

O canal de comunicação é criptografado usando TLS.
O certificado do servidor de recebimento é validado e são realizadas verificações na lista de revogação.
O servidor de Transporte verifica se o FQDN no certificado do servidor de recebimento corresponde ao domínio configurado nas propriedades do conector de Envio.

Ao habilitar a validação de domínio em um conector de Envio, você também precisa especificar o nome de domínio contra o qual será feita a validação. Ambas as propriedades podem ser configuradas com os parâmetros TlsAuthLevel e TlsDomain do cmdlet Set-SendConnector. Para obter mais informações sobre a configuração desse recurso, Set-SendConnector.

Partilhar via