Uma falha SMTP TLS pode ocorrer depois que a conexão de rede e os comandos SMTP iniciais já tiverem funcionado. O remetente pode não conseguir negociar uma versão do protocolo, rejeitar um certificado ou receber uma interrupção durante o handshake. Trate-as como observações da camada de transporte, e não como evidência imediata de que o remetente SPF ou DKIM registro está errado.
Identifique o modo de transporte
Em SMTP com STARTTLS, o cliente primeiro estabelece SMTP , recebe o anúncio de capacidade, solicita STARTTLS e então inicia a negociação TLS após a resposta de prontidão do servidor. TLS implícito inicia TLS imediatamente na conexão e é comumente usado para um serviço de envio compatível. A mistura dessas expectativas pode causar falha na conexão antes que ocorra uma troca de mensagens útil. RFC 3207 seções 4 e 5.
Registre o destino, a porta, o modo, o software de envio, a saudação SMTP remota e os recursos anunciados. Preservar se a falha ocorreu antes da oferta STARTTLS , após o comando STARTTLS , durante o processamento do certificado ou após o handshake. Evite copiar chaves privadas, senhas ou segredos de sessão em um pacote de diagnóstico. Os metadados do certificado e os erros de protocolo redigidos são geralmente mais úteis do que uma vaga “falha na conexão segura”.
Avalie os certificados de acordo com a política real
Um certificado expirado, um protocolo não suportado, uma cadeia incompleta ou uma incompatibilidade de identidade podem ter importância diferente sob diferentes políticas de envio. TLS SMTP oportunista comum não é o mesmo modelo de garantia que uma conexão governada por MTA-STS ou autenticado DANE. Nomeie a política que está sendo aplicada antes de interpretar por que o remetente adiou a entrega. Não presuma que toda implementação SMTP valida todos os certificados de forma idêntica.
RFC 8461 especifica descoberta, validação e comportamento de aplicação de políticas MTA-STS . RFC 7672 define segurança de transporte SMTP DANE usando autenticação DNSSEC TLSA Informação. Esses mecanismos têm seus próprios requisitos e tratamento de falhas. Sua presença deve ser verificada a partir da configuração real do remetente e de evidências de descoberta relevantes, e não inferida simplesmente porque um erro TLS aparece em um log.
Resolva uma hipotética falha de identidade
Suponha que um cliente de envio autorizado esteja configurado para TLS implícito em submit.example , mas seu erro de certificado mostre uma identidade esperada de old-submit.example . Primeiro confirme o ponto final documentado atual do serviço e se o cliente o está a alcançar. Não altere o nome esperado apenas para fazer com que qualquer certificado pareça aprovado.
Se o proprietário do serviço confirmar submit.example está correto e o certificado e a cadeia satisfazem os requisitos aplicáveis para esse endpoint, uma correção de configuração do cliente aprovada poderá resolver a incompatibilidade. Se o ponto final estiver correto, mas o certificado estiver errado, repare o certificado de serviço. Mantenha a validação habilitada em ambos os caminhos e verifique novamente o mesmo serviço após a correção.
Esta é uma árvore de decisão hipotética, não um aperto de mão executado, emissão de certificado ou versão TLS reivindicada. Para entrega MX , use as regras de identidade MTA-STS ou DANE reais em vez de importar uma suposição de cliente de envio. Um certificado de página inicial HTTPS não estabelece o certificado ou a política do endpoint SMTP .
Corrija a causa sem apagar a proteção
Atribua renovação de certificado e implantação de cadeia ao proprietário do serviço, compatibilidade de protocolo ao proprietário da plataforma de correio e interceptação ou interrupções de caminho à equipe de rede. Verifique a identidade MX esperada e a política aplicável antes de substituir um certificado. Faça uma correção aprovada de cada vez e preserve um plano de reversão.
Não ignore um aviso de certificado, desative a aplicação ou permita texto simples apenas para passar no teste. Se um remetente pode recorrer depende do protocolo e da política governamental; uma política rigorosa pode adiar intencionalmente em vez de produzir resultados inseguros. Uma nova tentativa insegura bem-sucedida não demonstraria que o problema TLS foi corrigido.
Verifique a sessão SMTP reiniciada
RFC 3207 exige o descarte do conhecimento SMTP pré-TLS após STARTTLS bem-sucedido; o cliente deve enviar EHLO primeiro para descobrir os recursos da sessão protegida, que podem ser diferentes da lista anterior. Confirme que o real MTA completa esta transição e então transfere a mensagem autorizada. Registre qualquer atraso contínuo na fila e o resultado final separadamente do sucesso do handshake. TLS protege o salto de transporte; por si só, não estabelece a legitimidade visível do autor, a confidencialidade do conteúdo de ponta a ponta ou a colocação na caixa de entrada.
Preserve os requisitos de segurança ao reparar TLS
- Capture endpoint, porta, STARTTLS ou modo implícito e estágio exato com falha.
- Identifique a política ativa e a identidade esperada antes de alterar um certificado.
- Erros separados de nome, validade, cadeia de confiança e protocolo; excluir segredos dos logs.
- Aplique um reparo aprovado para uma causa específica sem desabilitar a validação.
- Confirme TLS em conformidade com a política, a redefinição do estado pós-STARTTLS e o resultado da mensagem de forma independente.