Exchange 2003 - como encaminhar TODOS os emails (incluindo internos) através de um gateway SMTP externo? (Ou a migração do servidor de domínio / email para as massas.)

Question

Versão resumida: Existe uma maneira de o Exchange rotear todos os emails, incluindo os usuários internos do AD que normalmente seriam roteados diretamente, através de um gateway externo? (SMTP, provavelmente um "Host Inteligente" na nomenclatura de troca).

Versão mais longa:     Eu não sou um especialista em email / admin / orevencompetent. Herdado um servidor Exchange 2003, migrando para o provedor SaaS baseado na web. Para aumentar a diversão, também somos (forçados por prazos) a transição de domínios. O que nós (meu chefe) quer é que qualquer e-mail enviado para o novo domínio tenha uma cópia enviada para ambos os domínios. Obter e-mails enviados para o novo domínio / provedor para serem copiados / encaminhados para nosso antigo domínio / troca é fácil. Mas queremos que os e-mails enviados do domínio antigo para o domínio antigo também sejam enviados para o novo domínio.

No entanto: Se rotearmos todos os emails de saída de troca através do novo gateway do provedor, com o novo domínio encaminhando para o antigo, obteríamos um loop de email. A "solução" desejada é para um usuário de troca que envia para outro usuário de troca ainda ser enviado pelo gateway externo, que por sua vez seria enviado para o novo domínio e copiado / encaminhado de volta para o domínio antigo. É possível?

Um pequeno pedido estranho, tenho certeza. E espero que o que estamos tentando fazer seja o DoingItWrong (tm). Alguma idéia melhor?

    

Answer 1

Se você configurá-lo, o Exchange não encaminhará uma mensagem para fora da organização se o endereço de destino pertencer a alguém no Active Directory. Sempre que o Exchange precisar rotear uma mensagem, a primeira etapa será sempre para procurar o endereço de destino no AD, e somente depois disso ele escolherá um caminho de roteamento externo adequado, baseado nos conectores que você define.

Com o Exchange 2007, você pode ter domínios SMTP "compartilhados", ou seja, domínios para os quais alguns endereços podem ser gerenciados pelo Exchange e outros por outro sistema (em um cenário de coexistência); Eu não sei se / como isso é possível com 2003, mas mesmo se fosse, a regra de ouro acima declarada ainda se aplica: primeiro a primeira coisa, o Exchange tentará entregar a mensagem internamente, e somente se não puder, enviará a mensagem de saída.

Pense nisso: se houvesse uma maneira de fazer o que você pergunta, o que o Exchange faria ao receber uma mensagem para um determinado usuário (mesmo se já estivesse sendo encaminhado pelo seu provedor)? Ele seria encaminhado de volta para o seu provedor. Não há como encaminhar mensagens com base em quem as envia, apenas no seu destino ; e o destino seria o mesmo quando a mensagem vem do próprio Exchange, ou quando vem de fora: se o seu desejo se tornasse realidade, você estaria preso em um loop de e-mail.

    

Answer 2

Eu sugeriria:

1. Aponte o registro mx para domain.com e novo domain.com para seu provedor de hospedagem e configure o pop para cada conta.

2. Use o popbeamer para baixar o e-mail de cada conta de volta ao sistema de troca local.

3. Altere o endereço de e-mail de todos no Exchange e crie contatos para eles (que enviam e-mail para ambos os endereços). Oculte as pessoas originais, deixando apenas os contatos exibidos no Catálogo do Active Directory fornecido para o Outlook.

ou seja, [email protected] torna-se [email protected] e alias é a configuração que envia [email protected] para [email protected] e também [email protected]

Existe uma razão pela qual você está se esforçando para manter dois sistemas de e-mail ao mesmo tempo?

    

Answer 3

Se você tiver clientes MAPI como o Outlook, não há uma ótima maneira de fazê-lo (se você tiver apenas OWA / SMTP, poderá tê-lo em um servidor separado e ter sua configuração local (não o nível inteligente da organização). as ferramentas do Exchange) enviar SMTP através de um smarthost.

Espero que não seja tarde demais. Invertendo um pouco as coisas, você poderia ter todas as mensagens para a nova rota de domínio através do Exchange primeiro, e ter um domínio alternativo funcionando também nesse novo sistema (newsystem.newdomain.com)? Por exemplo, se você tiver um novo endereço de e-mail, chegue ao Exchange. Em seguida, você deseja criar um script para um contato para [email protected], adicionar esse objeto dn ao atributo altRecipient para [email protected], definir deliverAndRedirect e adicionar smtp: [email protected] a proxyAddresses. Quando chegar a hora de cortar completamente, altere o roteamento newdomain.com para ir direto e, em seguida, desligue o lado do Exchange. Não é o ideal, mas o Exchange 2003 nem sequer converteu para SMTP em mensagens dentro do servidor, portanto, não sendo capaz de enviar essas conexões para outro lugar.

    

Answer 4

OK, eu posso estar faltando alguma coisa, mas aqui está o que eu penso. Isso é semelhante ao que o SirStan sugeriu, mas minha abordagem elimina o servidor Exchange existente da equação:

O e-mail de ambos os domínios deve ir para o novo provedor e deixá-lo lá. Aponte os registros MX para os domínios antigo e novo para o novo servidor e reconfigure o Outlook para cada usuário para POP para o novo servidor para receber o email enviado para qualquer domínio.

Se necessário, os usuários podem configurar regras no Outlook para mover mensagens enviadas para um domínio para pastas diferentes, para mantê-las separadas. Além disso, se os usuários precisarem ser capazes de enviar como domínio, você poderá configurar 2 contas POP em cada perfil do Outlook para POP na mesma caixa de correio no novo provedor. Você pode configurar o Outlook para deixar uma cópia das mensagens no servidor. Cada usuário receberá uma cópia de cada e-mail em ambas as contas POP, o que poderá resultar em uma grande quantidade, mas lhes dará a capacidade de enviá-las como johndoe@old_domain.com e johndoe@new_domain.com.

Você perderá a capacidade de usar sua GAL interna e perderá a capacidade de visualizar caixas de correio de outros usuários e Pastas Públicas, mas provavelmente perderá essas com o novo provedor de qualquer maneira.

Existem algumas outras maneiras em que posso pensar para alcançar seu objetivo, mas essa parece ser a abordagem mais direta para mim.