Minha empresa configurou recentemente um ambiente do Microsoft Exchange orientado ao Active Directory para consolidar e-mails enviados. Nós temos um conjunto de servidores de teste que agora devem usar nosso MSEXCHG como smarthost para o correio de saída.
Esses servidores estão localizados na DMZ, e é por isso que a solução com votos contra êxito em Autenticando no Exchange 2010 smarthost? não é uma alternativa, já que não podemos permitir que um servidor na DMZ apenas envie e-mails a qualquer momento através do nosso servidor Exchange.
Coisas que fizemos no MSEXCHG:
As coisas que fizemos em exim4 (8) :
update-exim4.conf (8) (c.f. exim4_files (5) ), configuramos o exim para usar exchange.contoso.com:587 como um smarthost. exim4_files (5) ), adicionei a seguinte linha: exchange.contoso.com:[email protected]:secret123 ) Depois de iniciar o exim com a configuração descrita acima, recebo os dois erros de TLS a seguir em mainlog :
TLS error on connection to ex.contoso.com [192.168.1.8] (recv): A TLS packet with unexpected length was received. TLS error on connection to ex.contoso.com [192.168.1.8] (send): The specified session has been invalidated for some reason. Nosso MSEXCHG se recusa a enviar o e-mail e a seguinte entrada de log (final) é mostrada:
** [email protected] R=smarthost T=remote_smtp_smarthost: SMTP error from remote mail server after MAIL FROM:<[email protected]> SIZE=1538: host ex.contoso.com [192.168.1.8]: 530 5.7.1 Client was not authenticated
Outras coisas que tentei:
Então, pergunta obrigatória: Como podemos obter o exim para usar nosso ambiente MSEXCHG como smarthost?
Nosso problema foi bastante específico para nossa configuração. Temos mais de um Exchange Server em execução em paralelo com um balanceador de carga atuando como AP. O LB foi configurado incorretamente, o que causou a negligência de oferecer qualquer barra de método de autenticação NTLM e GSSAPI mesmo após o bem-sucedido STARTTLS handshake.
Testes detalhados via swaks jetmore.org (podem recomendar esta ferramenta) revelaram isso .
Sua organização opera sua própria autoridade de certificação para servidores internos? Talvez você precise adicionar os certificados de autoridade de certificação para o servidor Exchange no armazenamento confiável de certificado para o Exim? Muitos produtos não reportam muito bem este erro (não sei se o Exim faz ou não).
O Wireshark (captura primeiro no servidor com tcpdump -p -s0 -w /tmp/foo.pcap e copia para uma estação de trabalho local com o Wireshark) deve poder mostrar o envio do certificado do servidor do Exchange, e se o cliente desligar depois disso, um certificado CA ausente é uma causa comum.
O problema é devido aos certificados TLS. Procedimento para resolver:
sudo apt-get instala o openssl
sudo / usr / share / doc / exim4-base / exemplos / exim-gencert
sudo nano /etc/exim4/exim4.conf.localmacros
main_tls_enable = '1'