Mensagens do Sendmail rejeitadas pela Microsoft ao usar o TLS

Question

Vou começar com uma afirmação de que não sou especialista em sendmail. Eu raramente uso, mas nessa situação eu tenho para o meu cliente.

Histórico:

Um cliente meu tem um servidor de correio com Debian 7.7, Sendmail 8.14.4 e OpenSSL 1.0.1e. Ele gera e-mails (como redefinição de conta) e os envia para os clientes. Eu chamarei de "Servidor A".

As mensagens enviadas do Servidor A para qualquer servidor de e-mail no domínio * .outlook.com (que estranhamente não incluem mensagens @ outlook.com, aquelas tratadas pelo hotmail) estavam sendo adiadas devido a um handshake TLS com falha. Este é apenas um problema para servidores de propriedade da Microsoft; todo o resto está funcionando. O erro no log parecia algo como:

sendmail[22213]: ruleset=tls_server, arg1=SOFTWARE, relay=mail.protection.outlook.com, reject=403 4.7.0 TLS handshake

sendmail[22213]: s2L9EakQ022098: to=<[email protected]>, delay=00:00:55, xdelay=00:00:31, mailer=esmtp, pri=181653, relay=mail.protection.outlook.com. [145.123.225.25], dsn=4.0.0, stat=Deferred

Observação: esses registros são criados porque meu cliente não quer que as coisas sejam copiadas e coladas, pois elas acidentalmente vazam dados confidenciais. A informação está lá, eu apenas digitei manualmente para ignorar erros de digitação, etc.

Isso foi tudo o que consegui obter dos logs, mesmo com os logs 15 (além disso, o sistema começou a ficar vinculado ao disco).

Problema:

Um tcpdump do handshake mostrou que o Servidor A estava se conectando ao outlook.com, o EHLO foi com sucesso, o Servidor A iniciou o STARTTLS, o outlook.com então respondeu com sua cadeia de certificados. Tudo isso foi normalmente.

Depois que o Servidor A recebeu a cadeia de certificados da Microsoft, o Servidor A enviou seu próprio certificado de cliente. O Outlook.com, em seguida, descartou a conexão.

Nossos certificados de cliente são certificados autoassinados que usamos para verificação intraorganizacional e não devem sair para o outlook.com.

De meu conhecimento limitado, meu melhor palpite é que outlook.com está solicitando o certificado do cliente para verificação (ou pelo menos o sendmail acha que está solicitando o certificado), que o sendmail no Servidor A é obrigatório. Outlook.com, em seguida, está soltando a conexão, porque o certificado é inválido ou não é o que estava esperando.

Duas perguntas:

1. Por que o sendmail envia o certificado do cliente para outlook.com como parte do STARTTLS?

2. Existe uma maneira de impedir que o sendmail envie certificados de clientes para servidores fora de nosso domínio, mesmo que o servidor os solicite? Das experiências que fiz, o outlook.com aceitará a mensagem se eu simplesmente ignorar a solicitação do certificado e enviar a mensagem.

Antes de qualquer um sugerir, eu já criei um mapa de acesso que impede o TLS de conexões com alguns endereços IP associados à Microsoft. Esta não é uma boa solução permanente, porque eu preferiria usar o TLS, e a lista de endereços IP deve ser mantida manualmente, o que é um incômodo.

    

Answer 1

Bem-vindo ao Serverfault! :-)

Você configurou explicitamente o SendMail para usar o TLS? Caso contrário, o SendMail ainda tentará executar operações TLS oportunistas com um certificado de cliente de zero bytes. Eu suponho que isso é o que você está vendo? Para mais informações sobre isso (estranheza?) Confira a excelente resposta do @ MadHatter aqui: link

Então, com isso dito, responderei às suas perguntas na ordem em que foram feitas:

1. Why is sendmail sending the client certificate to outlook.com as part of STARTTLS?

Quando dois MTAs estão tentando estabelecer um túnel seguro para STARTTLS, é normal que eles negociem informações de segurança e troquem certificados públicos para poder criptografar informações com segurança entre si. Se o sendmail não fornecesse um certificado de cliente para outlook.com, os servidores de correio outlook.com não teriam uma maneira de criptografar respostas / confirmações de volta ao sendmail.

2. Is there a way that I can prevent sendmail from sending client certificates to servers outside our domain, even if the server requests it? From the experiments I've done, outlook.com will accept the message if I simply ignore the certificate request and send the message.

Você tem algumas opções:

Opção nº 1: implemente uma regra de exceção por servidor / por domínio. Isso pode ser feito adicionando Try_TLS:<broken.server> NO à sua tabela de acesso. Parece que você já está fazendo isso, mas é importante observar que a parte "broken.server" pode ser um IP, um registro MX (microsoft-com.mail.protection.outlook.com) ou partial registro MX (outlook.com).

Opção nº 2: implemente uma regra de ignorar todos os domínios. Isso pode ser feito adicionando Try_TLS: NO à sua tabela de acesso (não é necessário especificar IPs).

Tecnicamente , você também pode hackear o arquivo sendmail.mc para evitar que o sendmail verifique a capacidade TLS. Eu não recomendaria isso, já que requer mudanças delicadas.

    

Answer 2

_{Transferir solução de pergunta para responder à seção.}

Para quem tem este problema e não consegue descobrir, encontrei a causa raiz e a solução.

Eu não consegui impedir que o certificado do cliente fosse enviado para a Microsoft, então minha única opção era descobrir por que a Microsoft estava rejeitando o servidor. Ao criar o certificado, estávamos usando um nome de servidor diferente do apresentado no ehlo. por exemplo. mx1.example.com no helo e mx.example.com no certificado. A incompatibilidade estava fazendo com que a Microsoft abandonasse as conexões sem explicação.