Ainda é "errado" exigir STARTTLS nas mensagens SMTP recebidas

15

De acordo com a Seção 5 da especificação STARTTLS :

Um servidor SMTP publicamente referenciado NÃO DEVE exigir o uso da
extensão STARTTLS para entregar correio localmente. Essa regra
impede que a extensão STARTTLS danifique a interoperabilidade da infraestrutura SMTP da Internet. Um servidor SMTP publicamente referenciado é um servidor SMTP executado na porta 25 de um host da Internet listado no registro MX (ou Um registro se um registro MX não estiver presente) para o
nome de domínio no lado direito de um endereço de correio na Internet .

No entanto, essa especificação foi escrita em 1999 e, considerando que é 2014, eu esperaria que a maioria dos clientes, servidores e retransmissões SMTP tivesse algum tipo de implementação do STARTTLS.

Quanto e-mail posso esperar perder se precisar de STARTTLS para mensagens recebidas?

email  smtp  starttls 
— jackweirdy
fonte
1
Boa pergunta. Ter TLS forçado não vai impedir SPAM embora.
— Matt
1
Eu não estou esperando que ele, eu só quero a criptografia (que eu parecem estar recebendo a partir de 90% das mensagens recebidas sem tê-lo obrigatório) :)
— jackweirdy
2
@ Matt Verifiquei recentemente os emails recebidos em um servidor de email específico e encontrei isso. Dos e-mails recebidos com TLS, havia 4% de spam; dos e-mails recebidos sem TLS, havia 100% de spam. Eu não bloquearia completamente os e-mails sem o TLS com base nisso, mas certamente é um sinal forte, que pode ser utilizado na filtragem de spam.
— kasperd
@kasperd - você pode ativar o TLS ou usá-lo como um meio de reduzir o spam, mas não vai durar. Tudo o que realmente significa é que o cliente smtp que eles estão usando para enviar spam ao servidor não está usando TLS, ou talvez tente não usar TLS por padrão, mas pode tentar uma sessão habilitada para TLS, se necessário. Na melhor das hipóteses, você verá uma redução temporária no SPAM, mas espero que ele volte aos níveis normais ao longo do tempo.
— Matt
@ Matt Isso se aplica à maioria das abordagens atualmente adotadas contra spam. Outro problema com a maioria das abordagens é que elas bloqueiam muitos emails legítimos. As pessoas raramente consideram quantos emails legítimos é aceitável bloquear.
— precisa saber é o seguinte

Respostas:

19

Sim, ainda é uma má ideia.

Três razões:

  1. Enquanto a RFC que você citou ( RFC 2487 ) é de fato obsoleta pela norma atual RFC 3207 , a norma atual mantém a palavra NÃO PERMITIDA que você citou na sua pergunta.

  2. Os clientes SMTP não precisam implementar o STARTTLS. É totalmente aceitável não fazer isso. Embora o STARTTLS esteja se tornando mais comum, ele não é absolutamente universal.

  3. Como resultado dos motivos 1 e 2, se você precisar do STARTTLS em todas as conexões recebidas, perderá o correio.

Contudo:

Seu servidor - suas regras. Se você deseja rejeitar arbitrariamente qualquer correspondência por qualquer motivo, ou mesmo por nenhum motivo - esse é seu direito e privilégio. (no entanto, isso não significa necessariamente que é uma ótima ideia)

Notas laterais:

Você não evita o spam exigindo STARTTLS, mesmo que exija autenticação mútua do STARTTLS. Os spammers também podem obter certificados - ou criar certificados autoassinados. Rejeitar certificados de cliente autoassinado também resultará na perda de correio legítimo.

STARTTLS é criptografia ponto a ponto. O sistema de conexão ainda pode ler o conteúdo do email. Se você deseja privacidade real, precisa de algo de ponta a ponta, como OpenPGP ou S / MIME.

Dito isto, o STARTTLS remove um caminho possível para interceptação ou MITM e, portanto, ainda é uma boa idéia usá-lo quando possível, ou seja, quando o outro lado também o suporta.

— Joe Sniderman
fonte
1
A observação sobre certificados e spam está fora do lugar. É o destinatário que precisa de um certificado, não o remetente.
— precisa saber é o seguinte
isso não ajudará a evitar spam. Mesmo se você tornar obrigatória a autenticação mútua do STARTTLS. Atualizará a resposta para esclarecer.
— precisa saber é o seguinte
2
+1 na nota sobre spam. Só porque é criptografado, não o torna seguro.
— Matt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.