Quão amplamente suportado é o TLS forçado nas conexões SMTP de entrada?

10

Eu executo um MTA que consiste nas verificações padrão Postfix, SpamAssassin, ClamAV, SPF / DKIM, etc.

Estou ciente de que alguns serviços de email estão começando a tentar conexões TLS antes de texto sem formatação ao tentar entregar email para o meu servidor.

Percebo que nem todos os serviços suportam TLS, mas estou me perguntando quão bem adotado é para que eu possa satisfazer o lado de segurança do TOC do meu cérebro (sim, eu sei que o SSL não é tão seguro quanto pensávamos que era) ...)

A documentação do Postfix para smtpd_tls_security_levelafirma que o RFC 2487 decreta que todos os servidores de correio publicamente referenciados (por exemplo, MX) não forçam o TLS:

De acordo com a RFC 2487, isso NÃO DEVE ser aplicado no caso de um servidor SMTP publicamente referenciado. Esta opção está, portanto, desativada por padrão.

Portanto: qual a aplicabilidade / relevância da documentação (ou a RFC de 15 anos), e posso forçar com segurança o TLS em todas as conexões SMTP de entrada sem bloquear metade dos ISPs do mundo?

security email postfix tls Craig Watson
fonte
1
Os padrões são criados por comitês cujos membros provavelmente nunca trabalharam como administrador de sistemas nem um único ano de vida e são bastante visíveis em praticamente todas as especificações padrão da Internet. No caso de RFCs, a situação é um pouco melhor, mas os RFCs não são padrões. São rascunhos (" r equest f or c omments"). E: você recebe seu salário não de um jornal, mas de uma empresa.
peterh - Reintegrar Monica
7
Essa RFC foi obsoleta pela RFC 3207 . E seu autor existe há muito mais tempo do que um comentarista parece pensar.
Michael Hampton
6
Para email de saída , aqui estão algumas estatísticas do Facebook: O estado atual da implantação do SMTP STARTTLS
masegaloeh
Não tenho certeza do motivo do voto negativo único. Obrigado Michel e Peter por seus pontos de vista, muito apreciados.
Craig Watson

Respostas:

7

Essa é uma pergunta muito complicada, uma vez que os provedores de correio do mundo não fornecem prontamente estatísticas em seus servidores de correio.

Auto diagnóstico

Para determinar a resposta à sua pergunta com base em seus próprios pares de servidor / domínio, você pode ativar o log SSL:

postconf -e \
    smtpd_tls_loglevel = "1" \
    smtpd_tls_security_level = "may"

postconf
postfix reload

Isso pressupõe que você salve suas mensagens de syslog de email por um tempo. Caso contrário, talvez configure uma estratégia de arquivamento de syslog e escreva um script de shell para resumir o uso do TLS no seu servidor. Talvez já exista um script para fazer isso.

Quando estiver satisfeito com o fato de todos os seus colegas suportarem TLS e com a força da cifra e do protocolo que deseja aplicar, você poderá tomar uma decisão informada. Todo ambiente é diferente. Não existe uma resposta que atenda às suas necessidades.

Minha própria experiência pessoal

Pelo que vale, meu servidor de correio pessoal impõe o TLS. Isso tem um efeito colateral engraçado de negar a maioria dos bots de spam, pois a maioria deles não suporta TLS. (Até essa mudança, eu estava contando com a metodologia regexp S25R)

Atualizar

Faz um ano que eu respondi a isso e os únicos problemas que tive ao receber e-mails com o TLS foram os servidores Web front-end da Blizzard (controle dos pais) e o sistema de gerenciamento da Linode. Todos os outros com quem interajo parecem oferecer suporte a TLS com cifras fortes muito bem.

Ambiente Corporativo

Em um ambiente corporativo, recomendo fortemente que você habilite o log TLS e deixe isso em execução por um longo tempo antes de aplicar o TLS. Você sempre pode aplicar o TLS para nomes de domínio específicos no arquivo tls_policy.

postconf -d smtp_tls_policy_maps

O site do postfix possui uma excelente documentação sobre o uso dos mapas de políticas tls. Você pode pelo menos garantir que domínios específicos que fornecem informações confidenciais sejam criptografados, mesmo que um ISP tente remover o suporte ao TLS na conexão inicial do servidor.

Aaron
fonte