Bem ... não e sim.
O problema é que, quando a consulta do registro MX do DNS é concluída, o servidor DNS não sabe quem é o usuário (essa informação não é enviada ao servidor DNS), portanto, o servidor DNS não pode enviar registros MX são especiais para alguns usuários. Seria estranho (a frase técnica é "uma violação de camadas") para o DNS saber muito sobre seus usuários. Além disso, e se o email tivesse 2 pessoas na linha To: , uma para um dos usuários originais e outra para os usuários do Exchange? Fica confuso.
Vamos chamar os usuários que têm seus e-mails entregues no servidor Postfix "Grupo P" e os usuários que desejam que seus e-mails sejam entregues no Exchange "Grupo E".
A solução é o servidor Postfix entregar emails do Grupo P localmente e encaminhar os emails do Grupo E para o servidor Exchange. Da mesma forma, os servidores do Exchange precisam saber para entregar os emails do Grupo E localmente e os emails do Grupo P precisam ser encaminhados.
A chave é garantir que esses dois servidores tenham as mesmas informações exatas. Caso contrário, ambos os servidores entregarão as mensagens de uma pessoa localmente, ou (ainda pior) nem pensarão que são responsáveis pelo e-mail e farão um pingue-pongue entre os servidores.
Solução se o Grupo E for pequeno:
Se o grupo E for curto (isto é, com algumas exceções), você pode fazer isso:
- No Postfix, configure aliases para cada usuário para encaminhar seus e-mails para sua conta do Exchange.
- No Exchange, configure o servidor para encaminhar emails para usuários desconhecidos para o servidor Postfix. (Infelizmente eu não sei as configurações para isso, como eu não sei Exchange).
Solução para sites maiores:
Para configurações maiores, recomendo que os dois servidores (chamem-nos serverE.example.com e serverP.example.com) estejam configurados para entregar emails locais para [email protected] e [email protected] respectivamente, mas não entrega o email localmente para [email protected]. Cada máquina acessa um banco de dados LDAP / ActiceDirectory que indica que (por exemplo) [email protected] tem seu e-mail entregue a [email protected] e [email protected] envia seu e-mail para [email protected] . Dessa forma, as coisas permanecem sincronizadas e você só tem um lugar para atualizar.
Pouco fato conhecido: Com o postfix, se o arquivo aliases contiver:
tom: [email protected]
geri: [email protected]
E o mydestination de mail.cf contém serverP.example.com , mas não serverE.example.com , então o e-mail para tom será entregue localmente e o e-mail para geri será retransmitido para o serverE. Não vai criar um loop!
Eu levanto esse problema porque antes de saber disso, escrevi um grande script em perl que gerava aliases arquivos para cada servidor de email para que (por exemplo) tom não aparecesse no arquivo aliases para serverP , apenas todos os outros. Quando soube disso, eliminei o roteiro. O mesmo arquivo aliases pode estar em todas as máquinas. (Claro que, como o Exchange não usa aliases arquivos, alguma outra coisa deve ser feita nesses servidores.)
Se myorigin = example.com , em seguida, o email de saída tiver "[email protected]" na linha From: , e ninguém será mais sábio se houver dois servidores de e-mail. (Eu não sei o equivalente da Exchange, mas tenho certeza que existe.)
Aviso de teste
Ao testar essa configuração, não basta testar se o email recebido vai para o lugar certo. Certifique-se também de que o email enviado de cada cliente vá para o lugar certo. Por exemplo, um usuário do Exchange envia uma mensagem To: tom, geri e garante que ambos sejam entregues. Faça o usuário Debian fazer o mesmo. Já vi situações em que (por exemplo) os aliases e / ou encaminhamento não estavam configurados nas duas máquinas e os e-mails foram entregues localmente para o usuário tom em ambos os servidores. tom teve que ler o email em ambos os lugares até que isso fosse corrigido. Opa!